Models

Models are used to simulate different business objects, processes, and their hierarchies. Complexity of models can greatly vary, from defining a few custom calculated properties or business rules to representing a digital twin of a whole industrial facility with all its entities and assets.

Models may act on their own, allowing your app users to create their instances on-demand, or be attached to lower-level objects, such as devices or other models, to amend their behavior. In the latter case, a model’s instances are created automatically to match the hierarchy of objects it’s attached to.

Each model comprises:

  • Definitions of variables (properties) representing model values.

  • Definitions of functions (operations) that instruct the model to perform some processing or calculation.

  • Definitions of events the model can produce.

  • Definitions of bindings that tie the model's properties, operations and events together, allowing it to react to the events or states of other objects.

  • Sets of business rules for decision making according to a machine-readable knowledge base.

Simple real life model example

Simple monitoring and control systems allow direct visualization of values that were collected from devices. However, devices from different manufacturers use differing approaches for providing values with the same physical meaning.

For example, network management products are used to track the CPU load of network nodes. This simple metric is available in many different forms:

  • Windows-based computers expose "spot" values of the CPU load via SNMP.

  • Same Windows machines can provide WMI-based CPU load readings if SNMP is not available.

  • Cisco routers provide pre-calculated CPU utilization data as 5-minute and 1-hour averages.

  • HP-UX servers have counter-type values showing how many seconds the CPU was busy since server startup. These counters require complex processing to calculate the current load.

However, a Network Device dashboard should have a "CPU Load" chart which looks the same regardless of device type. A "High CPU Load" alert is also expected to behave the same for all device types. In addition, we'd like to build a "CPU Load Overview" report showing current utilization for all devices in our network.

The right way to ensure the above requirements is having a numeric "CPU Load" metric in every device that provides CPU data. This metric should have a common format, but its calculation and update policy will differ between device types.

That's where a model can help. The "CPU Load" model attaches to every network device and employs a set of business rules to calculate current CPU load. The rules calculation is triggered by a periodic binding. The calculation result based on the business rule set is written into the CPU Load variable that is declared by the same model.

Models are a little bit similar to widgets. A model may be interpreted as a widget that runs inside the server and has no user interface. However, both models and widgets have binding engines that make them "live" by activating certain based on system events and state changes.

Every user has their own set of models.

Administering Models

Two contexts are used to administer models: One is the general Models context, which serves as a container. The other is the Model context, which holds the information for one model.

Was this page helpful?