📚 课程目录第4章软件架构与系统组成

4. 软件架构与系统组成

工业网关的软件架构决定了它能否在严苛的现场环境中长期稳定运行。与消费级路由器不同，工业网关需要同时承担协议转换、数据采集、边缘计算、远程运维等多重职责，因此其软件系统通常采用分层解耦的设计思路：底层是嵌入式操作系统，中间是协议栈与边缘计算框架，上层是远程管理组件。理解这四层之间的协作关系，是进行量产部署和故障排查的基础。

一、嵌入式操作系统：稳定性的地基

工业网关的操作系统选择直接影响启动速度、实时性和维护成本。主流方案分为三类：以 Linux 为代表的通用嵌入式系统、以 FreeRTOS/Zephyr 为代表的实时操作系统（RTOS），以及厂商定制的轻量级系统。Linux 的优势在于生态完善、协议栈丰富、支持容器化边缘应用；RTOS 的优势在于确定性调度和极小资源占用，适合硬实时采集场景。

在量产部署中，操作系统层需要重点关注以下配置：

只读根文件系统：将根分区挂载为只读，配合 overlayfs 或 tmpfs 保存运行时数据，避免异常断电导致文件系统损坏。
看门狗与自动恢复：硬件看门狗配合 systemd 或 init 脚本，在关键进程崩溃时自动重启。
启动优化：裁剪无用服务，将启动时间控制在 10～30 秒内，满足现场快速上电需求。
内核参数调优：调整网络缓冲区、文件句柄数、TCP 重传参数，适应高并发采集。

# 典型只读根文件系统挂载配置 /etc/fstab
/dev/mmcblk0p2  /        ext4    ro,noatime          0 1
tmpfs           /tmp     tmpfs   defaults,size=64M   0 0
tmpfs           /var/log tmpfs   defaults,size=32M   0 0
overlay         /etc     overlay lowerdir=/etc,upperdir=/data/etc,workdir=/data/work 0 0

二、协议栈：南北向数据通道

协议栈是工业网关最核心的功能组件，通常分为南向协议和北向协议。南向协议负责与现场设备通信，包括 Modbus RTU/TCP、CANopen、Profinet、EtherCAT、OPC UA、DL/T 645 等；北向协议负责与云平台或上位机通信，包括 MQTT、HTTP/HTTPS、OPC UA、IEC 104 等。

协议栈的设计要点在于解耦与可扩展。推荐采用“协议驱动 + 统一数据模型”的架构：每个协议实现为独立驱动，采集到的数据统一映射为内部点表模型，再由北向模块按需上报。这样新增协议时只需增加驱动，不影响其他模块。

协议类型	典型协议	传输层	部署关注点
南向串口	Modbus RTU、DL/T 645	RS-485/RS-232	波特率、校验位、超时重试
南向现场总线	CANopen、Profinet	CAN/Ethernet	周期扫描、节点掉线检测
南向工业以太网	Modbus TCP、OPC UA	TCP	连接数、会话保持、证书
北向云接入	MQTT、HTTPS	TCP/TLS	断线重连、QoS、消息缓存

三、边缘计算框架：从采集到决策

边缘计算框架位于协议栈之上，负责对采集数据进行清洗、聚合、计算和本地决策。典型能力包括：规则引擎、流式计算、数据缓存、本地数据库和容器化应用运行时。

在量产部署中，边缘计算框架需要解决三个问题：资源隔离、任务调度和数据持久化。资源隔离通常通过 cgroup 或容器实现，防止某个边缘应用占用过多 CPU 导致采集任务延迟；任务调度需要保证高优先级采集任务优先执行；数据持久化则依赖本地时序数据库或环形缓冲区，在网络中断时暂存数据，恢复后补传。

典型边缘计算数据流：现场设备 → 协议驱动采集 → 点表映射 → 规则引擎判断 → 本地告警/控制 → 数据缓存 → 北向 MQTT 上报。整个链路中，规则引擎和缓存队列是最容易成为瓶颈的环节，部署时应重点监控其队列深度和延迟。

四、远程管理组件：量产运维的抓手

远程管理组件是工业网关区别于普通采集器的关键能力。它通常包括设备影子、远程配置、固件升级（OTA）、日志回传和远程诊断五个部分。在量产部署阶段，远程管理组件直接决定了运维效率和故障响应速度。

设备影子：在云端维护设备最新状态，即使设备离线也能查看最后上报数据。
远程配置：支持按设备、按分组下发采集规则和上报策略，避免现场逐台修改。
OTA 升级：支持差分升级、断点续传和回滚机制，升级失败自动恢复旧版本。
日志回传：按需拉取设备日志，减少现场出差成本。
远程诊断：提供 ping、traceroute、端口检测、进程状态查询等工具。

# 远程管理组件典型配置片段
remote_manage:
  mqtt_broker: "ssl://iot.example.com:8883"
  device_shadow: true
  ota:
    strategy: "delta"
    rollback: true
    max_retry: 3
  log_upload:
    level: "warning"
    max_size_mb: 20
  diagnostics:
    enable_ping: true
    enable_traceroute: true

五、四层协作关系与部署误区

这四层并非孤立存在，而是通过明确的接口协作：操作系统提供进程、网络和存储资源；协议栈通过系统调用访问串口和网络；边缘计算框架以进程或容器形式运行在操作系统之上，消费协议栈的数据；远程管理组件则通过北向通道与云端交互，同时可以控制边缘计算框架的配置和升级。

常见误区：很多团队在样机阶段把四层功能全部塞进一个进程，导致量产时无法独立升级协议驱动或边缘应用；也有团队忽略只读文件系统和看门狗配置，现场断电后设备无法启动。建议在架构设计阶段就明确各层边界，协议驱动、边缘应用和远程管理组件应支持独立部署和独立升级。

下面这张图展示了工业网关软件架构的四层组成及其数据流向，可以帮助理解各层之间的依赖关系和接口边界。

在实际量产部署中，建议按照“操作系统固化 → 协议栈验证 → 边缘框架压测 → 远程管理联调”的顺序逐层推进。每一层都要有独立的健康检查和日志输出，这样才能在出现问题时快速定位是系统资源不足、协议驱动异常、边缘任务阻塞还是远程通道中断。只有四层各司其职、接口清晰，工业网关才能在无人值守的现场长期稳定运行。