在产线数据采集的工程实践中最耗时的问题通常不是并发或存储而是协议适配。同一个车间里温度传感器说着 Modbus RTUPLC 是西门子 S7电表跑着 DLT645环保监测设备用 HJ 212SL651 同源的水文规约家族新采购的网关又是 MQTT。每接一类设备就要重新学一套报文格式、一套连接管理、一套异常语义。这种碎片化在工业物联网领域已存在二十余年——各协议诞生于不同年代与行业服务于不同的技术约束难以彼此取代。设备生命周期以十年计老仪表不会因为新协议出现而退役碎片化因此不是待消灭的错误而是必须长期共存的现实。平台层的职责是屏蔽协议差异对上层业务的影响。这句话说起来轻巧落到工程上要回答三个问题几十种协议怎么组织、接入之后怎么统一建模、新的协议怎么低成本地长出来。DC3 的答案是 36 个驱动模块加一套 Driver SDK。五类驱动五种接入问题DC3 仓库里的dc3-driver/目录下有 36 个驱动模块按场景分五类。分类不是目录学游戏——每一类对应一种真实存在的接入问题。工业协议17 个解决存量现场怎么进。Modbus TCP / Modbus RTU、OPC UA / OPC DA、Siemens S7、BACnet/IP、EtherNet/IP、Omron FINS、三菱 MELSEC、IEC 60870-5-104、IEC 61850、DNP3、DLMS、DLT645、KNX、M-Bus、SL651——从工厂自动化到电力楼宇从抄表到水利。这一类的特点是设备先于平台存在产线上的 PLC、变电站的远动装置、楼宇里的 KNX 总线都不会为一次数字化改造而更换。平台要么讲它们的语言要么放弃这批数据。IoT 协议7 个解决新部署的无线低功耗场景怎么进。MQTT、CoAP、LwM2M、HTTP、BLE、Zigbee、LoRaWAN面向电池供电、无线组网、云边协同的增量设备。与工业协议相反这一类的难点不在兼容历史而在语义对齐——同一批传感器不同接入方式在会话保持、传输开销、报文组织上各有约定平台要为它们保留一致的采集与下发语义。数据桥接5 个解决数据不在设备上怎么办。MySQL、PostgreSQL、Oracle、SQL Server、Redis——很多接入其实是把别处已落库的数据搬进来老系统的关系库、第三方平台的缓存设备数据早已存在缺的只是把它纳入统一点位模型的那一跳。基础通信5 个解决自定义协议与网络管理怎么进。TCP/UDP、Serial、SNMP、CAN、Kafka——私有规约的传输底座与网络设备的纳管通道。现场永远存在说不上名字的私有协议这一类不给协议语义给的是把任意字节流接进平台的起点。仿真调试2 个解决没有设备怎么开发。Virtual 与 Listening Virtual 不接真设备也能把整条链路跑通——Virtual 驱动按位号类型生成随机值布尔位号给出随机真假值数值位号在 0 到 100 之间取随机数是平台自测与新人上手的脚手架。需要说明36 个驱动的成熟度存在差异它们均为独立部署的微服务——每个驱动是单独的进程按需启停、按需扩容不需要的驱动不参与部署不占运行资源。独立进程不只是资源问题更是隔离问题一个驱动里的连接泄漏或内存异常被限制在自己的进程内不会顺着调用链拖垮其他协议的采集。统一建模协议差异的收敛驱动多本身不是壁垒真正的设计在模型层。DC3 用四个核心实体把所有协议翻译成同一种语言Driver驱动→ Device设备→ Profile位号模板→ Point位号无论底层是 Modbus 的寄存器地址、OPC UA 的 NodeId 还是 S7 的 DB 块偏移进到平台里都是同一个 Point 模型有数据类型、有读写标志、有采集频率、有归属租户。协议差异被封装在两层配置属性里驱动级属性描述怎么连接Modbus TCP 的 host 与 port位号级属性描述读哪里从站号 slaveId、功能码 functionCode、偏移量 offset。上层数据中心、告警引擎、AI 工具面看到的从来不是某品牌 PLC而是一组语义统一的点位。这就是协议可以碎接入模型不能碎的含义也是 36 个驱动还能被有效维护的原因——如果每个驱动各带一套上层语义36 个模块就是 36 个维护分叉。Driver SDK新增驱动的开发契约协议世界永远比驱动仓库长得快所以 DC3 提供了 Driver SDK 与配套的开发指南docs.dc3.site 的 Driver Authoring 一章。SDK 的契约可以用一句话概括驱动只拥有协议 I/O 与面向用户的属性元数据其余平台共性——注册、调度、元数据刷新、健康上报、命令处理、数据分发——全部由 SDK 与运行时承担。落到接口上SDK 定义了一组能力接口生命周期启停钩子、元数据事件监听设备与位号的增删改通知、健康检查、读写协议、命令与配置校验。功能完整的驱动实现聚合接口即可只需要部分能力的驱动可以只挑小接口实现。Modbus TCP 驱动是一个现成的标尺整个模块的 Java 源文件只有两个——一个 Spring Boot 启动类一个协议服务实现类。后者做的事全部属于协议本身维护设备连接缓存校验 host/port 与 slaveId/functionCode/offset 配置按功能码 1–4 读线圈与寄存器、按功能码 1/3 写线圈与保持寄存器外加一个务实的细节——同一设备连续 3 次连接失败后进入 60 秒退避避免一台不可达设备拖垮整个调度周期。由此新增一个驱动的工作量边界相当清楚实现协议解析与点位映射在模块配置文件里声明驱动编码与属性元数据属性编码、类型、默认值打包成镜像、起服务注册进平台就能被统一管理——不必碰调度器、不必碰消息发送、不必碰租户逻辑。对社区贡献者而言新驱动应来自真实工位的真实需求——这也是接入层保持开放结构的原因。适用范围与限制成熟度有差异。仓库的驱动 README 明确列出一批标注进行中的驱动CAN、DLMS、EtherNet/IP、IEC 104、LwM2M、MQTT、OPC DA、Zigbee其协议 I/O 尚不完整生产使用前需核对实现Modbus、OPC UA 这类高频协议经过的实战检验远多于小众协议。选型时建议先用 Virtual 驱动验证链路再接真实设备SDK 消除协议本身的复杂度。SL651、DLT645 这类行业规约通常还伴随报文加密、私有扩展等现场适配工作量SDK 解决的是工程结构问题协议内部的坑仍要开发者自己踩清单以仓库为准。驱动清单以仓库dc3-driver/目录为准新驱动在持续增加。结语36 这个数字会过时五分类也可能长出第六类但协议可以碎接入模型不能碎这条约束不会变。对接入层而言真正耐用的资产从来不是驱动清单本身而是让一个新驱动只需一个启动类、一个协议实现类和一份属性元数据就能长出来的那套契约。相关仓库与文档入口见文末。仓库GitHub pnoker/iot-dc3 · Gitee pnoker/iot-dc3GVP文档docs.dc3.siteDriver Authoring Guide· book.dc3.site · demo.dc3.site 
长河君 · 2026/9/2 6:57:10 · 阅读 1.2k 36 个驱动模块：应对协议碎片化
在产线数据采集的工程实践中最耗时的问题通常不是并发或存储而是协议适配。同一个车间里温度传感器说着 Modbus RTUPLC 是西门子 S7电表跑着 DLT645环保监测设备用 HJ 212SL651 同源的水文规约家族新采购的网关又是 MQTT。每接一类设备就要重新学一套报文格式、一套连接管理、一套异常语义。这种碎片化在工业物联网领域已存在二十余年——各协议诞生于不同年代与行业服务于不同的技术约束难以彼此取代。设备生命周期以十年计老仪表不会因为新协议出现而退役碎片化因此不是待消灭的错误而是必须长期共存的现实。平台层的职责是屏蔽协议差异对上层业务的影响。这句话说起来轻巧落到工程上要回答三个问题几十种协议怎么组织、接入之后怎么统一建模、新的协议怎么低成本地长出来。DC3 的答案是 36 个驱动模块加一套 Driver SDK。五类驱动五种接入问题DC3 仓库里的dc3-driver/目录下有 36 个驱动模块按场景分五类。分类不是目录学游戏——每一类对应一种真实存在的接入问题。工业协议17 个解决存量现场怎么进。Modbus TCP / Modbus RTU、OPC UA / OPC DA、Siemens S7、BACnet/IP、EtherNet/IP、Omron FINS、三菱 MELSEC、IEC 60870-5-104、IEC 61850、DNP3、DLMS、DLT645、KNX、M-Bus、SL651——从工厂自动化到电力楼宇从抄表到水利。这一类的特点是设备先于平台存在产线上的 PLC、变电站的远动装置、楼宇里的 KNX 总线都不会为一次数字化改造而更换。平台要么讲它们的语言要么放弃这批数据。IoT 协议7 个解决新部署的无线低功耗场景怎么进。MQTT、CoAP、LwM2M、HTTP、BLE、Zigbee、LoRaWAN面向电池供电、无线组网、云边协同的增量设备。与工业协议相反这一类的难点不在兼容历史而在语义对齐——同一批传感器不同接入方式在会话保持、传输开销、报文组织上各有约定平台要为它们保留一致的采集与下发语义。数据桥接5 个解决数据不在设备上怎么办。MySQL、PostgreSQL、Oracle、SQL Server、Redis——很多接入其实是把别处已落库的数据搬进来老系统的关系库、第三方平台的缓存设备数据早已存在缺的只是把它纳入统一点位模型的那一跳。基础通信5 个解决自定义协议与网络管理怎么进。TCP/UDP、Serial、SNMP、CAN、Kafka——私有规约的传输底座与网络设备的纳管通道。现场永远存在说不上名字的私有协议这一类不给协议语义给的是把任意字节流接进平台的起点。仿真调试2 个解决没有设备怎么开发。Virtual 与 Listening Virtual 不接真设备也能把整条链路跑通——Virtual 驱动按位号类型生成随机值布尔位号给出随机真假值数值位号在 0 到 100 之间取随机数是平台自测与新人上手的脚手架。需要说明36 个驱动的成熟度存在差异它们均为独立部署的微服务——每个驱动是单独的进程按需启停、按需扩容不需要的驱动不参与部署不占运行资源。独立进程不只是资源问题更是隔离问题一个驱动里的连接泄漏或内存异常被限制在自己的进程内不会顺着调用链拖垮其他协议的采集。统一建模协议差异的收敛驱动多本身不是壁垒真正的设计在模型层。DC3 用四个核心实体把所有协议翻译成同一种语言Driver驱动→ Device设备→ Profile位号模板→ Point位号无论底层是 Modbus 的寄存器地址、OPC UA 的 NodeId 还是 S7 的 DB 块偏移进到平台里都是同一个 Point 模型有数据类型、有读写标志、有采集频率、有归属租户。协议差异被封装在两层配置属性里驱动级属性描述怎么连接Modbus TCP 的 host 与 port位号级属性描述读哪里从站号 slaveId、功能码 functionCode、偏移量 offset。上层数据中心、告警引擎、AI 工具面看到的从来不是某品牌 PLC而是一组语义统一的点位。这就是协议可以碎接入模型不能碎的含义也是 36 个驱动还能被有效维护的原因——如果每个驱动各带一套上层语义36 个模块就是 36 个维护分叉。Driver SDK新增驱动的开发契约协议世界永远比驱动仓库长得快所以 DC3 提供了 Driver SDK 与配套的开发指南docs.dc3.site 的 Driver Authoring 一章。SDK 的契约可以用一句话概括驱动只拥有协议 I/O 与面向用户的属性元数据其余平台共性——注册、调度、元数据刷新、健康上报、命令处理、数据分发——全部由 SDK 与运行时承担。落到接口上SDK 定义了一组能力接口生命周期启停钩子、元数据事件监听设备与位号的增删改通知、健康检查、读写协议、命令与配置校验。功能完整的驱动实现聚合接口即可只需要部分能力的驱动可以只挑小接口实现。Modbus TCP 驱动是一个现成的标尺整个模块的 Java 源文件只有两个——一个 Spring Boot 启动类一个协议服务实现类。后者做的事全部属于协议本身维护设备连接缓存校验 host/port 与 slaveId/functionCode/offset 配置按功能码 1–4 读线圈与寄存器、按功能码 1/3 写线圈与保持寄存器外加一个务实的细节——同一设备连续 3 次连接失败后进入 60 秒退避避免一台不可达设备拖垮整个调度周期。由此新增一个驱动的工作量边界相当清楚实现协议解析与点位映射在模块配置文件里声明驱动编码与属性元数据属性编码、类型、默认值打包成镜像、起服务注册进平台就能被统一管理——不必碰调度器、不必碰消息发送、不必碰租户逻辑。对社区贡献者而言新驱动应来自真实工位的真实需求——这也是接入层保持开放结构的原因。适用范围与限制成熟度有差异。仓库的驱动 README 明确列出一批标注进行中的驱动CAN、DLMS、EtherNet/IP、IEC 104、LwM2M、MQTT、OPC DA、Zigbee其协议 I/O 尚不完整生产使用前需核对实现Modbus、OPC UA 这类高频协议经过的实战检验远多于小众协议。选型时建议先用 Virtual 驱动验证链路再接真实设备SDK 消除协议本身的复杂度。SL651、DLT645 这类行业规约通常还伴随报文加密、私有扩展等现场适配工作量SDK 解决的是工程结构问题协议内部的坑仍要开发者自己踩清单以仓库为准。驱动清单以仓库dc3-driver/目录为准新驱动在持续增加。结语36 这个数字会过时五分类也可能长出第六类但协议可以碎接入模型不能碎这条约束不会变。对接入层而言真正耐用的资产从来不是驱动清单本身而是让一个新驱动只需一个启动类、一个协议实现类和一份属性元数据就能长出来的那套契约。相关仓库与文档入口见文末。仓库GitHub pnoker/iot-dc3 · Gitee pnoker/iot-dc3GVP文档docs.dc3.siteDriver Authoring Guide· book.dc3.site · demo.dc3.site