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

Server-Driven Model

Icon of the Server Driven pattern

Device models, which describe the attributes and functionalities of particular types of devices, are created and stored on the backend server. The backend server also assigns instances of these models to the respective devices.

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. But not all devices come with the ability to provide or store this information.

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, or a pointer to a Pre-Defined Device-Driven Model. Especially legacy devices or very constrained devices might not be able to store and provide 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.

Solution:

Create a device model that describes the device and its functionality. Store it in a model database on the backend server. Assign a model instance to the device on the backend server during registration. Store the device’s model instance in a Device Registry.

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