(82) Cracking the IIoT architectural code — Part 1

I have spent the last several weeks deep diving on architectural frameworks that define any IIoT implementation. The more I read up and interact with industry experts, the more I realised that there will be no one single architecture and no single system that will provide all of the capability that an industrial company will want.

An architecture will always be a combination of Edge, on-premise, centralized, and cloud systems for a company to be successful.

Here is my interpretation of an IIoT platform

Level 1: Sensors and Actuators

This is the layer from where data is gathered from sensors and PLCs where the data is originally generated. A sensor is defined as device that can record a measurement about its physical environment. This measurement can then be turned into an electrical signal that is sent to a gateway for additional processing. Sensors have predefined roles in data gathering. Sensors can generate data like temperature, air quality, water levels etc in analog form. The more sensors you have, the more volume of data gets generated.

Actuators intervene to change the physical conditions that generate the data. An actuator might, for example, shut off a power supply, adjust an air flow valve, or move a robotic arm in an assembly process.

Level 2: Internet Gateway

The data from the sensors starts in analog form. That data needs to be aggregated and converted into digital streams for further processing downstream.

Data acquisition systems (DAS) perform these data aggregation and conversion functions. The DAS connects to the sensor network, aggregates outputs, and performs the analog-to-digital conversion.

The Internet gateway receives the aggregated and digitized data and routes it over Wi-Fi, wired LANs, or the Internet, to Stage 3 systems for further processing to the cloud.

Stage 2 systems often sit in close proximity to the sensors and actuators. For example, a pump might contain a half-dozen sensors and actuators that feed data into a data aggregation device that also digitizes the data. This device might be physically attached to the pump. An adjacent gateway device or server would then process the data and forward it to the Stage 3 or Stage 4 systems.

Level 3: Edge IT

Once IoT data has been digitized and aggregated, it’s ready to cross into the IT layer. However, the data may require further processing before it enters the data center. This is where edge IT systems, which perform more analysis, come into play. Edge IT processing systems may be located in remote offices or other edge locations, but generally these sit in the facility or location where the sensors reside closer to the sensors.

Because IoT data can easily eat up network bandwidth and swamp your data center resources, it’s best to have systems at the edge capable of performing analytics as a way to lessen the burden on core IT infrastructure. You’d also face security concerns, storage issues, and delays processing the data.

With a staged approach, you can preprocess the data, generate meaningful results, and pass only those on. For example, rather than passing on raw vibration data for the pumps, you could aggregate and convert the data, analyze it, and send only projections as to when each device will fail or need service.

Here’s another example: You might use machine learning at the edge to scan for anomalies that identify impending maintenance problems that require immediate attention. Then you could use visualization technology to present that information using easy-to-understand dashboards, maps, or graphs. Highly integrated compute systems, such as hyper-converged infrastructure, are ideally suited to these tasks because they’re relatively fast, and easy to deploy and manage remotely.

Level 4: The data center and the cloud

Data that needs more in-depth processing, and where feedback doesn’t have to be immediate, gets forwarded to physical data center or cloud-based systems, where more powerful IT systems can analyze, manage, and securely store the data. It takes longer to get results when you wait until data reaches Stage 4, but you can execute a more in-depth analysis, as well as combine your sensor data with data from other sources for deeper insights.

The data is aggregated in a big data warehouse. It makes sense to add a data lake to the solution to accumulate all the data a company plans to use in the future and thus separate potentially useful data from the data with the already proved usefulness.

Functional Architecture

Machnation has attempted to create a functional IoT architecture for the industry, which looks a very promising reference guide.

Here’s a quick summary of its eight functional categories:

1. Application: An application is any piece of contained logic either running on or directly integrated to an IoT platform. On-cloud and on-premises applications enable code-based control over IoT platform components, enriching the raw assets or data with customer-specific logic. An application can contain customer-, operator-, or administrator-facing user interfaces (UIs), or could function as a self-contained service, providing any type of relevant data or device manipulation.
2. Access Control: Access control is the system of identity verification and permission management for all platform-connected elements including APIs, administrator or operator interfaces, devices, users, organizations, stored or in-transit data, or any other platform service.
3. Analytics: Analytics refers to the ability of an administrator or operator to monitor both historical and real-time observations collected from platform-connected IoT devices. Analytics can include descriptive, predictive, and prescriptive components.
4. Data Management: Data management is defined as the capabilities within an IoT platform to ingest, store, manage, and forward data received from platform-connected IoT devices.
5. Device Management: Device management refers to the ability of a platform to provide lifecycle management functionality for connected devices, including device onboarding, deployment of software and firmware updates, and configuration of managed devices.
6. Event Processing: Event processing refers to the ability of an IoT platform to execute actions or provide notifications based on administrator or operator configured rules or triggers.
7. Integration: Integration is defined as the ability of an IoT platform to interface and share data with off-platform or third-party applications, services, or systems.
8. Monitoring: Monitoring is defined as the ability of a platform to trigger events, evaluate device status, and follow ingested data streams. Platform capabilities for monitoring should include both aggregated and drill-down views, and typically include operator- or administrator-facing dashboards and other graphical interfaces.

In the next post, I will continue the topic and present to you IIoT architectural framework proposed by the Industrial Internet Consortium