工业IoT网关设计：从协议解析到边缘计算

Why Build Our Own Gateway?

Anyone working in industrial IoT knows that the gateway is the “throat” of the entire system — it connects to various devices below and to the cloud platform above. Whether the gateway is stable directly determines whether the entire system is stable.

At first, we tried to use off-the-shelf gateways. We tested several — but either they didn’t support enough protocols, had weak customization capabilities, were too expensive, or lacked stability. Finally we decided: let’s build our own.

We stepped in many pitfalls along the way, and accumulated a lot of experience. Today let’s talk about how an industrial-grade IoT gateway should be designed.

Overall Architecture: Four Layers

Our gateway’s overall architecture has four layers:

┌──────────────────────────────────────┐
│        Cloud Access Layer            │
│  MQTT / HTTP / Resume / Encryption   │
├──────────────────────────────────────┤
│        Edge Computing Layer          │
│  Rule Engine / Data Cleaning /       │
│  Local Alerts / Script Engine /      │
│  Local Storage                       │
├──────────────────────────────────────┤
│        Protocol Adaptation Layer     │
│  Modbus / OPC UA / MQTT / Custom     │
│  Driver Framework / Plugin System    │
├──────────────────────────────────────┤
│        Hardware Abstraction Layer    │
│  Serial / Ethernet / DI-DO / 4G /    │
│  WiFi / Platform Independence        │
└──────────────────────────────────────┘

Let’s go through each layer.

Hardware Layer: What Platform to Choose?

Hardware is the foundation of the gateway. The platform you choose determines performance, power consumption, price, and stability.

We tried several options:

Option 1: Raspberry Pi

Advantages: cheap, great ecosystem, fast development. But in industrial scenarios, there are many problems:

• Not industrial-grade, narrow temperature range (0~60°C), easily crashes in summer workshops.
• No hardware watchdog — if it dies, it stays dead, no auto-recovery.
• SD cards wear out easily — with frequent reads/writes in industrial environments, they fail in a few months.

Conclusion: Good for prototypes, not for production.

Option 2: ARM Industrial Boards

Like Allwinner or Rockchip industrial-grade chips. Advantages: strong performance, reasonable price, can run Linux.

Disadvantages:

• Industrial-grade boards aren’t cheap.
• Peripheral interfaces need to be expanded yourself.
• Ecosystem isn’t as good as Raspberry Pi, drivers need tuning.

Option 3: MCU + RTOS

Like STM32 + FreeRTOS. Advantages:

• Industrial-grade, stable and reliable.
• Low power consumption, cheap.
• Good real-time performance.

Disadvantages:

• Limited performance, can’t run complex edge computing.
• Harder development, less rich ecosystem than Linux.

Our final choice: dual architecture:

• Lite version: MCU + RTOS, for simple data collection scenarios — low cost, high stability.
• Pro version: ARM + Linux, for scenarios requiring edge computing and complex protocols — powerful, extensible.

Both versions share the upper-layer protocol stack and business logic, with hardware abstraction at the bottom — so maintenance costs don’t explode.

Protocol Adaptation Layer: The Most Painful Part

What’s the biggest headache in industrial sites? Too many protocols.

Different equipment, different manufacturers, different eras — all use different protocols. Modbus, OPC UA, Profinet, EtherNet/IP, CAN, various proprietary protocols… writing integration code for each one would drive you crazy.

Our approach: driver framework + plugin-based protocols.

Driver Framework

First, abstract a unified driver interface. No matter what protocol, it implements the same interface:

• connect(): connect to device
• disconnect(): disconnect
• read(addr, type): read data
• write(addr, type, value): write data
• subscribe(addr, callback): subscribe to data changes

This way, upper-layer business logic only calls the unified interface and doesn’t care what protocol is underneath.

Plugin-Based Protocols

Each protocol is implemented as an independent plugin (dynamic library/.so file). Load whatever protocols you need — don’t load what you don’t need, saving memory.

Currently supported protocols:

• Modbus RTU/TCP: Most common, supports function codes 01/02/03/04/05/06/15/16.
• OPC UA: Used by more and more new devices, supports subscriptions and method calls.
• MQTT: Some smart devices output MQTT directly, can integrate straight away.
• TCP custom protocols: Many old devices use manufacturer-specific TCP protocols — we provide scriptable protocol parsing.
• DL/T645: Used by electric meters.
• GB/T 19582: Used by PLCs.

Adding new protocols is easy — just write a plugin following the driver interface, no need to modify core code.

One Pitfall: Protocol Docs Don’t Match Reality

This is the most common pitfall in industrial protocols — the protocol documentation from the manufacturer doesn’t match the actual device.

For example:

• Docs say register addresses start at 40001, but actually they start at 0.
• Docs say data is big-endian, but it’s actually little-endian.
• Docs say a register exists, but reading it returns all zeros.
• Docs say a function code is supported, but it’s not.

Lesson: Don’t fully trust documentation — always test with real equipment. And build fault tolerance — if you can’t read some data, don’t crash. Log it and keep running.

Edge Computing Layer: Why Do Gateways Need “Computing”?

Many people think a gateway is just “data passthrough” — collect device data, send it to the cloud, done.

But in real projects, pure passthrough has many problems:

• High traffic costs: If data volume is large and everything goes to the cloud, 4G data fees are expensive.
• Poor real-time performance: Alerts wait for data to reach the cloud before being judged — high latency.
• Strong network dependency: If the network goes down, nothing works.
• Cloud pressure: With many devices, massive data all going to the cloud puts huge processing pressure on the cloud.

So we built edge computing into the gateway, offloading some computation to the gateway locally.

1. Data Cleaning and Downsampling

Not all data needs to go to the cloud. For example, temperature data sampled once per second — but reporting an average once per minute is enough.

