Internet of Things Patterns
This is an excerpt of the pattern that was first published in [1].

Pre-Defined Device-Driven Model

Icon of the Pre-Defined Device-Driven Model pattern

Device models, which describe the attributes and functionalities of particular types of devices, are created and stored on the backend server. The devices themselves choose a model that fits them from the provided selection and fill an instance of it with their metadata.

Context:

You have devices that each offer a specific set of functionality to other components, such as operations that can be invoked on them (for example, operating an actuator, or restarting the device) or information that can be retrieved from them (for example, the most recent values of a sensor). Each device is also described by a set of metadata, which could include its name, type, id, manufacturer, etc. You have other components, like other devices, a backend server, an application, etc., that need to interact with these devices.

Problem:

Other components need to know the data and functionality which a specific device provides so that they can interact with it. Not all devices come with the ability to provide or store this information, but you need them to retain some autonomy.

Forces:

  • Compatibility: For other components to be able to interact with a device they have to somehow have a common understanding of the available functionality.

  • Unmodeled Devices: Not all devices will come with a Device-Driven Model or have the ability to store such a model. Especially legacy devices or very constrained devices might not be able to store such information themselves. It should be possible to also integrate these devices.

  • Flexibility: The abilities of a device might change through firmware updates. Other components have to be made aware of and adapt to these changes. This will be hard if changes have to be made on all other components, especially if changes have to be made by hand.

  • Diversity: Many different kinds of devices with different functionality exist. Storing and managing descriptions of all of these devices centrally might be very hard.

  • Autonomy: The devices need to retain some autonomy, so it won’t be possible to use Server-Driven Models.

Solution:

Create a predefined set of device models. The models contains the device properties that can be read or written and the device commands that can be executed. Store the models on the backend server. Let devices choose a fitting model when they register.

Solution sketch of the Factory Bootstrap pattern

Solution Details:

This is an excerpt of a previously published pattern. The full pattern can be found in [1].


Benefits:
Drawbacks:

Variants:

Related Patterns:

Known Uses:

  1. L. Reinfurt, U. Breitenbücher, M. Falkenthal, F. Leymann, and A. Riegg, “Internet of Things Patterns for Device Bootstrapping and Registration,” in Proceedings of the 22nd European Conference on Pattern Languages of Programs (EuroPLoP), New York, NY, USA, 2017. Available at https://dl.acm.org/citation.cfm?doid=3147704.3147721