Working with interfaces

How does data management work?

A device that has a temperature sensor in an office might report temperature in degrees Fahrenheit or in degrees Celsius. It is not efficient to configure applications to be able to consume data in all these formats. Instead, the data needs to be collected, transformed, and normalized to create a single logical model so that an application can interact with the different devices in the same way.

The data management component of the IoT tool includes a device twin feature. The device twin feature lets you take advantage of the collection, transformation, and normalization of different formats of device data into a single logical model.

At a high level, the IoT tool supports the following methods for accessing your device data by using data management logical interfaces:

Device twins

A device twin is a cloud-based digital representation of a physical device that is connected to the IoT tool. A device twin represents a logical model of the events that are published by a device. After it is defined and instantiated, the device twin provides a consistent means of interacting with a device in a REST-like manner, regardless of whether the device is online or offline. The properties of a device, including information about the current state of the device, which is known as the device state, can be retrieved by using an HTTP request or by subscribing to an IoT topic.

Device twins can help you:

• Provide your application developers with consistent interfaces to access event-driven device data in a REST-like manner.
• Access the state of a device.
• Normalize data from devices of different makes or models that publish data in different formats.
• Filter out unneeded data.

To create a device twin, you need to define the following resources in the IoT tool:

• The structure of the events that are sent by your device. The structure of an inbound event is defined in the physical interface, event type, and event schema resources.
• The properties that you want to record. These properties define the logical structure of the device state that can be consumed by your applications. The properties are defined in the logical interface and logical schema resources.
• The mapping of physical interface events onto the logical interface properties. Use the mappings resource to map events to properties.

For example, two different temperature devices might exist at separate locations. One device reports device data in degrees Celsius and the other reports data in degrees Fahrenheit. The data is sent to the IoT tool in the "t" and "temp" temperature formats. The IoT tool automatically transforms the degrees Fahrenheit into degrees Celsius. The "t" and "temp" temperature formats are normalized into the "temperature" logical format. The application can query the state of either device by accessing the value for the "temperature" parameter.

Limitations

Logical interfaces must only be used for devices types that were created in Maximo® Monitor versions that are earlier than 8.8. Logical interfaces are not required for device types that are created in 8.8 or later versions. If you are using logical interfaces with Maximo Monitor, the following limitations apply:

• You can create one logical interface per event type for each device type. If a logical interface maps two or more events, the Event Type field will be blank in the device type table in the data lake.
• If two different logical interfaces map the same property but with different data types, unexpected behavior, including data loss might occur.
• To rename a logical interface property, you must use the interfaces API to deactivate the logical interface, update the property and then activate the logical interface.
• The logical interface array JSON type is not supported.

Next steps

• Create logical interfaces from the UI or from a REST API.
• Create rules and actions that are triggered when event data that matches a specified condition, or set of conditions, is received by IoT.