工业与车联网协议速查

做工业、车载和物联网系统时，最容易被"协议"两个字吓住。真正难的不是背报文格式，而是搞清楚这次对接到底落在哪一行：是工厂里的 PLC 采集，还是车上的诊断刷写，还是路网里的定位上报，还是受限设备的传感上报。每一行用的协议、传输层、联调第一关都完全不同。把协议按行业分族，比按 OSI 七层去背要实用得多。

本文把九篇实战笔记按行业重新排布：工业现场总线（PROFIBUS / 西门子 S7 / kepserver）、车载与新能源（UDS / GB/T 32960 / JT/T 808）、物联网与机器人（CoAP / ROS2）、以及通用接口（USB）。每篇都保留了原作者"先抓住这三点"的坑位表达，文末附一张"协议 → 行业 → 传输层 → 典型场景"的速查表——这张表就是合并稿独有而单篇笔记给不了的东西。

一、工业现场总线：PROFIBUS、西门子 S7 与 kepserver 收口多品牌设备

工厂自动化里连 PLC、远程 IO 和驱动的，核心是现场总线那一套。PROFIBUS 是过程现场总线（Process Field Bus），常见 PROFIBUS DP 用于离散控制、PROFIBUS PA 用于过程仪表并可本安供电；它是主从轮询模型，主站按配置周期扫描从站，物理层常见 RS-485 和专用电缆，拓扑对终端电阻和段长很敏感。西门子 S7 协议则用于 PLC 与上位机交换数据块、输入输出和标志位：S7-300/400 走 ISO-on-TCP 的 102 端口，S7-1200/1500 在 TIA 里还要放行 PUT/GET，Snap7、NCK 或 OPC 服务器都能当客户端去读 DB。KEPServerEX 是工业现场常用的 OPC 服务器，把多品牌设备收口到同一地址空间——它以驱动形式接 Modbus、Siemens、Omron 等协议，对外提供 OPC DA/UA 点位，上位 SCADA 或 MES 只需订阅点名。

三个容易踩的坑

• 物理层决定稳定性（PROFIBUS）。屏蔽、等电位和终端电阻没做好，上层协议再对也会 CRC 刷屏；主从周期决定实时性，看门狗、最小从站间隔和诊断报文要在主站工程里配好，掉线才会被发现。
• 字节序与对齐（S7）。布尔、整数、浮点的对齐和字节序搞错会读出离谱数字；写操作必须限速、做范围校验，避免把工艺参数写成非法值；访问前要在 PLC 侧允许远程读写，并弄清 DB 编号、偏移和数据类型。
• 轮询粒度与权限（kepserver）。产线上不要把所有点都设成几十毫秒轮询，按变化速度分组；UA 证书与用户权限要和上位系统对齐；调试先看设备通讯灯是否绿，再用快速客户端读写点，超时和质量差往往出在波特率、站号或网络隔离。

什么时候用：维护老产线、对接西门子或第三方 DP 从站时必须懂 PROFIBUS，新项目更多转向 PROFINET 或 EtherCAT，改造时先确认波特率、地址和 GSD。S7 适用于把某个 DB 的实时值送到 MES 或组态软件，网络上建议划 VLAN，不要把 102 端口暴露到公网，调试用 Wireshark 的 S7 插件看 Job 和 Ack。kepserver 适合一台采集软件收口多品牌设备，把点表导出做版本管理，换设备时才能对得上旧地址，日志里的断线与重连次数是现场运维最直接的健康指标。

二、车载与新能源：UDS 诊断、GB/T 32960 与 JT/T 808 三套国标

车上的通信分两类：一是车内的诊断与刷写（UDS），二是车与平台之间的监管上报（GB/T 32960 与 JT/T 808）。三者命令字、会话模型完全不一样，混用就会联调失败。

UDS（统一诊断服务，ISO 14229）跑在 CAN、DoIP 或以太网之上，请求和响应按服务 ID 配对。常用的有读数据 22、写数据 2E、诊断会话 10、安全访问 27、例程 31、传输数据 34/36/37。做刷写工具或远程诊断时，会话切换和安全种子钥匙是第一关，后面才是数据块传输。

GB/T 32960 是电动汽车远程服务与管理系统的通信协议系列国标，覆盖车载终端和平台之间怎么报车辆登录、实时信息、补发和控制命令；报文按单元编码，含时间、车辆状态、动力电池和报警。做新能源车联网或监管接入时，平台要按这份协议解析和应答，不能只收自定义 JSON。

JT/T 808 是道路运输车辆卫星定位系统的终端通信协议，出租车、两客一危和货运平台广泛使用；它定义终端注册、鉴权、位置汇报、多媒体和车辆控制，报文有头、属性和校验并支持分包。

四个容易踩的坑

