Architectural models

Resources

• An Internet of Things Reference Architecture Symantec
• Azure and Internet of Things Dominic Betts
• Final Architectural Reference Model for the IoT IoT-A
• P2413 - Standard for an Architectural Framework for the Internet of Things (IoT) IEEE
• IIoT Reference Architecture IIoT
• A Taxonomy of IoT Client Architectures Antero Taivalsaari and Tommi Mikkonen

Architectural frameworks

Long gone (hopefully!) are the days of building hodge-podge systems. The systems built nowadays are sufficiently complex and with sufficiently widespread effects that they require a structural framework in which to plan, design and ultimately implement the system.

An architectural framework gives general principles in any particular system might be designed and implemented. The figure from The Concept of Reference Architectures by Cloutier et al illustrates this:

The IoT is an amalgamation of two engineering disciplines which have hitherto been relatively disparate: IT and control systems. The highest level view of an IoT system might be

That is, a system of sensors, actuators and some control systems is linked to a more traditional IT system. Without both of these, it is not an IoT system.

Although simplistic, this does raise a large number of issues:

• The device-based system often uses hard-coded and custom-built control mechanisms. For example, a thermostat is hard-wired to turn on a heating system when the temperature reaches a point on the dial. An IT system will generally be soft-coded, with the possibility of being replaced easily with an updated version.
• The device-based system often has to react in real-time. Particularly in industrial system, the constraints are often hard real-time. It isn't possible to wait for a software upgrade to complete when you need to make microsecond decisions about the nuclear reactor.
• Related to this is the concept of resilience. While many functions of an office system may be disabled by a network outage, a device-based system must be able to survive a network outage. This may be by downgrading functions or even going into 'sleep' mode, but the system must degrade in a controlled manner.
• Many IT system are reversible: an erroneous entry into a database can usually be undone. Releasing a valve on a tank of sulphuric acid can't be. This is closely related to safety: many device-based systems have to legally conform to constraints on behaviour caused by safety issues.
• It is becoming the norm to hear about massive data breakins to large corporations. Credit cards and login details are made available for sale, and intellectual property secrets are traded. However, industrial espionage can turn very nasty in physical ways, as evidenced by the Stuxnet attack on the Iranian nuclear facilities. Security flaws can affect any part of an IoT system, and due to the scope of an IoT system this can be anywhere from sensors and actuators to big data. While IT systems are becoming more tuned to the fast turnaround required to patch systems, device-based systems may never be fixed - and so should not be attackable in the first place! Impossible, but the risk can be mitigated by designing for security from the outset.
• A device-based system with hard-coded event-response mechanisms does not have an object-based view of what is happening: that was probably in the designer's head. Software systems are increasingly object-oriented, with software objects explicitly manipulated. So an IoT system processing, for example, temperature data from a sensor will typically use a Thermometer object. There will need to be a "concept bridge" between the two systems so that the software layer will know that the digital data represents a temperature rather than anything else.

Functional viewpoint

There are multiple viewpoints that can be had about any system: functional, business, usage, implementation, ... From the functional viewpoint, the IIoT Reference Architecture distinguishes these domains

• Control domain
• Operations domain
• Information domain
• Application domain
• Business domain

These are linked through their Figure 6.1

The IIoT states

Data flows and control flows take place in and between these functional domains. Fig 6-1 above illustrates how the functional domains relate to each other with regard to data and control flows. Green arrows show how data flows circulate across domains. Red arrows show how control flows circulate across domains. Other horizontal arrows illustrate some processing taking place within each domain, to process input flows and generate new forms of data or control flows.

This substantially refines the simplistic model of the previous section and clearly shows the flows between components. The IIoT reference architecture goes into substantially more detail about each component, and while targetted towards industrial systems, is nevertheless applicable to many other IoT systems.

Design patterns

Design patterns are a well-accepted means of capturing design problems and possible solutions in an implementation independent way. Architectural design patterns act at a relatively high level. The IIoT reference architecture lists five patterns:

• Three-tier architecture pattern
• Gateway-Mediated Edge Connectivity and Management architecture pattern
• Edge-to-Cloud architecture pattern (This pattern contrasts with the gateway-mediated pattern as it assumes a wide-area connectivity and addressability for devices and assets.)
• Multi-Tier Data Storage architecture pattern (This pattern supports a combination of storage tiers (performance tier, capacity tier, archive tier.)
• Distributed Analytics architecture pattern

The IoT-A Internet of Things – Architecture prefers to use "design tactics". Both go into a large amount of detail regarding the next level down.

Client architectures

The A Taxonomy of IoT Client Architectures list several layers for client side devices:

• no-OS architectures,
• RTOS (real-time OS)
• architectures,
• language-runtime architectures,
• full-OS architectures,
• app-OS architectures,
• server-OS architectures,
• container-OS architectures.

Implementation

Much of the sequel of this book concerns the choices to be made at the implementation level: this network protocol or that, for example. However, any implementation solution should be guided by higher-level architectural considerations.

Copyright © Jan Newmarch, jan@newmarch.name

"The Internet of Things - a techie's viewpoint" by Jan Newmarch is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Based on a work at https://jan.newmarch.name/IoT/.

If you like this book, please donate using PayPal