Data Management

Last modified: Aug 15, 2018 @ 13:27

Before data can be pushed to or polled into DDM the individual physical sensors and devices must be defined and registered in the platform. Only data from registered devices will be accepted and inserted into the platform. A registered device can be called a device shadow or an instance of a device in DDM.

Data collection

The sender of the incoming data is identified and the data is mapped to the corresponding device shadow instance in DDM where it is stored. The picture below shows the latest received value from a device containing several sensors. Full drill down capabilities of the data is built into the platform via GUI and APIs.  New data types can be added to devices and sensors using the administrator console.

The following figure shows the sensors of a device that is registered into the platform. In this case the device is a LWM2M enabled device so both device mgmt objects as well as sensor values are ingested into DDM.

Apply rules and logic

Part of the data management function is to apply logic and rules to the incoming data such as verifying if there are formulas or algorithms that should be applied, if calculations of data is needed, if triggers should be raised based on the conditions that are defined for the sensor/device.  Rules can be define based on location, type of sensor, type of data or any other tag that is defined in the platform.

DDM support both physical data and virtual data, the physical data is the raw data coming from the sensors and virtual data can be created inflight via formulas and transformers.  By adding formulas on the received data new data types, values and entities can be created.

Triggers and event

Data rules defined in DDM can trigger an event to be executed. If a value goes outside of a defined span in the platform DDM fires of a call to an external system such as a heating device if the temperature is the low in a location or to a workforce mgmt if manual interaction is needed to solve the problem or to a combination of different devices/systems.
By using the native functionality DDM can control and manage external systems for cooling, heating, lights etc.

Rules can easily be defined for individual sensors values, for all sensors of a certain type, for all sensors in a building etc.

The screen below shows the definition of a trigger that is part of a rule called High Temp.

If a sensor values of a device that is included in the “All temperature devices” resource group is higher than 22 in average the last 1 minute an alarm will be raised.

More complex rules can be defined by combining several sensor values in a combination of realtime and aggregated values coming from ”physical” sensors and/or “virtual” sensors/devices.

It is also possible to set rules with AND/OR rules to decide if sensors triggering must be in the same smart object or within the same device or maybe in the same location but on different devices.

The slide below shows the result of a trigger that has fired, the temperature is above the defined max value. In this case the trigger is manually reset when the problem is

Actuator and Consumers

DDM supports sending alarms to different receivers of the event/alarm. There are two different receivers supported and one event can be sent to several different receivers.

  • Actuator
    • An actuator is one or many writable or executable resources on one or many devices that DDM interacts with.
    • You can automate processes like switch off lights, open doors, start a cooling system.
    • The actuator below reset a value of a temperature smart object.
  • Consumer
    •  A consumer is a call out to an external application that decides what shall happened. Example can be to send an email but a consumer can also be a work force mgmt system if manual interaction is needed to solve a problem.
    • There are several ways that the Event consumer can get notified, either by defining a HTTP end point to be called, working with an Inbox/Outbox which then supports occasionally connected consumers, email, SMS etc.

Resolution, Aggregation and Time

Data from the sensors can be sliced and examined based on time resolutions, aggregations and time.  Searching for a sensors max, min, average or other values for the last day, week, month or any of the timeframes that have been configured is possible via GUI or the provided APIs.

With Resolutions it is possible to create aggregated values based on timing intervals. A Resolution is a defined timespan which is updated in real-time. The Resolution values are stored in the platform and can be requested through the REST APIs. Examples: 1 min, 5 min, 60 min

The slide shows the built in GUI for monitoring individual sensors values. Using APIs external tools such as freeboard, graphana, Power-BI can be used to display the data as well. The graph show the average value for a sensor based on 10 minutes intervals for today.

Even the rules engine can be defined to trigger on  values from the resolutions and aggregation, i.e. fire an alarms if the average value that last 10 minutes is < X.