3. 车载通信协议入门
在整车电子电气架构中，T-Box（Telematics Box）并不是孤立工作的。它既要通过蜂窝网络与云端通信，又要在车内与网关、动力域、车身域、座舱域等控制器交换数据。理解 T-Box 的安全通信与设备身份工程，第一步必须弄清它“接在哪些总线上、和谁说话、用什么协议说话”。本节从车载通信协议的基本特征出发，梳理 CAN、CAN FD、LIN、FlexRay、车载以太网与 T-Box 之间的通信关系。
一、核心原理：五类车载协议的定位差异
车载网络协议的选择，本质上是在带宽、实时性、成本、拓扑复杂度之间做权衡。CAN 与 CAN FD 是当前车内控制通信的主力；LIN 用于低成本、低速率、非关键的执行器与传感器；FlexRay 面向高实时、高可靠的线控场景；车载以太网则承担高带宽、大数据量的域间与诊断通信。T-Box 通常同时挂载在 CAN/CAN FD 与以太网上，通过网关实现跨网段访问。
从通信关系看，T-Box 的角色可以概括为“车内数据的采集者、云端指令的执行者、安全边界的守门人”。它通过 CAN 获取车辆状态（车速、电量、门锁、故障码），通过以太网与中央网关或座舱域控制器交互，通过蜂窝网络与 TSP 平台通信。不同协议承载的数据类型、周期和安全等级不同，这直接决定了 T-Box 的报文过滤、身份认证与加密策略。
二、方法流程：T-Box 跨协议通信的典型链路
以“远程解锁车门”为例，T-Box 的通信链路通常如下：
- 云端下发指令：TSP 平台通过 TLS 通道向 T-Box 发送解锁请求，携带设备证书、指令签名与时间戳。
- T-Box 身份校验：T-Box 验证云端证书链、指令签名与防重放随机数，确认指令合法。
- 跨网段转发：T-Box 将指令转换为 CAN 报文，通过中央网关路由到车身域控制器（BCM）。
- 执行与回执：BCM 执行解锁并回传状态报文，T-Box 将结果加密上报云端。
这条链路中，T-Box 既是安全端点，又是协议转换点。它必须对来自云端的指令做二次鉴权，不能“收到即执行”；同时要对发往 CAN 总线的报文做 ID 白名单过滤，防止越权控制。
三、案例/场景：不同协议在 T-Box 中的实际用途
| 协议 | 典型速率 | T-Box 相关用途 | 安全要点 |
|---|---|---|---|
| CAN | 125 kbps～1 Mbps | 车速、门锁、故障码采集 | ID 白名单、报文频率检测 |
| CAN FD | 2～8 Mbps | OTA 分包传输、诊断数据 | 大包完整性校验、会话鉴权 |
| LIN | ≤20 kbps | 车窗、雨刮、座椅等从节点状态 | 主节点身份校验、防非法唤醒 |
| FlexRay | 10 Mbps | 底盘线控、高实时安全数据 | 时隙完整性、双通道一致性 |
| 车载以太网 | 100/1000 Mbps | 网关通信、诊断、OTA、座舱交互 | VLAN、MACsec、TLS、证书管理 |
四、误区与复盘
误区一：认为 T-Box 只接 CAN。 现代架构中 T-Box 往往同时具备 CAN、CAN FD 与以太网接口，忽略以太网路径会导致安全策略覆盖不全。
误区二：把 LIN 当作“无安全需求”的总线。 LIN 虽低速，但若被非法节点注入，仍可影响车窗、门锁等车身功能，必须做节点身份与唤醒校验。
误区三：只加密云端链路，不保护车内报文。 云端 TLS 只保护“云到车”，车内 CAN/以太网仍需报文过滤、MACsec 或 SecOC 等机制。
复盘建议：绘制一张“T-Box 通信矩阵”，横轴列出协议类型，纵轴列出数据方向（上行/下行）、数据类别、安全等级与对应防护措施。这样在后续做设备身份与密钥管理时，可以清晰判断哪些链路需要证书、哪些需要预共享密钥、哪些只需报文过滤。
# 示例：T-Box 通信矩阵片段（YAML 伪配置）
links:
- proto: CAN
dir: rx
data: vehicle_status
security: id_whitelist + rate_limit
- proto: CAN_FD
dir: tx
data: ota_package
security: session_auth + crc32
- proto: Ethernet
dir: both
data: gateway_diag
security: vlan + macsec + tls
- proto: Cellular
dir: both
data: cloud_command
security: mtls + signature + anti_replay