• 会话决定权限（UDS）。默认会话能读基础信息，编程会话才能刷写，切会话失败后面全是负响应；刷写是状态机——擦除、请求下载、传块、退出传输、校验，缺一步 ECU 会拒绝或变砖。
• 负响应要当协议读（UDS）。NRC 如 0x78 表示请求正确但要等待，0x33 是安全未通过，不要一律当超时重试。
• 登入与心跳先行（GB/T 32960）。没登入成功的实时信息平台会拒，补发和登出也有独立命令字；实时信息按信息体拼接（车辆、驱动电机、燃料电池、发动机、位置、极值、报警），缺项要按协议填无效值；终端时钟与平台时差、可选加密方式要在接入规范里写死，否则监管抽查对不上。
• 注册鉴权顺序不能乱（JT/T 808）。先注册拿鉴权码，再鉴权后才能发位置，否则平台不应答业务；0x7e 包头包尾要转义，校验错了整包丢，联调先抓原始十六进制；位置汇报要配策略，空车重车、熄火和报警时间隔不同，一刀切会浪费流量或漏点。

什么时候用：做诊断仪、OTA、产线刷写或远程故障读取必须走 UDS，实时控制信号不该塞进诊断服务，开发前向主机厂要 DID 列表、安全算法和刷写规范。做新能源车辆监管接入、T-Box 或车厂车联网平台必须按 GB/T 32960，物流货车轨迹常用 JT/T 808，不要混用命令字。做营运车辆监控、部标终端或监管对接用 JT/T 808，乘用车私有协议或新能源国标用别的规范，上线前用平台模拟器把注册、位置和补传跑通。

三、物联网与机器人：CoAP 受限设备、ROS2 机器人通信

这两类场景的共同点是"设备和节点很多、通信很碎"，但定位完全不同：CoAP 面向电量带宽都很紧的受限设备，ROS2 面向多进程协作的移动机器人和机械臂。

CoAP 是面向受限设备的应用层协议，跑在 UDP 上，语义接近 HTTP 的 GET/POST/PUT/DELETE；它用二进制头，支持确认消息和去重，还能通过观察模式做订阅。和 MQTT 比，CoAP 更像 REST，资源路径清晰；MQTT 更像消息代理。网关常把 CoAP 转成 HTTP 或 MQTT 再进云。ROS2 是机器人操作系统的二代通信与工具链，用 DDS 做发布订阅，不再依赖 ROS1 的中心主节点；节点间用 Topic 传流式数据、Service 做请求应答、Action 做长任务反馈，QoS 决定可靠传输还是最佳努力，launch 文件把多个节点组装成一个机器人进程树。

三个容易踩的坑

• CON 要有 ACK（CoAP）。可靠消息必须应答，丢包靠重传，超时要退避，别在丢包网上当 TCP 用；块传输拆大资源，固件或图片走 block-wise，一次塞超长 payload 会被中间盒丢掉。
• QoS 两端要对齐（ROS2）。传感器用 best effort、控制指令用 reliable，两端不一致时就改参数，不要先疑硬件；状态与 tf 要有明确帧率，导航与传感融合不能混用不同时钟源。
• 节点失败要可重启（ROS2）。lifecycle 节点把 configure、activate 分开，避免一个驱动挂掉整机；观察模式省轮询，但注意令牌和取消观察。

什么时候用：电量和带宽都很紧的传感网、灯控和楼宇设备优先 CoAP，手机 App 和浏览器用 HTTPS，接入云平台时确认是否原生支持 CoAP，否则加协议转换网关。做移动机器人、机械臂和传感融合平台时 ROS2 是主流选择，纯嵌入式闭环控制、没有多进程通信需求的小板子不必上 ROS，新项目不要再从 ROS1 起步，从 ROS1 迁移时要先解决消息定义与时间同步。

四、通用接口：USB 的描述符与端点模型

USB 是通用串行总线，主从角色分明：主机调度，设备应答。枚举过程中设备报描述符，主机加载驱动并分配地址。传输类型有控制、批量、中断和同步，分别服务配置、大块数据、人机接口和音视频。版本从 USB 2.0 到 3.x、Type-C，物理接口变了，分层模型仍是设备、配置、接口、端点。

三个容易踩的坑

• 描述符必须自洽。端点大小和间隔要符合规范，否则枚举失败；Windows 对 INF 和 VID/PID 敏感，调试用总线分析仪看枚举失败点。
• 供电与数据分开考虑。Type-C 还涉及 CC 检测和 PD 协商，线材质量差会表现为随机掉包。
• 先选对设备类。嵌入式 CDC、HID、MSC 是最常见三类设备类，先选对类再谈自定义协议，驱动会少踩很多坑。

什么时候用：做固件时描述符和端点规格要对齐规范；通用外设、人机接口、音视频流都走 USB，但不要把 USB 当长距离工业总线用。

附：协议速查表（行业 → 传输层 → 典型场景）