工控现场大量设备走 MODBUS（RS485/RTU 与 TCP），但上位机与设备对接长期有三类痛点：① 多设备、多链路若各自开关串口、各写一套读写代码，重复且容易冲突；② 数据采集与控制要跟业务流程（判断、写值、记录、上报）串起来，纯命令行工具做不到；③ 现场调试只有零散串口工具，看不清"总线上到底在传什么"，遇到"控制无效"时难判断是协议、接线还是转换器工作模式的问题。本项目立项，就是做一个 MODBUS 工业通讯套件：底层是常驻的"总线服务"（统一持有 RTU/TCP 链路、串行化事务、覆盖全功能码），上层既能被工作流节点与脚本调用完成自动采集和控制，也能用人工调试台当主站发指令、当从站被轮询、抓总线全部报文并做统计分析。面向设备数据采集、产线控制与联调、工控网关/转换器排障等场景。
分工明确的四部分。 ① MODBUS 总线服务 （无界面、被调用）：持有串口 RTU / TCP 链路并按链路串行化，对外只暴露同步事务接口；覆盖 MODBUS 全公开功能码——读 01/02/03/04、写 05/06/15/16、屏蔽写 22、读写组合 23、FIFO 24、文件记录 20/21、诊断 07/08/11/12/17（仅串行）、MEI 43 读设备标识；链路在一次任务内复用、空闲自动关闭；所有阻塞收发都在服务自带 I/O 线程，不阻塞界面。 ② 工作流节点 ：「MODBUS 链路」节点声明串口/网络（不做 I/O），经连线把链路交给「MODBUS 设备」节点，设备节点承袭链路后直接读写该站（先写后读、支持数据类型与字节序转换、仅写模式、一台设备多地址段）。 ③ 本机控制面与脚本库 ：服务另开仅回环（127.0.0.1）+ Bearer JWT 的 HTTP 控制面（health / transact / batch），配套纯标准库的 Python 客户端库（自动发现服务、401 自动续期），脚本可自由组合读/判断/写、多总线多站。 ④ MODBUS 调试台 （人工）：主站测试（全功能码 + RAW 任意帧 + 轮询 + 读值双击写回）、从站模拟（TCP Server / RTU Slave 内存映射应答 + 异常注入）、总线监控（RTU 只读嗅探按 CRC 逐帧切分 / TCP 透明代理双向抓包，自动识别承载是网关还是透传）、数据分析（帧表 + 站号/功能码过滤 + 异常与时延统计 + CSV 导出）。
我负责服务端、节点、控制面与调试台的完整设计与实现。技术栈：C++17 + Qt 6.8（Widgets / Gui / SerialPort / Network）+ CMake；协议编解码层与 Qt 解耦，可被插件源码级复用（调试台直接编译服务的协议实现，不复制代码、不改架构）；控制面用 JWT（HS256）鉴权，Python 客户端仅用标准库。亮点与难点：① 服务化与无状态 ——总线唯一持有者按链路串行化，链路参数随请求传入，因此不存在跨工作流的作用域问题，链路可复用、空闲自动关闭；② 阻塞 I/O 隔离 ——所有收发都在服务自带 I/O 线程，调用线程被阻塞但不影响界面；③ 完全解耦的跨语言控制面 ——消费方与生产方唯一的耦合点是"JSON 契约 + 发现文件"，不 include、不链接、不依赖插件 id，服务将来抽成独立进程或独立机器只需改一个地址环境变量，客户端零改动；④ 安全面最小化 ——只绑回环并拒绝非回环对端、密钥仅内存不落盘、发现文件只放签好的令牌、滚动重签保证客户端不被打断；⑤ 总线嗅探的帧切分 ——不能只靠时序（设备回得快时请求与响应会落在同一批数据），改为按功能码 + 字节数域推候选长度并逐个 CRC 校验，残余才用帧间静默兜底；⑥ 承载自动识别 ——能判定转换器是"网关/转换"还是"透传"（串口上出现 MODBUS TCP 报文即透传），这是现场"控制无效"最常见的根因；⑦ 无硬件验证 ——服务端与客户端库均有探针（仅回环 / 令牌 / 401 续期 / 批量顺序 / 停止清理等共 38 条断言），不打开任何真实串口或网络设备。
评论