Designing Reliable Industrial IoT: Architecture, Middleware & Real-World Cases

Preface

Although the term "Internet of Things" appeared in 1999, it was only after IBM introduced the "Smart Earth" concept in 2009 that many countries elevated IoT research to a strategic level. In China, IoT development still relies heavily on government projects, making its future uncertain.

The government, prompted by internet companies, proposed the "Internet+" concept. While both focus on networking, "Internet+" emphasizes the internet itself with peripheral smart modules, whereas industrial IoT centers on sensor data collection, device control, and remote monitoring.

Many internet companies market "Internet+" projects under the IoT label, causing confusion about the true positioning of IoT.

From a technical perspective, IoT is an extension of traditional industrial control networks. Modern remote monitoring needs appear in agriculture, forest fire detection, fish pond monitoring, etc.

Because of differing focus, "Internet+" projects prioritize user count and data traffic, while small‑scale IoT projects emphasize system stability, reliability, ease of development, and maintainability over long lifecycles.

Thus, the architecture design for "Internet+" and industrial IoT differs significantly; this article focuses on the latter.

Concept and Features of Industrial‑Grade IoT

Industrial‑grade IoT refers to projects with industrial‑level characteristics applied to sectors such as agriculture, forestry, animal husbandry, and fisheries. These projects require stable, reliable devices, flexible control strategies, easy upgrades, and straightforward maintenance.

Traditional industrial control projects are large, costly, and time‑consuming, whereas IoT leverages mature internet and cloud infrastructure to deliver solutions more quickly and cheaply.

The reduced cost expands the range of applicable fields, creating a virtuous cycle of increased reliability and lower expense.

Industrial IoT Architecture Design

A typical IoT system consists of three parts: device side, cloud side (public cloud), and monitoring side.

Device‑Side Architecture

The device side handles data acquisition, process execution, and control. Devices act as IoT gateways, communicating with the cloud via HTTP (GET/PUT) for configuration or via TCP/UDP sockets for high‑volume, low‑latency data.

Functionally, the device side is divided into three layers: data acquisition & control output, process execution, and data upload & command reception.

Cloud Architecture

The cloud comprises a web front‑end, web back‑end, and middleware.

The front‑end displays real‑time process screens, data reports, logs, and diagnostic information.

The back‑end handles HTTP requests, real‑time data via WebSocket, and maps device data to reports and curves.

Middleware is essential for device communication, complex business logic, data conversion, and long‑running services.

Monitoring‑Side Architecture

Monitoring can be done via PC, mobile, or tablet. A dedicated app enables remote access beyond the web front‑end.

The monitoring stack typically consists of a UI layer and a data communication layer.

Summary

Beyond functional requirements, architecture must consider reliability, scalability, and maintainability. Different industries share many technical components but require customized logic and UI, making modular, configurable platforms essential.

General IoT Middleware Platform Architecture

The platform targets cross‑industry reuse, providing a common runtime for multiple projects.

1. Embedded Data Configuration (YFIOs) Architecture

YFIOs follows a three‑tier design: driver layer (physical interfaces), strategy layer (system and user policies), and core layer (memory databases IODB for point data and IOBC for block data). It supports .NET‑based driver and strategy development, dynamic driver replacement, remote upgrade, and integrates with a HMI component (YFHMI).

2. Cloud Middleware (YFCloud) Architecture

YFCloud extends YFIOs to a networked version, removing the IODC database and simplifying the driver layer to TCP/IP sockets. It includes a WebSocket server and manages projects via templates and APIs.

3. General IoT Platform Architecture

YFIOs runs on edge gateways and communicates with YFCloud. The web front‑end offers process visualization, reports, curves, logs, parameter configuration, and camera monitoring. The back‑end provides user, role, template, and project management.

Summary

The platform’s advantage lies in its full .NET stack, reducing the need for diverse technical expertise and simplifying secondary development and maintenance.

IoT Project Case Summaries

1. Remote Home Health Monitoring

Integrates blood‑glucose, blood‑pressure, camera, temperature/humidity sensors, RFID, and 3G modules. Doctors can view data and send messages via a web portal. The modular driver architecture allows adaptation to various sensor models.

2. Agricultural Greenhouse Monitoring

Uses an IoT gateway with cameras and temperature/humidity sensors, transmitting data via Ethernet, Wi‑Fi, or 3G to a server. Users monitor crops remotely via PC, tablet, or phone.

3. Offshore Fishery Monitoring

Collects water quality via Modbus RTU, images via camera, GPS coordinates, and transmits data over GPRS to a remote server.

4. Village Wastewater Treatment Monitoring

Smart gateway connects to RS485/CAN devices, gathers data, and communicates with the server via Wi‑Fi or GPRS. The web interface shows process flow, reports, and parameter settings.

Future Directions for IoT Development

Commercial IoT focuses on consumer markets with high volume and low customization. Non‑consumer IoT, such as industrial projects, faces diverse processes, harsh environments, 24/7 reliability demands, and the need for extensibility and maintainability.

Future efforts will prioritize reliability, extract common components to minimize per‑project modifications, and leverage mature cloud services, standardized protocols, and collaborative development among vendors.