在产线数据采集的工程实践中，最耗时的问题通常不是并发或存储，而是协议适配。
同一个车间里，温度传感器说着 Modbus RTU，PLC 是西门子 S7，电表跑着 DLT645，环保监测设备用 HJ 212（SL651 同源的水文规约家族），新采购的网关又是 MQTT。每接一类设备，就要重新学一套报文格式、一套连接管理、一套异常语义。这种碎片化在工业物联网领域已存在二十余年------各协议诞生于不同年代与行业，服务于不同的技术约束，难以彼此取代。
平台层的职责，是屏蔽协议差异对上层业务的影响。
36 个驱动模块是怎么分的
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------从工厂自动化到电力楼宇，从抄表到水利。
- 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------不接真设备也能把整条链路跑通，是平台自测与新人上手的脚手架。
需要说明：36 个驱动的成熟度存在差异，它们均为独立部署的微服务------每个驱动是单独的进程，按需启停、按需扩容，不需要的驱动不参与部署，不占运行资源。
比 36 这个数字更重要的：统一建模
驱动多本身不是壁垒，真正的设计在模型层。DC3 用四个核心实体把所有协议"翻译"成同一种语言：
Driver（驱动）→ Device（设备）→ Profile（位号模板）→ Point（位号）
无论底层是 Modbus 的寄存器地址、OPC UA 的 NodeId 还是 S7 的 DB 块偏移，进到平台里都是同一个 Point 模型：有数据类型、有读写标志、有采集频率、有归属租户。上层数据中心、告警引擎、AI 工具面看到的从来不是"某品牌 PLC"，而是一组语义统一的点位。
这就是"协议可以碎，接入模型不能碎"的含义。
Driver SDK：第 37 个驱动从哪来
协议世界永远比驱动仓库长得快，所以 DC3 提供了 Driver SDK 与配套的开发指南（docs.dc3.site 的 Driver Authoring 一章）：驱动开发者只需要实现协议解析与点位映射，注册、心跳、调度、数据上行、租户隔离这些平台共性由 SDK 与运行时承担。写完打包成镜像，注册进平台就能被统一管理。
对社区贡献者而言，新驱动应来自真实工位的真实需求------这也是接入层保持开放结构的原因。
实事求是的边界
- 驱动的成熟度有差异：Modbus、OPC UA、MQTT 这类高频协议经过的实战检验远多于小众协议，选型时建议先用 Virtual 驱动验证链路、再接真实设备；
- SL651、DLT645 这类行业规约通常还伴随报文加密、私有扩展等现场适配工作量，SDK 解决的是工程结构问题，不能消除协议本身的复杂度；
- 驱动清单以仓库
dc3-driver/目录为准，新驱动在持续增加。
仓库 ：GitHub
pnoker/iot-dc3· Giteepnoker/iot-dc3（GVP）文档：docs.dc3.site（Driver Authoring Guide）· book.dc3.site · demo.dc3.site