The gateway processes locally first:

• Downsampling: High-frequency collection, low-frequency reporting.
• Outlier filtering: Obviously unreasonable data (like temperature suddenly jumping to 1000°C) is discarded.
• Change-based reporting: Don’t report if data hasn’t changed — only report when change exceeds a threshold.

This reduces reported data volume to 1/10 or less of the original, drastically saving traffic and cloud costs.

2. Rule Engine

The gateway can run a rule engine locally for real-time judgment and alerts.

For example:

• Temperature exceeds 80°C → trigger alert, local audio-visual alarm, simultaneously push to cloud.
• Device no data for 5 consecutive minutes →判定 offline, log it.
• Current suddenly spikes → predict equipment failure, alert in advance.

These judgments happen locally, in milliseconds — truly real-time, no network dependency.

3. Local Storage + Resume from Breakpoint

Unstable networks are the norm in industrial sites. The gateway must be able to store data locally — keep storing when offline, then upload when network is restored.

Our gateway uses SQLite for local storage, capable of storing 3+ months of data. Resume-from-breakpoint uses idempotent processing to ensure no duplicate reports.

4. Script Engine

Some customers have special calculation logic, like:

• Combining values from several registers to calculate a metric.
• Making complex judgments based on certain conditions.
• Linking with other local devices.

This logic is different for every customer — you can’t build it all into the firmware. So we built a script engine that supports custom logic written in Lua. Customers can write their own scripts and upload them to the gateway to run.

This greatly increases the gateway’s flexibility — many customization needs don’t require firmware changes, just a script.

Cloud Access Layer: How to Ensure Reliable Data Transmission?

Communication between gateway and cloud seems like just sending MQTT messages, but there’s a lot to it.

1. Why MQTT?

MQTT is the de facto standard for IoT scenarios, with clear advantages:

• Lightweight, low overhead.
• Supports QoS, guarantees reliable message delivery.
• Pub-sub model, flexible.
• Long connection, good real-time performance.

We use MQTT as the main communication protocol, with HTTP for auxiliary tasks (like firmware upgrades, configuration下发).

2. Key Points for Reliable Transmission

• QoS 1: Important data uses QoS 1 (at least once delivery). Non-critical data uses QoS 0 to save bandwidth.
• Heartbeat mechanism: Send heartbeat packets periodically to detect connection health. Auto-reconnect on disconnection, with exponential backoff to avoid hammering the server with frequent reconnections.
• Message caching: Messages that can’t be sent are stored locally, then sent when connection is restored.
• Data encryption: TLS encrypted transmission for data security. This is a hard requirement in government and enterprise projects.

3. One Pitfall: Carrier NAT Timeout

On 4G networks, carriers’ NAT tables have timeout periods — if a connection is idle too long, the NAT entry gets deleted and the connection breaks, but the MQTT client might not know.

Solution: Set the heartbeat interval shorter than the NAT timeout. Generally 60 seconds is safe. Too short wastes power and data, too long risks disconnection.

Remote Management: How to Manage Hundreds or Thousands of Gateways?

As projects grow and gateway数量 multiplies, management becomes a problem. You can’t go on-site to configure every gateway, right?

So remote management capabilities are essential.

1. Remote Configuration

All configurations can be pushed remotely: which points to collect, collection frequency, reporting frequency, alert rules… all can be changed in the cloud, and the gateway automatically applies changes.

2. Remote Diagnostics

When a gateway has issues, you don’t need to go on-site — you can diagnose remotely:

• Check gateway status: CPU, memory, disk, network.
• Check device connection status: which devices are online, which are offline.
• Check logs: remotely pull gateway logs for troubleshooting.
• Remote debugging: you can even remotely log into the gateway’s command line for direct debugging.

3. OTA Upgrades

Firmware upgrades are essential. When you find bugs or add features, you can’t go on-site to flash firmware on every gateway.

Key points for OTA upgrades:

• Differential upgrades: Only transfer the delta, saving bandwidth.
• Resume from breakpoint: If the upgrade package download is interrupted by network loss, resume next time.
• Dual partitions: The gateway has two system partitions. During upgrade, write to the other partition. If upgrade fails, switch back to the original version — guarantees you can recover even if it “bricks.”
• Gray release: Upgrade a small number of gateways first, roll out fully if no issues — avoid全军覆没 if something goes wrong.

Stability: The Lifeline of Industrial Gateways

Finally, the most important point: stability.

In industrial scenarios, gateways might be installed in无人看管 (unattended) locations, running for years at a time. If something goes wrong, nobody’s there to restart it — so it must be rock solid.

We do these things to ensure stability:

1. Hardware watchdog: If the program crashes, hardware auto-restarts. Software watchdogs aren’t reliable enough — you must have hardware.
2. Process supervision: If the main process dies, the supervisor process restarts it automatically.
3. Resource monitoring: Monitor CPU, memory, disk usage. Alert and auto-handle when thresholds are exceeded (e.g., clean logs, restart processes).
4. Fault-tolerant design: If any device has issues or any protocol parsing fails, it must not affect the entire gateway. Errors must be isolated — one failure can’t take everything down.
5. Long-run testing: Before each release, run at least 72 hours of stress testing to check for memory leaks or performance degradation.

Closing Thoughts

Building an industrial gateway seems simple — isn’t it just collecting data and sending it? But when you actually build one, you discover there are so many details.

Full protocol support, sufficient performance, strong stability, convenient management, affordable price… none of these are easy.

But the gateway is the foundation of the entire industrial IoT system. If the gateway is stable, the platforms and applications above it matter. If the gateway isn’t stable, no matter how pretty the dashboards or how powerful the algorithms, they’re castles in the air.

If you’re also building industrial IoT gateways, or selecting one, I hope this article gives you some reference.