网关要做的是建模，不只是搬运
这类网关南向用设备原生协议采集数据，北向按节点图对外提供服务。做法上的关键差别在建模：好的做法是按设备类型定义对象类型，把温度、转速与状态组织在同一对象下，为每个量补上工程单位、量程与数据质量，让上层按类型解析而不依赖地址表；差的做法是把寄存器原样列成变量清单，虽然换了协议，语义与安全都没补上。除建模之外，还要规划采样与订阅策略、容量上限、证书与用户身份、配置备份与固件升级，否则网关本身会成为新的单点故障。
基本信息
| 南向 | 按设备原生协议采集，做主站或从站 |
|---|---|
| 北向 | 按节点图对外提供服务，可浏览与订阅 |
| 建模 | 按设备类型定义对象类型，避免扁平变量清单 |
| 数据质量 | 传递质量戳与时间戳，上层可判断有效性 |
| 容量 | 点数、订阅数与刷新周期上限需核算 |
| 安全 | 加密端点、用户身份与访问控制 |
| 运维 | 配置可导出备份，固件可升级，支持诊断日志 |
| 可靠性 | 批量部署需考虑冗余与故障恢复 |
典型使用场景
- 多协议现场统一接入：把不同协议设备统一为一种对外接口
- 按设备类型建模：同类设备复用类型定义，新设备只需实例化
- 上云与上层集成：提供带身份与加密的接口，满足审计要求
- 替换老上位机：保留现场设备，只替换接入层
- 安全收敛：在网关处终结旧协议的开放端口
- 批量部署：用配置模板统一命名与建模规则
建模做法对照
| 做法 | 效果 | 后果 |
|---|---|---|
| 按类型建模 | 设备结构清晰，可复用 | 前期投入略高，后期维护成本低 |
| 原样暴露寄存器 | 变量清单扁平 | 上层仍需地址表，语义缺失 |
| 补单位与量程 | 上层可直接换算与判断 | 需逐点核对，工作量大 |
| 不带质量戳 | 坏值与正常值无法区分 | 统计与报警受污染 |
| 统一命名规则 | 批量部署与检索高效 | 规则需事先约定 |
| 不规划容量 | 点数增加后性能下降 | 表现为延迟与丢通知 |
部署与运维要点
部署与运维要点
# 1 建模优先：按设备类型定义对象类型，同名类型的设备复用定义
# 2 补全语义：工程单位、量程、数据质量与时间戳都要传递到上层
# 3 容量核算：点数、订阅数与刷新周期留出余量，并做压力验证
# 4 安全：只开放加密端点，配置用户身份并按角色分配权限
# 5 备份与升级：配置文件导出归档，固件版本纳入变更管理
# 6 可靠性：批量部署时考虑冗余与快速更换，避免单点故障网关很容易变成新的单点：现场多台设备都依赖它对外通信，部署时应把配置备份、备件与恢复流程一起规划。
网关若不传递数据质量与时间戳，坏值会与正常值混在一起进入报表，做统计与报警时需要额外的怀疑成本。