## 1. 文档目标
本文档用于指导基于 .NET 技术栈建设一套可落地的工业 IoT Edge 边缘程序。该程序面向工业现场数据采集、平台远程控制、边缘自治运行、自动升级和多协议接入场景，满足以下核心目标：
1. 支持边缘设备心跳包与运行状态检测。
2. 支持平台下发启动、停止等控制指令。
3. 支持边缘程序自动更新与灰度发布。
4. 支持平台侧统一配置通讯驱动、标签点位与自定义结构体。
5. 支持常见工业协议和设备，包括 API、OPC UA、OPC DA、串口、Modbus RTU/TCP、西门子主流 PLC。
6. 具备 IoT Edge 场景下的离线缓存、远程部署、模块化扩展和安全管控能力。
## 2. 建设范围
### 2.1 业务范围
本系统聚焦边缘侧运行平台与采集网关能力，不直接承担企业级 SCADA、MES、ERP 等完整上层应用职能，而是作为“边缘数据接入与控制执行底座”对接上层平台。
### 2.2 功能范围
- 边缘节点注册、身份识别、版本管理。
- 运行心跳、资源状态、模块状态上报。
- 平台指令控制：启动、停止、重启、重新加载配置。
- 设备连接器管理：API、OPC UA、OPC DA、串口、Modbus RTU/TCP、西门子 PLC。
- 标签点位与采集计划管理。
- 自定义结构体（结构化点表）配置与解析。
- 本地缓存、断点续传、离线补传。
- 自动更新、升级校验、回滚策略。
- 日志、告警、追踪、审计。
## 3. 总体架构
建议采用“云边协同 + 边缘模块化 + 驱动插件化”的架构。
```text
┌─────────────────────────────────────────────────────────────┐
│ 云端平台 / 控制中心 │
│ 设备管理 配置中心 指令中心 升级中心 监控告警 数据接收 │
└─────────────────────────────────────────────────────────────┘
│
│ HTTPS / MQTT / AMQP
▼
┌─────────────────────────────────────────────────────────────┐
│ IoT Edge Runtime / Edge Host │
│ 负责部署、模块生命周期、模块路由、设备身份、安全策略 │
├─────────────────────────────────────────────────────────────┤
│ Edge Agent（可选依赖 IoT Edge Runtime 能力） │
│ Edge Hub （消息路由、离线缓存、云边通信） │
├─────────────────────────────────────────────────────────────┤
│ Device Gateway Module（核心边缘业务模块，.NET） │
│ ├─ Heartbeat Service 心跳与状态检测 │
│ ├─ Control Service 平台控制执行 │
│ ├─ Config Service 通讯/标签/结构体配置管理 │
│ ├─ Collector Scheduler 采集调度 │
│ ├─ Protocol Adapters 协议驱动适配层 │
│ ├─ Data Processor 数据转换/质量码/标准化 │
│ ├─ Local Cache 本地缓存/补传 │
│ ├─ Update Coordinator 升级协调 │
│ └─ Observability 日志/指标/追踪 │
├─────────────────────────────────────────────────────────────┤
│ Driver Plugins │
│ API / OPC UA / OPC DA / Serial / Modbus / Siemens PLC │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ PLC / 仪表 / 传感器 / 第三方系统 │
└─────────────────────────────────────────────────────────────┘
```
## 4. 技术选型建议
### 4.1 开发平台
- 开发语言：C# 12+
- 框架版本：.NET 8 LTS
- 部署方式：Linux 容器优先，兼容 Windows 边缘主机
- 应用形态：IoT Edge Module / Worker Service
- 通讯基础：MQTT / HTTPS / AMQP（由 IoT Edge Hub 或平台 SDK 承担）
### 4.2 推荐技术组件
- 依赖注入Microsoft.Extensions.DependencyInjection
- 后台服务Microsoft.Extensions.Hosting
- 配置Microsoft.Extensions.Options
- 日志Serilog
- 本地数据库SQLite 或 LiteDB
- 缓存队列：本地文件队列 + SQLite 索引
- JSON 序列化System.Text.Json
- 工业协议库：按协议选成熟库或厂商 SDK 封装
- 容器镜像：Docker
- 部署与升级：Azure IoT Edge Deployment + Device Update 能力思想
## 5. 功能设计
## 5.1 心跳包与状态检测
### 5.1.1 目标
边缘程序需要按周期向平台发送运行心跳，便于平台判断节点是否在线、是否异常、是否需要介入处理。
### 5.1.2 心跳内容
建议心跳载荷包含：
- 设备唯一标识edgeDeviceId
- 节点名称edgeName
- 程序版本appVersion
- 配置版本configVersion
- 运行状态Running / Degraded / Stopped / Updating / Error
- 启动时间startedAt
- 当前时间reportedAt
- 资源指标：CPU、内存、磁盘、网络
- 连接状态：平台连接状态、各驱动连接状态
- 采集指标：采集点数、采集成功率、最新采集时间
- 缓存指标：待上传条数、补传状态
- 告警摘要：当前告警数量、最高级别
### 5.1.3 设计要点
- 心跳周期建议 10~30 秒，可配置。
- 状态检测分为“进程存活”“模块健康”“协议连接”“任务执行”四层。
- 本地保留最近 N 次心跳快照，便于故障排查。
- 当上行链路中断时，心跳数据应至少保留摘要日志，以便恢复后补充诊断。
## 5.2 平台控制：启动、停止
### 5.2.1 控制方式
平台通过云端下发控制命令，边缘模块接收后执行：
- 启动采集任务
- 停止采集任务
- 重启指定驱动实例
- 重新加载配置
- 重启边缘服务
- 执行诊断命令（如测试连接）
### 5.2.2 控制通道
建议使用以下两类通道之一：
1. IoT Edge / IoT Hub 的云到设备消息、模块方法或模块 Twin 期望属性。
2. 平台通过安全 API 通道推送指令，由边缘长连接客户端订阅执行。
### 5.2.3 控制设计原则
- 所有命令需带命令 ID，支持幂等执行。
- 所有命令需回执：已接收、执行中、执行成功、执行失败。
- 控制操作需审计，记录操作人、时间、参数、结果。
- 停止操作应支持细粒度范围：全局停止 / 驱动停止 / 采集组停止。
## 5.3 自动更新
### 5.3.1 升级对象
自动更新应覆盖以下对象：
- 边缘主业务模块镜像
- 协议驱动插件包
- 配置模板
- 规则引擎脚本（如果有）
### 5.3.2 升级模式
建议支持：
- 全量升级
- 灰度升级
- 分批升级
- 指定设备升级
- 指定设备组升级
### 5.3.3 升级流程
1. 平台生成升级任务。
2. 对目标设备/模块分配新版本。
3. 边缘节点下载镜像或升级包。
4. 完成完整性校验（签名/哈希）。
5. 进入维护窗口或安全切换阶段。
6. 停止相关任务并切换到新版本。
7. 执行启动后自检。
8. 成功则上报升级成功，失败则回滚。
### 5.3.4 回滚策略
- 保留上一个稳定版本。
- 升级失败自动回滚。
- 回滚后立即上报失败原因。
- 灰度发布期间若异常率超阈值，平台停止后续批次。
## 5.4 通讯配置管理
### 5.4.1 配置目标
平台能够通过统一数据模型描述不同协议设备的连接参数、轮询参数、超时重试、数据编码与采集策略。
### 5.4.2 通讯类型
#### API
- 支持 REST API、HTTP WebHook、可选认证方式。
- 支持 GET/POST、自定义 Header、Token、签名。
- 支持 JSON/XML/文本解析。
#### OPC UA
- 支持端点地址、安全策略、证书配置。
- 支持节点订阅与轮询两种方式。
- 支持命名空间、NodeId、数据类型映射。
#### OPC DA
- 适用于 Windows 场景。
- 通过专门驱动宿主或兼容层封装。
- 建议作为可选模块部署，降低主程序耦合。
#### 串口
- 支持端口号、波特率、数据位、停止位、校验位。
- 支持命令模板、报文帧定义、超时重试。
#### Modbus RTU/TCP
- 支持站号、功能码、寄存器地址、数据长度。
- 支持字节序、字序、缩放系数、数据类型映射。
#### 西门子 PLC
- 支持 S7-200 SMART、S7-1200、S7-1500 等主流系列。
- 支持 IP、Rack、Slot、DB 地址、位地址、字地址读取。
- 支持批量读取和分组优化。
### 5.4.3 配置结构建议
建议平台统一下发如下层级：
- 边缘节点
- 驱动实例
- 设备实例
- 采集组
- 标签点
- 自定义结构体模板
## 5.5 标签配置与自定义结构体
### 5.5.1 标签配置
标签用于描述采集点位，建议包含：
- tagCode
- tagName
- protocolType
- address
- dataType
- scale
- unit
- readMode
- scanInterval
- qualityRequired
- transformRule
- alarmRule
### 5.5.2 自定义结构体
为适配复杂设备数据块，应支持结构体模板。例如：
- 电机状态结构体
- 产线工单结构体
- 配方结构体
- 报警数组结构体
结构体需支持：
- 嵌套字段
- 偏移量定义
- 字节序设置
- 数组字段
- 枚举映射
- 时间类型转换
### 5.5.3 建议模型示例
```json
{
"structCode": "MotorStatus",
"name": "电机状态结构体",
"fields": [
{ "name": "Run", "offset": 0, "type": "Bool" },
{ "name": "Fault", "offset": 1, "type": "Bool" },
{ "name": "Speed", "offset": 2, "type": "Int16", "scale": 0.1 },
{ "name": "Temperature", "offset": 4, "type": "Int16", "scale": 0.1 }
]
}
```
## 6. 模块拆分设计
建议按职责拆分为以下模块。
### 6.1 Edge Host Adapter
职责：对接 IoT Edge Runtime、Edge Hub、平台身份认证与模块运行上下文。
### 6.2 Configuration Module
职责：
- 接收平台下发配置。
- 校验配置合法性。
- 生成运行时配置快照。
- 支持版本管理与热更新。
### 6.3 Driver Runtime Module
职责：
- 统一加载各类协议适配器。
- 管理驱动实例生命周期。
- 提供标准化读写接口。
### 6.4 Collection Scheduler Module
职责：
- 根据标签扫描周期调度采集。
- 做批量优化、合并读。
- 对失败任务执行重试和熔断。
### 6.5 Data Processing Module
职责：
- 原始值转标准值。
- 质量码附加。
- 时间戳标准化。
- 结构体解包。
- 组包上传。
### 6.6 Control Execution Module
职责：
- 接收控制命令。
- 命令幂等校验。
- 执行启动/停止/重载/诊断。
- 结果回执。
### 6.7 Update Module
职责：
- 接收升级计划。
- 执行版本切换。
- 做升级前后健康检查。
- 执行失败回滚。
### 6.8 Storage Module
职责：
- 存储配置快照。
- 存储采集缓存。
- 存储命令记录、审计记录。
- 存储故障诊断信息。
## 7. 核心数据流
## 7.1 配置下发流
平台配置中心 → 边缘配置服务 → 配置校验 → 版本落盘 → 驱动热重载 → 结果回执。
## 7.2 数据采集流
驱动连接设备 → 采集调度执行 → 原始数据读取 → 数据标准化 → 本地缓存/直接上报 → 平台接收。
## 7.3 控制执行流
平台下发命令 → 边缘命令接收 → 幂等校验 → 调用服务/驱动 → 执行结果回执 → 审计记录。
## 7.4 升级流
平台发布版本 → 设备命中升级策略 → 下载/拉取新镜像 → 校验 → 切换 → 自检 → 成功/回滚。
## 8. 配置模型设计建议
建议采用统一 JSON 配置模型，分为如下层级：
```json
{
"edgeDeviceId": "EDGE-001",
"configVersion": "2026.03.16.1",
"heartbeat": {
"intervalSeconds": 15
},
"drivers": [
{
"driverId": "modbus-main",
"protocol": "ModbusTcp",
"enabled": true,
"connection": {
"host": "192.168.1.10",
"port": 502,
"timeoutMs": 3000
},
"devices": [
{
"deviceId": "meter-01",
"stationNo": 1,
"tags": [
{
"tagCode": "VoltageA",
"address": "40001",
"dataType": "Float",
"scanInterval": 1000
}
]
}
]
}
]
}
```
## 9. 非功能设计
## 9.1 可用性
- 支持断网自治运行。
- 支持自动重连。
- 支持服务异常自动恢复。
- 支持关键任务隔离，避免单驱动故障影响全局。
## 9.2 性能
- 支持数千到数万标签点采集（取决于硬件与协议组合）。
- 支持不同采样周期混合调度。
- 支持批量读取与连接池复用。
## 9.3 安全
- 所有平台通信需 TLS 加密。
- 配置下发需签名校验。
- 命令通道需鉴权与授权。
- 敏感配置如账号密码需加密存储。
- 驱动插件加载需做白名单控制。
## 9.4 可观测性
- 结构化日志。
- 指标采集（CPU、内存、采集成功率、队列长度、连接状态）。
- TraceId 串联控制与采集链路。
- 支持日志分级与远程拉取。
## 10. 部署设计
建议优先基于 IoT Edge 模式部署：
- 使用 IoT Edge Runtime 管理模块生命周期。
- 使用 Edge Hub 做模块间路由与离线缓存。
- 使用 Deployment Manifest 做模块部署与期望属性配置。
- 使用模块 Twin 管理动态配置和运行状态。
- 使用设备分层分组做批量升级与灰度发布。
## 11. 实施建议
### 11.1 第一阶段重点
- 打通边缘主程序骨架。
- 实现心跳、配置、控制三大基础能力。
- 优先落地 Modbus TCP、OPC UA、API 三类通用协议。
- 建立标签与结构体统一模型。
### 11.2 第二阶段重点
- 增加串口、Modbus RTU、西门子 PLC 驱动。
- 实现升级编排与灰度发布。
- 强化缓存补传、监控告警与审计。
### 11.3 第三阶段重点
- 增加 OPC DA 兼容支持。
- 优化高点位规模性能。
- 完善运维工具链、远程诊断与自动化测试。
## 12. 风险与应对
| 风险 | 说明 | 应对 |
|---|---|---|
| 协议差异大 | 各协议模型差异明显 | 采用统一驱动接口 + 协议插件化 |
| OPC DA 依赖 Windows | 跨平台兼容难 | 独立为专用驱动模块 |
| 大规模点位性能瓶颈 | 扫描与上传压力大 | 批量读取、分组调度、缓存分层 |
| 升级失败影响生产 | 现场设备升级风险高 | 灰度发布、维护窗口、自动回滚 |
| 配置复杂度高 | 平台建模成本大 | 建立统一配置模板与校验规则 |
## 13. 结论
该方案基于 .NET 8 和 IoT Edge 的模块化特性，能够高效支持工业现场的边缘数据采集、设备接入、远程控制以及自动升级需求。整体设计的核心着眼于以下几点： - 通过统一的配置模型抽象多协议设备，提升系统的兼容性。 - 利用插件化驱动框架，显著降低协议扩展的开发成本。 - 借助 IoT Edge 的部署能力、模块生命周期管理与离线通信功能，强化系统的可运维性。 - 通过本地缓存、状态监控和回滚机制，进一步提升现场系统的稳定性。 此设计方案具备很强的可实施性，可为后续的详细设计和编码工作提供坚实基础。