传感器几乎从来不是难点
工业 TPMS 传感器测量压力和温度，通过免许可频段发出去——我们用的是 433.92 MHz。这部分很成熟：量程、精度、电池寿命、防护等级都写在规格书上，一个下午就能把不同供应商比完。
真正比不出来的是无线链路之后发生的事。只驱动自家显示屏的接收器，是一个封闭产品；能讲机器本身总线语言的接收器，是一个部件。这个差别决定机器控制器能不能对胎压数据做出动作——比如气压低时限制车速——还是操作员只是又多了一块没人看的屏幕。
胎压数据离开车辆的三条路
实践中我们见到三种集成形态，后果差别很大。
- 只有本地显示。 接收器驱动驾驶室里的 7 英寸屏。改装最快、没有集成工作，但数据留在驾驶室，永远到不了车队系统。
- 现场总线输出。 接收器把胎压数据发到 CAN、RS485、Modbus RTU、PROFINET 或 RS232 上。机器控制器像读其他节点一样读它，报警可以接进现有逻辑。
- 蜂窝网关。 接收器配一台 4G DTU，数据上云看板，也可以通过 API 交给客户自己的平台。这是超过几台车之后唯一能规模化的形态。
这三条并不互斥。有用的地方在于：同一台接收器硬件三条路都支持，所以车队可以先上本地显示，之后再补联网，不必换掉已经装好的东西。
J1939 期望什么，TPMS 怎么放进去
J1939 是重型车辆在 CAN 之上用得最多的上层协议。数据按参数组组织，用 PGN 标识；组里的具体值用 SPN 寻址。已经在消费 J1939 的控制器，期望新数据以同样的形状出现——有定义的 PGN、有定义的字节布局、有定义的更新速率。
让人意外的是：胎压和胎温并不像发动机转速那样有一个行业公认的 PGN。 所以实践中 TPMS 集成走两条路之一：
- 供应商发布专有 PGN 或报文集，OEM 自己把它映射进应用。第一个项目最常见走这条；
- 双方约定一套符合 OEM 既有习惯的报文布局，由供应商在固件里实现。这在 OEM/ODM 项目里是常规做法，也是供应商必须有自己的固件团队的原因之一。
无论走哪条，三个数字都比任何宣传语重要：波特率、更新（数据）周期、字节布局。我们的默认是 250 kbps + 10 ms 周期，两者都可软件配置，因为不同机型期望的速率不一样。
该向 TPMS 供应商要什么
技术评估之前，先要这四样。拿不出这四样的供应商，也做不了集成支持。
- 报文表或寄存器表：用了哪些标识符、每个字节什么意思、比例和偏置怎么算、故障怎么表示；
- 波特率与周期时间，以及这两项是固件可配还是出厂固定；
- 台架搭建说明：接收器在台架上要满足什么条件才开始发数据，让你的工程师不用上车就能复现；
- 一台样机 + 协议文档：在订单执行期间就给，不是交货之后才给。
如果供应商只是答"支持 CAN"却拿不出文档，那不是集成答案。
部署真正出问题的地方
装得足够多之后，失败模式就不再让人意外。
- 长底盘上的无线遮挡。 20 轴的车可以有效地挡住 433 MHz。中继器位置必须对着底盘布置来规划，不能靠估。160 轮运梁车上我们用了 12 台。
- 地址分配。 有 256 个可能位置，就必须有人把传感器 ID 映射到物理轮位，并在更换传感器时保持这个映射不变。交付之前就定好谁负责这个流程，别等第一次换胎之后。
- 地与供电。 工业车辆电气环境恶劣。接收器的供电范围和防护能力，与无线指标同样重要，尤其是充电系统偏老的机器。
- 报警语义。 只点亮驾驶室一个灯的低压报警很简单；必须触发限速或写日志的报警，就得和测量本身一样认真定义。
这对写规格意味着什么
给供应商的第一封有效邮件，不是"把你的 TPMS 目录发我"，而是一小段话：机器是什么、有多少个轮位、哪个控制器必须收到数据、它今天讲什么接口、轮胎异常时操作员应该能做什么。
有了这些，配置就有答案——接收器数量、中继器数量、传感器数量，以及配套的文档集。没有这些，任何答复都是打扮成报价单的猜测。
把机器、轮位数量和必须收数据的控制器发给我们，我们会回一份配置方案和文档清单。看 CAN 总线 TPMS 集成页，接收器细节见 TR100 接收器产品页，或者直接把机器情况发给我们。