内侧双胎就是全部理由
任何公交运营方都能讲清胎压为什么重要：油耗、轮胎寿命、磕马路牙子的损伤，以及满员六十多人时，承载轴上一条软胎会让整车操控完全不一样。但真正让一个公交集团的胎压监测项目获批的理由，要具体得多，也实际得多。
两轴城市公交通常有六个轮位，其中四个是后桥双胎。每侧的内侧胎，就是没有维修工会去查的那条——要够到它，得躺在车底下、拿着胎压表和气管，通常是在夜里的车场，通常是下着雨。全行业的人工检查表都在讲同一个故事：外侧胎有记录，内侧胎是估出来的。
这才是给公交车上 TPMS 的真正理由。不是车队不查胎压，而是承载最大的那几个轮位上的检查结果不可信。
「车场级」改变了什么
只在驾驶室屏幕上显示胎压的单车方案，是个有用的产品，却是个很难推进的车队项目。数据从不离开车，车场里没人看得到趋势，没人能证明上周的检查真的做了，而一台车因为轮胎故障停驶时，也没有记录可以复盘。
车场级监测的意思是：管理单位是车场，不是单车。要做到这一点，有三件事必须成立：
- 每台车都汇入车间已经在用的同一个视图，以车队编号为主键。
- 报警要在车出场之前到达，最晚也要在日检时到达，而不是等司机在运营中发现软胎。
- 每个轮位都能被明确识别，让工单可以直接写「4127 号车，左后内侧」，不留歧义。
最后一条是维保系统的要求，不是传感器的要求，而它恰恰是最常被跳过的一条。
数据从车上出来的四条路
我们接触过的车队，最终基本落在四种架构上。
只有驾驶室显示屏。 成本最低、装得最快，不依赖车场网络。它解决了司机的可见性问题，对车间毫无帮助。小车队作为第一步是合理的。
显示屏加手持读码器。 技术员夜里绕车场走一圈逐台读取。这保住了人工检查的流程，但省掉的只是「开气门嘴」这一步，人工量没变，规模一大就不成立。
车载网关或车联网对接。 接收器默认输出 CAN 2.0B、250 kbps、数据周期 500 ms，两项都可软件配置；同一平台还覆盖 J1939、RS485、RS232、Modbus RTU、PROFINET 和 UART。如果车上本来就有网关，胎压数据就并进同一路数据里。这才是把 TPMS 变成车队信息的架构。
云端或车场服务器。 车辆回车场时上传数据。我们的接收器最多支持 256 个轮位，对六轮的公交车来说远远用不完——这里的容量瓶颈是车辆数而不是轮位数，而车辆数属于平台侧，不属于传感器。
多数认真做的项目会把后两种组合起来：驾驶室里实时报警，车场里留记录。
到了车队规模，规格要求就变了
单台车的技术要求平平无奇。但到每年约 1500 台这个量级——也就是我们给国内某大型城市公交集团供货的量级——开始变得重要的是另外几件事：
- 统一物料号。 一个车队用三种传感器，就会攒出三套备件、三套安装流程和三场培训。
- 传感器寿命对上开轮周期。 内置传感器标称至少 5–6 年，外置型使用可更换 CR1632，标称至少 2 年。按车队多久开一次轮来选，而不是看单价。
- 环境适应范围。 车场冲洗、融雪盐、以及一年四季的温差。内置传感器 −40 ~ +125 °C，外置 −20 ~ +85 °C，两者都是 IP68。
- 供电。 接收器 DC 10–30 V，直接取整车电源，不需要加变换器。
- 压力精度。 ±7 kPa 足以抓到一周一次的人工检查会漏掉的慢漏气；胎温 ±3 °C 则补上了单看压力会漏掉的过载信号。
铺设的时候不能停运
1500 台车的车队不可能一个项目装完。真正可行的顺序其实很朴素：
1. 先做一个车场、一个车型，在这个范围里把轮位表的写法定下来。
2. 先给一个月内新到的车装，而不是整个车场，让车间用少量车先把报警处理流程跑熟。
3. 商定哪一条阈值直接开工单，以及谁对这条工单负责。
4. 之后才按车型、用同一份物料清单放大。
最容易犯的错是一次全装完、流程以后再说。结果就是整个车队都在报没人约定过怎么处理的报警。
从报警到工单
车队 TPMS 的价值是在车间里实现的，所以项目的最后一步是管理动作，不是电气动作。要提前定清楚：
- 哪一条压力或温度条件自动生成工单
- 哪一条只在下次计划保养时留个备注
- 工单上怎么写轮位，让维修工直接走到正确的那条胎
- 报警由谁、怎么消除
这四条如果没定义，车队只会得到更多数据，以及同样多的爆胎。我们在每一类车型上看到的规律都一样：传感器是最简单的部分，流程才决定这个项目能不能回本。
我们怎么做
GZVIA 在深圳自研自产传感器、接收器、中继器、显示屏和云平台。我们给国内某大型城市公交集团供货，每年约 1500 台；同时以客户品牌为港口机械整机厂供货，每年约 600 台。
如果你正在为公交集团做 TPMS 选型，把车队规模、车辆轮位配置和需要接收数据的系统发给我们，我们会回一份配置方案和协议文档。