-
Notifications
You must be signed in to change notification settings - Fork 1
A flexible IoT data mapper
Technology review
200 h
Companies like Amazon, Microsoft, Google and Siemens are competing in the race for the 'best' IoT platform. Each Cloud provider uses different technology and has its advantages. Companies decide at one point to commit to a cloud provider, a decision that affects the technology they can use and the products of third party suppliers they can connect to their IoT solution. IoT device suppliers also face the challenge which cloud technology to support. While the underlying communication to each cloud, i.e. API calls can be abstracted through libraries with common interface, the mapping of application data to messages in the required format requires more effort.
The objective of this assignment is to find a flexible solution that allows for run time configuration of application data and its mapping to various cloud back ends. This can be achieved through data transformation rules and or a plug-in based software.
In recent years proprietary field bus technology has been replaced by standaridized ethernet based protocols to connect devices. This allows for resusing existing IT solutions and to connect PLCs from the machines to a ethernet TCP/IP based production network. The production net is connected to companies enterprise resource planning systems like SAP and possibly the internet. Figure 1 shows an exemplary network topology.
+----------------+ | | | Bildchen | | cpx-iot | | | +----------------+
Connecting industrial devices and machines to the internet allows for continuous data recording. This enables a range of options for generating knowledge about usage, performance, possible optimizations and component status. In the most basic case data is visualized and compared against thresholds. In more advanced cases the data is analyzed by machine learning algorithms to detect anomalies.
A gateway device collects data from connected field devices in the machine. Each field device provides a set of variables and configuration data. The gateway can be configured to poll sets of variables at a given frequency and publish it to the cloud.
The most simple case of this application is when the gateway manufacturer also provides the cloud back end and the field devices connected to the gateway. In this application the data-points of each device, their sensible sampling rate and the cloud technology are set by the manufacturer to provide a IoT product for fixed use-cases.
If a customer intends to monitor a specific application, e.g. variables from a PLC or maintenance data from devices the solution needs to be more flexible.
Currently a JSON file describes the data points for each known device. The data points are grouped in categories which define the sampling interval. A set of these JSON objects is put together at during setup by the user according to the actually connected device. The result is a tree-like structure of devices with their respective data-objects. Currently the data-objects have a fixed sampling rate and implicit data type.
In industrial automation it is common to calculate with raw values, meaning numeric data without explicit information about its physical dimension, its scaling or engineering unit. For instance a control loop in a PLC program reads a sensor value 12-Bit integer, the programmer first applies a scaling function programmed specifically for this sensor using external knowlege from the sensors data sheet. The PLC program code is agnostic about the meaning of the value only the programmer has knowledge whether this sensor value is a measurement of lengh, mass or any other physical dimension. The program also does not have or use information about the engineering unit, e.g. length in meter or feet. As result whenever a value is read from a PLC there is no information about its unit available.
For data form devices the unit and therefore the range is often not fixed. Many devices can be configured to provide data in a range of units. For a thermometer for instance the unit could be set to Fahrenheit if used by a US customer, to Degrees Centigrade if used in Europe o to Kelvin. Hence the 12 Bit raw value read is in a different range even after scaling. In the best case the currently used unit can be read back from the sensor. In the most common case this is determined and configured by the programmer during setup and must not change.
-
Depending on the application required sampling intervals for data must be configured. A temperature value may not be sampled as often as position information.
-
Since the user may have changed units of a device's data it must be possible for the user to configure the unit of data points for each device instance of the application.
-
Some cloud implementations such as Siemens Mindsphere require information about the data type of values. A data point in the cloud must have a type, e.g. float (1.234) , integer (1234) or string ("1234") and require this attribute to be sent with the datapoint. Other clouds are able to interpret a generic datatype "number". Depending on the cloud backend this extra information must be configured in the system.
Bonus: ?
- In cases where devices do not allow for changing the engineering units a formula may be provided to convert sensor readings to values with one common unit.