先回答两个问题，架构基本就定了
选协议之前，先回答两件事。
胎压数据第一站落在哪？ 落在机器控制器、落在一个网关，还是直接进上位系统。这个答案决定了接口形式和失效模式。
报警归谁？ 如果机器上的操作员必须在几秒内反应，报警就该在机器上；如果调度需要的是下周的轮胎趋势，它就属于上位层。想让一个地方同时满足两种需求，结果往往是两边都没做好。
其余的——协议、点名、轮询周期——都从这两个答案里推出来。下面讲实操细节。
RS485 + Modbus 与 CAN + J1939
这两者经常被摆成对手，其实不是。它们处在不同的层，各自更适合链条上的不同位置。
CAN + J1939 是给机器用的总线。 接收器是个「说话方」：它按自己的节奏发布，具备帧级校验、优先级仲裁和每节点错误计数器。如果这台机器本来就在跑 J1939，胎压数据就作为一路普通来源加入，你的集成工作是一个解码器加一份报文映射。诊断是白得的，而且快速漏气报警可以拿到比常规压力帧更高的优先级。
RS485 + Modbus RTU 是给控制柜用的总线。 PLC 或上位系统挨个轮询从站。不问就不说话，所以数据新鲜度就等于你的轮询周期；沉默的节点就是沉默，除非你自己实现超时判断。换来的是：不需要新增现场总线，几乎所有工业控制器和 SCADA 都能读，而且低波特率下的长距离走线很平常。
一个简短的选法：
- 控制器本来就有 CAN，而且那条总线上还有别的设备——用 CAN。
- 数据落在 PLC 或直接落在 SCADA、走串口——用 Modbus RTU。
- 机器很长、控制器离后轴组很远——低速串口很舒服；而 CAN 在 250 kbps 下也能覆盖常见的底盘长度。
- 还没定——买一台两种都支持的接收器。我们的接收器就属于同一硬件家族，选择权可以留到后面。CAN 总线集成那一页把 CAN 这条路讲得更细。
点表就是合同
接口文档比协议选型更重要。不管是 DBC 文件还是寄存器表，每一个量都必须写清五件事：
- 标识符，用操作员和检修记录已经在用的那套命名；
- 字节序、起始位或寄存器地址、长度；
- 换算、偏置和单位，明确写成 bar 或 psi、摄氏度；
- 有效范围，以及「无效 / 不可用」在总线上长什么样；
- 更新行为：什么条件下变，心跳长什么样。
有两条规矩能救项目。
按轮位发布，不要按传感器序列号发布。 接收器给出的应该是「这个位置的值」，而「传感器身份 ↔ 轮位」的映射放在一份点表引用的文档里。如果让 SCADA 自己去解传感器 ID，那每换一次胎都等于一次软件变更。
报警语义只写一次。 阈值、回差、快漏判据、传感器失联行为，以及判定状态前的延时。如果 PLC 和 SCADA 各拿自己的阈值比一遍，它们迟早会不一致——而且通常是在事故复盘的时候才发现。
轮询、延迟与「过期数据」预算
胎压是慢信号，所以很容易顺手假设延迟无所谓。但有一个场景它非常要紧：报警。
走 CAN，接收器按自己的节奏发布——我们的 CAN 输出是 250 kbps、10 毫秒数据周期，两者都可以用软件配置。所以新鲜度不取决于你写了什么程序。
走串口，新鲜度就是算术：轮询周期 × 设备数量，再加上任何不应答设备的重试。上位系统每 200 毫秒轮一次单台接收器，对轮胎趋势够快，通常对漏气报警也够快；而一条串口段上挂十几台设备、用一个很慢的扫描等级，就不够了——再聪明的报警逻辑也修不好一个迟到才到的值。
然后把整条链在纸上加一遍：
1. 传感器 → 接收器（433.92 MHz 无线）；
2. 接收器 → PLC 或网关；
3. 网关 → PLC 扫描，PLC → 上位系统；
4. 上位系统自己的扫描等级；
5. 你配置的报警延时 / 去抖。
第 3、4 步就是项目丢掉「以为自己有」的那一秒的地方。动手之前先定义两个数字：报警延迟（秒级）和趋势延迟（分钟级），然后逐跳对照。
还有一条规矩，它造成的是真实损失：通信超时必须读成「未知」，而不是读成「正常」。 一个过期但仍看起来合理的压力值，比没有值更糟——因为报警逻辑会把它当成一条健康的胎。每一套集成都应该带一个逐轮位的质量位，并且报警策略要把「质量坏」本身当成一类报警。
报警怎么正确地送进上位层
在状态产生的地方产生报警，然后以「带时间戳的状态」交付。 几个实操要点：
- 点表里每个轮位带一个状态字或报警字，让 SCADA 读状态，而不是自己从压力值反推；
- 类别要分开：低压、高压、快漏、高温、传感器失联、接收器／通信失联。它们的优先级和处置动作都不一样；一个笼统的「轮胎报警」位对操作员没有任何可操作性；
- 去抖只做一处。无线和串口都会产生单次毛刺，延时在一处决定、一处记录、一处实现；
- 上位系统里的「确认」不能清掉机器上的物理报警。操作员确认的是这条消息，而轮胎还是瘪的。把两者分开，可以避免一个善意的 SCADA 功能把真实故障藏起来；
- 如果有任何报表、班次记录或事故复盘依赖胎压数据的先后顺序，先把时钟对好：接收器、网关和 historian 的时间戳要互相对过，再去相信事件顺序。
集成最常翻车的六处
1. 字节序或换算错。在信任任何数字之前，先用一个已知压力和已知温度验证一遍。
2. 共享串口段上轮询过快，或者节点数超过扫描等级能承受的量，结果超时被误判成传感器故障。
3. 把通信丢失当成「压力正常」。这是最危险的一种配置错误。
4. 两套报警引擎，PLC 和 SCADA 的阈值不一样。
5. 换胎后轮位表失真，报警指向错误的轮位，操作员从此不再相信它。
6. 物理层做错：两端没有终端电阻、用星形而不是菊花链、屏蔽层两端都接地，或者把胎压挂到一段远比它重要的功能所占用的总线上。
一套能抓住这六条的调试顺序
- 台架上，用已知压力和已知温度：逐轮位、逐个换算值验证；
- 逐项模拟故障：传感器失联、中继器掉线、接收器掉线，一次一个，确认每种都产生你设计的状态；
- 模拟一次快速漏气并计时，从传感器一路计到操作员屏幕；
- 上位系统里逐个标签对照点表核，不要凭记忆；
- 把轮位表和报警设置记进这台机器的档案，跑完第一个班次后再复核一次。
我们交付什么
GZVIA 在深圳自研自产传感器、接收器、中继器、显示器和云平台。单台接收器最多支持 256 个轮位，压力精度 ±7 kPa；同一硬件家族支持 CAN 2.0B、J1939、RS485、RS232、Modbus RTU、PROFINET 和 UART——做控制器集成有 TR-100R-CAN 与 TR-100R-UART 两个变体，无线链路需要帮忙时有 TR-300R 中继器，数据要上云而不是进电柜时有 DB-4G-01 网关。
做集成时，我们会交付报文对照表或 DBC 文件、寄存器表、报警语义说明、接插件针脚定义和一份轮位表模板，并陪你的集成商走完第一次调试。把你要读数据的控制器或 SCADA 平台、以及轮位数量告诉我们，我们推荐的会是适配你架构的那条路。说说你的机器。