3. 车载网络协议基础与联调视角
在 MicroAutoBox 上做车载网络算法联调，第一步不是写算法，而是把“报文怎么走、时间怎么算、信号怎么对齐”这三件事在协议层面看清楚。MicroAutoBox 通常作为快速控制原型（RCP）节点接入整车网络，它既可能扮演一个 ECU 参与通信，也可能作为旁路监听/注入节点。不同协议在帧结构、仲裁方式、带宽、时间同步能力上的差异，直接决定了联调时哪些量可以实时闭环、哪些量只能离线分析。
一、五种协议的帧结构与通信机制
CAN（经典 CAN）采用 11 位或 29 位标识符，数据场最多 8 字节。它是基于优先级的 CSMA/CR 仲裁：标识符数值越小优先级越高，多个节点同时发送时逐位仲裁，失败方自动退让并重发。CAN 帧没有源地址，只有标识符，因此“谁发的”要靠 DBC 约定。位填充机制保证同步，但连续 5 个相同位后插入 1 个反相位，这会让实际帧长略大于理论值。500 kbps 下，一帧标准数据帧约 108~130 位，折算约 216~260 μs，这是联调时判断“一个控制周期能塞几帧”的基本依据。
CAN FD 保留仲裁段与 CAN 一致（保证与经典 CAN 共存时的仲裁兼容），但数据场扩展到最多 64 字节，并引入 BRS 位切换数据段波特率。典型配置是仲裁段 500 kbps、数据段 2 Mbps。以 64 字节数据为例，经典 CAN 需要 8 帧才能传完，而 CAN FD 一帧即可，且数据段提速后总时间反而更短。联调中要注意：CAN FD 帧的 CRC 多项式与经典 CAN 不同，且没有远程帧，因此不能沿用旧的 RTR 触发逻辑。
LIN 是主从式单线总线，最高 20 kbps，帧由主机头发起（含同步间隔、同步场、受保护的标识符 PID），从机响应 1~8 字节数据。它没有仲裁，靠调度表（schedule table）轮询。LIN 帧的 PID 由 6 位 ID 加 2 位奇偶校验构成，联调时若从机不响应，先查 PID 奇偶校验和从机使能，而不是查波特率。LIN 适合车门、座椅、雨刷等低速执行器，MicroAutoBox 一般通过 LIN 收发模块或网关节点间接参与。
FlexRay 是时间触发协议，通信周期由静态段、动态段、符号窗和网络空闲时间组成。静态段按 TDMA 固定时隙分配，适合确定性控制；动态段用迷你时隙按优先级竞争。FlexRay 支持双通道冗余，速率 10 Mbps。联调中最关键的是全局时间同步：各节点通过同步帧和偏差测量修正本地时钟，若冷启动节点未收到足够同步帧，会进入异步状态，此时静态段时隙会漂移，表现为周期性丢帧。FlexRay 帧头含 11 位帧 ID、7 位载荷长度、11 位头部 CRC 和周期计数，周期计数是判断“这一帧属于哪个通信周期”的核心字段。
Automotive Ethernet 以 100BASE-T1/1000BASE-T1 单对双绞线为主，帧就是标准以太网帧，但车载场景依赖 VLAN（802.1Q）做流量隔离，依赖 PTP（802.1AS）做时间同步，依赖 TSN 的 802.1Qbv 做时间感知整形。联调时，SOME/IP 或 DoIP 承载在 UDP/TCP 之上，带宽可达百兆甚至千兆，适合摄像头、雷达、诊断刷写。它的“帧”不再是固定短帧，而是变长帧，因此延迟分析要用整形器和信用量（credit-based shaper）模型，而不是简单的最坏响应时间公式。
二、MicroAutoBox 上的支持方式与联调要点
MicroAutoBox 通过对应通信模块接入各总线：CAN/CAN FD 走板载 CAN 控制器，LIN 走 LIN 收发器，FlexRay 走 FlexRay 通信控制器，以太网走车载以太网端口。在 RTI（Real-Time Interface）中，每种协议对应一组报文收发模块，配置时导入 DBC（CAN/CAN FD/LIN）或 ARXML/FIBEX（FlexRay）描述文件，工具会生成信号级接口，把原始字节映射为物理量。
联调时建议按“先监听、后注入、再闭环”的顺序推进。以 CAN FD 为例：先把 MicroAutoBox 设为只听模式，用示波器或总线分析仪确认仲裁段 500 kbps、数据段 2 Mbps 的采样点（通常仲裁段 80%、数据段 75%），再导入 DBC 观察信号更新周期是否与设计一致。确认无误后切到正常模式，用 RTI 的发送模块按 10 ms 周期注入报文，同时用接收模块回读，比较发送时间戳与接收时间戳的差值，这个差值就是该路径的往返延迟。
FlexRay 联调要额外关注冷启动和同步。若 MicroAutoBox 作为冷启动节点，需在配置中指定冷启动帧和同步帧；若作为普通节点，则要确认它能在两个通信周期内收到至少 2 个同步帧，否则会进入异步。判断依据是周期计数是否连续递增，以及静态段时隙是否与调度表一致。以太网联调则先确认 PTP 是否锁定（看 offset 是否收敛到微秒级），再做 SOME/IP 服务发现，最后才做闭环控制。
三、一个可复用的联调检查清单
| 协议 | 关键帧字段 | MicroAutoBox 配置项 | 联调判断依据 |
|---|---|---|---|
| CAN | ID、DLC、Data | 波特率、采样点、DBC | 周期抖动、ACK 是否正常 |
| CAN FD | BRS、ESI、DLC、Data | 仲裁/数据段双波特率 | 数据段眼图、CRC 错误计数 |
| LIN | PID、Data、Checksum | 调度表、主机/从机角色 | 从机是否响应、校验和类型 |
| FlexRay | 帧 ID、周期计数、头 CRC | 冷启动/同步帧、时隙表 | 周期计数连续性、时隙对齐 |
| Ethernet | VLAN、PTP、SOME/IP | IP、VLAN ID、PTP 角色 | PTP offset、服务发现是否成功 |
把这张表填完，再回到算法层：如果控制周期是 5 ms，而 CAN 上关键信号的实际更新周期是 10 ms，那么闭环里就必须做信号保持或预测，否则控制器会反复使用旧值。协议基础不是背景知识，它直接决定了联调时哪些假设成立、哪些必须修正。