3. 多厂商设备接口调研与建模
在多厂商设备集成的项目里，最容易被低估、却最容易导致返工的一步，不是写代码，而是把“现场到底有什么设备、每台设备能提供什么接口、这些接口之间能不能对上”这件事调研清楚并建模。很多集成失败并非协议不会写，而是调研阶段漏掉了一台设备的固件版本、少记了一个接口的鉴权方式，或者把“支持 Modbus”笼统当成“支持 Modbus TCP 且寄存器地址一致”。本节要解决的就是：如何把一堆来自不同厂商的设备，整理成一份可支撑后续开发、测试和验收的结构化模型。
一、设备清单梳理：从“有什么”到“能做什么”
设备清单不是简单的资产台账，它要同时承载“身份信息”和“能力线索”。建议按三层字段组织：
- 身份层：设备名称、厂商、型号、序列号、固件/软件版本、所在位置（车间/机柜/工位）、责任人。
- 网络层：IP 地址、端口、MAC、通信协议（Modbus TCP、OPC UA、MQTT、HTTP/REST、Profinet、串口 RS-485 等）、是否经过网关。
- 能力层：可读/可写点位、数据点表、采样周期、单位、量程、状态字、报警字、鉴权方式、并发连接数限制。
梳理时有一个实用原则：先按“接口”而不是按“设备”建行。一台 PLC 可能同时暴露 Modbus TCP 和 OPC UA 两个接口，如果按设备建一行，后续做接口能力矩阵时就会丢失粒度。示例：某产线有 3 台设备——A 厂商 PLC（Modbus TCP，支持 500 个保持寄存器）、B 厂商电表（Modbus RTU 经网关转 TCP，支持 40 个寄存器）、C 厂商机器人（OPC UA，支持 200 个节点）。按接口建行后，清单里就是 4 条接口记录（PLC 的 Modbus TCP、电表的网关 TCP、机器人的 OPC UA，以及网关自身的配置接口）。
二、接口能力矩阵：把“能不能对上”变成可查的表
接口能力矩阵是本节的核心建模产物。它的行是“接口”，列是“能力维度”，单元格填具体值或“支持/不支持/待确认”。推荐的能力维度包括：
- 协议与传输：协议名、传输层（TCP/UDP/串口）、端口、是否加密（TLS/证书）。
- 数据模型：点位数量、数据类型（bool/int16/float32/string）、字节序（大端/小端）、寄存器映射方式（连续/离散）。
- 访问方式：轮询/订阅/事件推送、最小采样周期、是否支持批量读、单次最大读取长度。
- 安全与鉴权：无鉴权/用户名密码/Token/证书、是否支持只读账号。
- 约束：最大并发连接数、是否允许跨网段、是否需要专用网关。
矩阵的价值在于“一眼看出冲突”。例如：采集端要求 200 ms 轮询 300 个点位，而某电表接口单次最大读取 40 个寄存器、最小周期 500 ms，那么即使协议都能通，吞吐也不满足，必须在建模阶段标记为“能力不足”，而不是等到联调才发现。
三、兼容性需求分析：把冲突分成三类
有了矩阵，兼容性分析就不再是“感觉能通”，而是逐维度比对。建议把每个接口的每个维度与采集端/平台端的需求做差，得到三类结论：
- 可直接集成：协议、点位、周期、鉴权全部满足。例如 PLC-A 的 Modbus TCP 支持 100 ms 轮询、500 个寄存器，采集端要求 200 ms、300 个点位，余量充足。
- 需改造或加中间层：协议能通但能力不足。例如电表-B 单次最多读 40 个寄存器、最小周期 500 ms，而需求是 300 点位/200 ms。可行方案是分组轮询：把 300 个点位拆成 8 组，每组 40 个，轮询周期设为 500 ms，整体刷新时间约 4 s；若业务要求 200 ms，则必须更换支持批量读的网关或改用支持订阅的协议。
- 待确认：字段缺失或来源不可靠。例如网关-G 的串口映射表未拿到，字节序未知。此时不能假设“应该没问题”，而应列入调研任务清单，指定责任人和确认方式（抓包、读手册、问厂商）。
这里有一个容易被忽略的维度：语义一致性。两个接口都叫“温度”，但一个单位是 0.1 ℃、另一个是 1 ℃；一个用 int16 大端、另一个用 float32 小端。协议层能通，语义层却对不上，最终数据会错得离谱。因此建模时必须把“单位、量程、数据类型、字节序、质量码定义”作为独立字段，而不是塞在备注里。
四、文档化方法：让模型可维护、可追溯
调研成果如果只停留在 Excel 里，几周后就会失真。文档化要做到三件事：
- 单一数据源：设备清单、接口能力矩阵、点位表用同一套设备 ID 和接口 ID 关联，避免“清单里叫 PLC1、矩阵里叫 A 线 PLC”这种对不上的情况。
- 版本与变更记录：每条接口记录带“确认状态（已确认/待确认/已变更）”“来源”“确认日期”。固件升级、网关更换后，必须回写并重新评估兼容性。
- 可执行的交付物：最终输出一份《接口兼容性调研表》，字段建议如下（示例）：
| 接口ID | 设备/厂商 | 协议/端口 | 点位/周期 | 鉴权 | 兼容性结论 | 确认状态 |
|---|---|---|---|---|---|---|
| IF-01 | PLC-A / 厂商A | Modbus TCP / 502 | 500 / 100ms | 无 | 可直接集成 | 已确认（手册 v2.3） |
| IF-02 | 电表-B / 厂商B | Modbus TCP / 502 | 40 / 500ms | 无 | 需分组轮询 | 已确认（现场抓包） |
| IF-03 | 机器人-C / 厂商C | OPC UA / 4840 | 200 / 订阅 | 证书 | 可直接集成 | 已确认（厂商文档） |
| IF-04 | 网关-G / 厂商D | HTTP / 80 | 映射表 | 密码 | 待确认 | 待确认（缺映射表） |
最后，建模的粒度要与后续开发对齐。如果采集程序按“设备 + 点位”组织，那么模型里就要有稳定的点位 ID；如果平台按“接口 + 采集任务”调度，那么模型里就要有接口 ID 和任务分组。调研阶段多花半天把字段设计清楚，后续开发、测试和验收就能少花几天去补数据。设备清单、接口能力矩阵、兼容性结论和确认状态，这四样东西合在一起，才构成一份真正能支撑多厂商集成的接口模型。