- Galdos Systems Inc. - https://www.galdosinc.com -

Mastering Data with Registries for IoT

Originally published on LinkedIn: https://www.linkedin.com/pulse/mastering-data-registries-iot-ron-lake [1]

Illustration of a master data registry managing and maintaining synchronization of device records and data flowing between different databases and applications

We noted in a previous post on the “Challenge of Unique Data for the Internet of Things”(https://www.linkedin.com/pulse/challenge-unique-data-internet-things-ron-lake [2]) that unique business data is key to the successful deployment and maintenance of IoT applications. Without it, IoT applications will be prone to the same costly master data management (MDM) problems confronted when managing traditional business data across the enterprise.

This article looks at the use of registries for IoT metadata, and at how registries can help ensure unique and synchronized data across IoT applications.

Key business data for IoT includes device identification, device description and properties, device location and location context, device connectivity, and application context. All of this data must be maintained in synch across all of the IoT applications (and there may be several) that a device participates in, and ideally across the enterprise or enterprises that employ the device.

How can registries help? Let us start by looking at device identification.

For hardware devices such as sensors or actuators, a common device identifier will be the manufacturer’s serial number. Of course there is the problem that such an identifier will not be unique across different device types, or even across the same device type from one manufacturer to another. Different departments may then add additional terms to the serial number to obtain a global ID, at least within that department. Others may add text or numeric strings to identify the function of the device. Using a registry, we can make use of the local identification system through objects called External Identifiers. These behave like identifiers but are not required to be globally unique. For example, the device serial number could be the value of an External Identifier which can then be “attached” to a give object such as an IoT sensor. At the same time, the device itself is automatically assigned a globally unique identifier by the registry itself. Searching for the serial number using the External Identifier may produce duplicates but, on the other hand, searching using the registry-assigned globally unique ID is guaranteed to return a unique result.

With the large number of devices that might be involved, one can anticipate application enterprises, such as an Oil Major, maintaining in-house stocks of components and assigning SKU’s (Stock Keeping Units) to track them. Again we can anticipate uniqueness issues where sensors are obtained from different SKU databases and again the registry’s External Identifier can provide a solution.

Note that a registry can support the user specification of the pattern used for the External Identifier value, and can check that new objects of a given type comply with this pattern. By using a registry and assigning External Identifiers, we can have the best of both worlds, matching in-use identification schemes and ensuring global uniqueness no matter how wide the scope of the application or the enterprise.

Using identifiers is not restricted to hardware devices. It will also be necessary to identify application and web service software components that are part of an IoT solution. Unlike the hardware case, there may be no existing identification schemes, and a registry’s own globally unique identifiers can be used directly. This is the common case, for example, in a registry of web services.

Identifiers will also apply to real world components that IoT devices interact with (e.g. a fuel tank, or a water pipeline), and again we have the same issues and solution as for IoT hardware devices.

Of course, it is essential that changes in external systems be maintained in synchronization with the registry. This can be handled in one of two ways. In the first case, a master registry would contain records of all IoT devices that are in scope for the enterprise or group of enterprises. All applications are then modified to use the master registry both for updating and for reading. This registry may be distributed across departments or enterprises, and the various copies synchronized using the registry data synchronization capabilities. In the second case, there may be existing IoT device databases with existing applications that porting to a registry is considered too expensive to be a practical solution. In this instance, the registry (again there may be multiple registries) is synchronized with the external database using the registry’s pub-sub data synchronization capability. Devices, matching a given type, location, etc. and inserted or modified in an external database, are then automatically inserted or modified in a subscribing registry. This same approach may cause external databases to be updated whenever changes are made to a device in a registry to which they are subscribing.

Registries offer all of the needed mechanics to support the description of key business data across IoT applications including device identifiers, device properties and description, device connectivity, location and location context, and application context. The data synchronization capabilities of registries can ensure the registry content remains unique and in synch with that in IoT databases across the enterprise or group of enterprises. Registries can solve a number of Iot and master data management challenges without any additional support.