Model execution for different devices

Models are executed independently for different devices. That is, models for one device can execute in parallel, making use of hardware parallelism where possible, if models are processing data (such as Measurement, Event, or Operation objects) for different devices. When defining a model, you can configure it to use data from only one device, or from a number of devices, with each device being handled independently.

Each model must either:

A device group is a means of organizing devices. A device group can contain any number of devices or other device groups. When a model uses a device group, the model will act on all devices referred to by the device group, either directly or indirectly through members of the device group that are themselves device groups and have device members (or even "grand-children" device group members). A device can be a member of zero, one or many device groups. See also the information on the Device Management application and grouping devices in the User guide at https://www.cumulocity.com/guides/.

Note: A model that acts on a device group only determines the device group membership when the model is activated. If the membership of a device group changes while a model is running, the model will not behave any differently for any new or removed members of the group. If a device group membership is changed, then models that refer to that device group should be de-activated and re-activated.

It is not possible to mix the two types of input blocks above (but see Broadcast devices). However, data from a model processing single devices can be sent to and received from other models, including models for device groups, and vice versa (see Connections between models).

When a model consumes data from groups, the model behaves as if multiple instances of the model are running, as illustrated below, each one processing data from each device independently. Each instance processes data for a different device, but all share the same blocks and block parameters. The values of the wires will be independent for different instances. Any blocks that are stateful, such as the Average (Mean) block, will operate independently of the data from other devices. As with single-device models, if any block causes a runtime error or exception, then the entire model will go into a failed state - it will stop processing data for all devices.

Typically, when using device groups for inputs, all input blocks would use the same group. It is possible to use different device groups. If there are devices in one group but not in another, those blocks will never generate a signal for devices that are not in that group. For some blocks, such as the Expression block, this is not useful - an Expression block will only generate an output if all of the required inputs have received a value, but it may be useful for pulse inputs of a Gate block.

When a model has inputs that are consuming data from a single device, then the output blocks must specify the same device.

When a model has inputs that are consuming data from a device group, all output blocks must specify the Trigger Device, a special device in the Output category of the palette. The Trigger Device generates data (Measurement, Event or Operation) for whichever device that model instance applies to - or whichever device sent the data to trigger that model instance.

You can use the model editor to change input and output blocks from one device or device group to another. When changing between a device group and a device, output blocks will switch between the Trigger Device and the device specified, so that the model is kept in a usable state. See also Replacing devices and device groups.

The test and simulation modes are only permitted for models using a single device. If you wish to test or simulate a model using a device group, then use the model editor to modify it to apply to a single device within the device group, and then activate the model in test or simulation mode. See Deploying a model for more information on these modes.

By default, the Apama Analytics Builder runtime uses up to 4 CPU cores to execute models. You can configure this by editing the file /usr/edge/properties/apama/extensions/config/files/analyticsbuilder-workers.properties. By default, this file contains the following:

Typically, this configuration value would be set to the number of CPU cores available for the system, but it may be useful to configure this either higher or lower according to what resources are available. It does not need to scale to the number of devices (that is, it is quite reasonable to have 4 worker threads with hundreds of devices, assuming a moderate event rate per device).

Because each device is processed independently, as noted above, it is only possible to use data from, or generate data for, a single device within each model. However, it is possible to configure the concurrency level to 1, at which point it is possible to activate models which can consume data and generate data across different devices. As the concurrency level (numWorkerThreads) value is a global setting, this means that for a given Apama Analytics Builder installation, it is only possible to achieve either scale up or models that operate across devices.

With the concurrency level set to 1, it is still possible to create models which use device groups as inputs, but these continue to operate independently for each device within the device group, and it is still not possible to mix device group and single device input or output.