For the development of an architecture for the Internet of Things (IoT), we present the approach “Platform as a Service” in today’s article. The accompanying graphic also shows in detail how this looks like.
The IoT architecture approach “Platform as a Service” is based on the IoT platforms of the major manufacturers. Cloud providers such as Amazon Web Services (with Amazon IoT Core) offer managed IoT platforms (see No. 4). Companies can register and manage millions of devices grouped by application purpose here (see 4a). The recorded devices are anchored in a central database and can even be updated from the cloud and managed directly, depending on the functional scope of the platform. However, this is based on devices that work with a manageable number of sensors and status updates.
Status changes for a sensor can be sent to a message broker (see no. 4b) via a gateway (see no. 3). A Message Broker is a central software component that functions according to the publish/subscriber principle. It uses the open message protocol MQTT (Message Queue Telemetry Transport) for machine-to-machine communication and should have established encryption at Transport Layer Security level if possible. This should be secured with certificates that are managed via Device Management.
The respective end device takes over the publisher’s part and sends its updates to a so-called “topic”. All recipients who have subscribed to this topic then automatically receive status changes. This is exactly where the rule engine comes in (see no. 4c), in which topics can be subscribed to and then rules can be created, e.g. using a graphical editor. These rules define, for example, how incoming data are to be transformed or how and where they are to be stored, i.e. in a database or mass storage (see 5a, 5b). Also simple calculations and comparisons of data are already possible here. For example a sudden temperature rise could be identified here, that is transmitted by a sensor. As a result, the system would send an e-mail or push message or address a downstream business logic, which would then carry out further processing.
Based on the stored data, a visualization can be realized with a suitable business intelligence tool, such as a tailored portal made by Storm Reply, Splunk, Power BI or Quicksight (see No. 6). In addition to the Rule Engine, there is also the Device Shadow / Thing Shadow (see no. 4d). A Device Shadow provides a persistent view of the managed device. The current status is stored in a device shadow and synchronized between cloud and device. If, for example, a switching process was initiated from the cloud, but the addressed device has no connection at that time, the status is synchronized with the next data connection and the “Thing” can then execute the switching process. Thus, no status is lost within the network.