IoT Architecture Blueprints

As already introduced in the “Plan/Build/Run” section previously, Ignite | IoT relies on a set of artifacts that are used to describe the solution architecture from different architectural perspectives. An overview of the different artifacts – in particular for the functional and technical design – can be found in the diagram below.

While some of these artifact types are well-known standard artifacts from normal IT projects, other are specialized artifact types that have been specifically developed for use in IoT projects. In particular, the Asset Integration Architecture (AIA) has been defined as part of the Ignite | IoT Methodology to help describe the relationships between assets and devices (“things”) and the backend. This will be our focus in the following.

Asset Integration Architecture

We have already provided a high-level overview of the Asset Integration Architecture (AIA) in the introduction. The basic idea of the AIA is that in an Enterprise IoT context, most solutions involve connecting assets with backend services provided by enterprise applications. According to our definition, an asset is an entity that is usually of primary economic interest to the enterprise, such as a vehicle, a machine, or a building. On the asset, we find different kinds of devices, such as sensors, actuators (like an electric motor to open a window), and so on. Usually, these devices would also have some kind of on-board power management and device control, for instance to operate a motor at different speeds. Many assets also have multiple on-board computer systems for various tasks. For example, a modern car has between 50 and 80 ECUs (Engine Control Units) and similar, specialized microcontrollers for managing the different elements of the power train (engine, transmission, drive shafts, differentials, etc.) This is what we call the “on-asset business logic.”

In Enterprise IoT solutions, one typical challenge is managing large fleets of fixed or mobile assets. This is usually achieved using a specialized tier that creates a logical link between the asset and the enterprise. We call this the IoT cloud or M2M tier. On the asset, this tier usually deploys a gateway and a software agent. The gateway can physically connect with the different on-asset hardware components on the one hand, and enable remote connectivity with the enterprise backend through mobile or satellite communication, for example. The software agent performs software-based local integration tasks. Often, the agent creates local objects (known as “device proxy objects”) that encapsulate the different connected heterogeneous devices, thus providing one homogeneous remote interface with the backend. The agent can also provide additional functionalities like event management, local event management, security, and local software lifecycle management.

The counterpart is the IoT or M2M backend on the enterprise side. The IoT/M2M backend typically implements a database to manage information about the remote assets and devices, including device status information and event history. This asset repository is a central function of the IoT/M2M backend, and is usually combined with event management or stream processing, identity management and security, asset-specific billing functionality, and remote software distribution.

In addition, the IoT/M2M backend uses different kinds of middleware technologies to integrate with existing backend applications, such as ERP (Enterprise Resource Planning), CRM (Customer Relation Management), and PLM (Product Lifecycle Management).

An important architectural decision is whether the new backend application logic should be implemented as part of the IoT/M2M backend or as part of an existing backend application. Later, in the “IoT Technology Profiles” section, we propose an approach in which BPM (Business Process Management) can be implemented as an integration layer between the IoT/M2M backend and the enterprise applications to make end-to-end IoT processes more transparent (see “Middleware” in the “IoT Technology Profiles” section).

Mapping the AIA to Different Industries

One important benefit of the AIA is that it provides a structural blueprint for the large number of highly heterogeneous approaches that can be found across different industries. The diagram below provides an overview of how the AIA maps to the various industry-specific approaches.

For example, in the automotive industry, you will usually find an architectural approach in which multiple, highly specialized ECUs (Engine Control Units) are distributed around the power train. A VCU (Vehicle Control Unit) acts as the head unit and provides a central integration point for other systems, for example the entertainment system. Because the ECU and the remote control TCU (Telematics Control Unit) are explicitly separated in most cars, we have mapped the TCU to the gateway function in our AIA. A sample use for a TCU would be a vehicle fleet management solution in the backend.

Take, as another example, the area of smart homes. Here it is common to find a central smart-home controller that combines gateway functionality with more advanced local business logic in a single device, which can use Bluetooth, Z-Wave, EnOcean, or Wi-Fi to connect to different local nodes such as a thermostat or window control unit.

Another example that can be easily mapped to the AIA is manufacturing. In the manufacturing sector, you will generally find Programmable Logic Controllers (PLCs), which are specialized microcomputers used to control and automate industrial electromechanical processes, for instance to control machinery on factory assembly lines. The PLC would therefore be the on-asset logic deployed on or close to the machine. SCADA systems (Supervisory Control and Data Acquisition) leverage telemetry technology to remotely manage a network of PLCs and provide a central data-acquisition server in the backend.

As we can see, the Asset Integration Architecture defined by the Ignite | IoT Methodology serves as an integrating perspective that can be used regardless of industry-specific standards. We will see how this can be used below.

AIA-Based IoT Architecture Patterns

Strictly speaking, the AIA is not an architecture in itself but rather an architectural lens through which different IoT architecture patterns can be observed. Some examples for concrete IoT architecture patterns are presented in the figure below.

On the right, we can see a simple pattern, “Device2Backend,” in which the device itself is directly connected to a backend – for instance, a mobile phone. Next to that, “Peer2Peer” (or “Device2Device”) describes a pattern where devices interact with each other directly. Next, the “Local Hub” pattern describes connectivity for multiple devices through a central local hub, such as a smart home controller. The “M2M” architecture pattern describes a more hierarchical management of multiple assets that are connected to a central backend. In keeping with our definition of M2M, this type of solution is limited to applications like Remote Condition Monitoring (RCM) and does not provide advanced services. Such services are added in the “Enterprise IoT” architecture pattern.

Cross-Domain Integration – Subnets of Things (Again)

As discussed in the introduction, many IoT solutions will start as more self-contained solutions – or, as we dubbed them, Subnets of Things (SoTs). In order to integrate multiple SoTs, such as a fleet management and an energy management solution, it is important to understand the architecture options, which are described in the figure below.

In principle, integration can take place on any of the layers of the AIA. On the device level, integration can happen through any kind of (usually wireless) near-field type of communication, an example being Bluetooth. Between different on-asset microcomputers, a local bus system can be used for integration. Gateways may also interact with each other directly, for instance in a Car2Car type of integration scenario. Specialized integration middleware providers such as wot.io can integrate multiple different IoT/M2M backend platforms. Alternatively, integration might actually take place on the application level in the backend – either by integrating backends with each other (and yes, this means that EDI or Electronic Data Interchange is not going to go away in the near future), or by having devices interact with other backends (such as a cloud-based smart home type of integration, for example).