IoT Patterns for Field Devices

This chapter lists the key patterns that are relevant to field devices or Things. After reading this chapter, you will be able to identify the existence of these patterns in IoT architectures. It provides details regarding the scenarios in which the patterns are suitable or applicable, along with the constraints that need to be considered. This will help you understand existing IoT architectures with relative ease.

This chapter covers the following three key patterns:

• Device gateway (DG): A DG serves as a bridge between field devices (sensors, actuators, and so on) and the central server. In a standalone deployment (without the central server), DG coordinates actions between local devices (sensors and actuators).
• Digital twin (DT): DT is used to maintain a virtual state of the field devices on the central server, thereby allowing for remote monitoring and control operations. By performing the required processing on the accumulated data...

Device gateway

DG is an important pattern as it helps link physical and virtual worlds. The physical world is monitored by sensors and actions are initiated by actuators, as per the commands that are sent by a DG. The notation that is used for the DG in this book is shown in the following diagram:

Figure 2.1 – Notation for the DG pattern

Important Note

The DG is also referred to as the Field Gateway in the IoT literature.

In addition to its role in enabling edge/local intelligence by hosting a Local Rule Engine (LRE) and performing latency-sensitive decisions, DG enables data communication with the central server, where more complex decisions (those requiring a global context) must be made. The need for DG arises because most sensors/actuators are constrained in terms of compute, memory, storage, or power, so they can’t establish connectivity with the central server. A good practical example of DG is a smartphone as it connects to multiple...

Digital twin

A DT is a virtual copy of an IoT device that’s deployed in the field. The concept is very similar to the process of creating a model (simulation) of a physical entity or process to understand its exhibited behavior. The notation for DT used in this book is shown in the following figure:

Figure 2.3 – Notation for the DT pattern

DT is an important pattern in the context of IoT as data may be transferred between the central server and field devices over unreliable communication channels (intermittent connectivity). Also, field devices may choose to sleep and only wake up during specific times to conserve energy. So, DT is also used to abstract users from the current state of field devices (wake up, sleep, and so on) and the communication channel’s nuances.

DT also provides an encapsulation mechanism whereby users can view and set the state without being concerned with the actual state of the field devices and/or connectivity...

Device management

The roles of the devices and how they are managed is the key differentiator between IoT and non-IoT deployments. The stages of device life cycle management include device provisioning (registration, activation, and commissioning) to de-provisioning. The notation used for device management in this book is shown in the following diagram:

Figure 2.6 – Notation for the device management pattern

Device management includes firmware updates for the field devices, either on an ad hoc basis (for example, patching security vulnerabilities) or in a planned manner (pushing the latest configuration and/or firmware with the updated feature set). Due to the constrained nature of IoT devices, special considerations are required while updating firmware:

• The device shouldn’t be in the middle of a critical operation. Accordingly, the device’s current state (busy, idle, and so on) should be shared with the central server at regular...

Summary

This chapter introduced the core device-related patterns (DG, DT, and device management). These patterns will help you develop end-to-end IoT architectures (that is, scenarios where data is sent by the devices and commands are then sent back to devices so that the required action can be taken). At this point, you should be able to make decisions regarding what functionalities need to be implemented in the DG and what functionalities need to be implemented at the central server.

The next chapter will expand on this list of IoT patterns and include patterns that are implemented on the central server.