这一页要做的决定
如果胎压数据要留在你自己的平台上，有两条路：
1. 你的控制器自己读 CAN 再自己上传 —— 最可控，工作量也最大（要帧布局，整条上行链路你搭）。
2. 由网关帮你发布 —— 通过 MQTT 发到你已经在跑的 broker，你只需要约定载荷和 topic，其余不用改。
这一页讲第 2 条，因为它是几天能跑起试点的那条，而不是一个项目周期。
整条链路
`传感器 → 接收器 → CAN → 4G 网关 → MQTT broker → 你的平台`
接收器那一侧见 CAN 集成页。这里要说清的是：网关是独立的一台设备，不是接收器的功能。
这恰恰是好事 —— 车上的那侧可以就是普通接收器 + CAN 节点，联网部分可以后加、可以换，不用动胎压硬件。
网关到底做什么
| 能力 | 对你的意义 |
|---|---|
| MQTT over TLS，双向认证 | 你发凭据、设备出示证书；不是配置文件里放一个共享密码 |
| 变化才上报 | 没变的值不发。车队里这就是"一天几 KB"和"一条常流"的区别 |
| 本地缓存 | 断网时存下来、恢复后补发。隧道和没信号的堆场不再是数据黑洞 |
| A/B 双分区 FOTA，失败回滚 | 现场就能升级，不必把车叫回来；升级失败自动退回上一版 |
| 4G Cat.1，可回退 2G/3G | Cat.1 便宜、够这个数据量；回退让老网络也能用 |
| 可选 GNSS | 每条读数带位置。超过一台车之后，这个就变成必需 |
Topic 设计：先定它，再谈别的
多数 MQTT 集成不是死在连通性，是死在 topic 结构。三种可行做法：
A. 每车一个 topic：`fleet/{vehicle_id}/tpms` —— 简单，数据一起到。
B. 每车每轮位一个：`fleet/{vehicle_id}/tpms/{axle}/{side}` —— 订阅更细，但 topic 数量多。
C. 一个 topic，车号放在载荷里：`fleet/tpms` + `vehicle_id` 字段 —— 最好管，但想按车订阅就得自己在代码里过滤。
试点几乎一律选 A。 只有平台确实需要按轮位订阅时才上 B；车队很大且平台本来就会解复用，才考虑 C。
还有两件必须书面定死：retained 标志（订阅时要不要直接拿到最后一次值 —— 压力通常要）和
QoS（压力用 QoS 1；丢得起的东西用 QoS 0）。
发布什么值
我们交付的载荷简单且有文档 —— 每条读数一个 JSON 对象，字段按你要的来，另加时间戳和轮位。
我们不会把自己的内部帧丢给你去解，那正是走网关这条路的意义。
我们需要你给的是约定，不是协议：
- 你要的字段名（或者你已有的 schema）；
- 单位（kPa 还是 bar；是表压 —— 我们不发表压）；
- 缺一个轮位时怎么表示（不出现 / null / 质量标志）；
- 读数要不要带轮位标签，还是嵌在轮位下。
如果你已经把别的传感器发到平台，给我们一条你们自己格式的示例报文就行 —— 比任何规格文档都快。
这条路的边界
- 不是 OBD 替代品：不读发动机，也不解车辆自己的 J1939 参数（除了我们产出的胎压）。
- 不需要你交出 CAN 协议：我们往你的 broker 发值，你的定义留在你手里。
- 不是看板：我们不做平台。想用我们的也行，但这条路的意义是数据留在你那。
定死这四件就能开跑
1. Broker 与 topic —— 地址、端口、TLS 方式、topic 模式、retained、QoS；
2. 凭据 —— 设备怎么认证、怎么轮换；
3. 载荷 —— 字段名、单位、表压/绝压、缺值约定；
4. 量 —— 多少车、每天多少条读数、需不需要位置。
有这四条，一台试用设备就能往你的 broker 发数据，而没有人要写解码器。
这就是它和裸 CAN 集成的实际差别：工作从你的固件团队，变成一张填一次的表。
网关/DTU 选项见产品页，整体视角见 CAN 总线胎压集成。
已经有 broker 的，把示例报文发我们，我们照着对。