FlexRay通信系统里，每条报文都被框定在“帧头+有效负载+帧尾”的固定格式里。 只要把这些镜头拉近来看，就能看到它们具体的字节级排布，这些细节其实都是从《FlexRayCommunicationSystem V2.1》里抠出来的。 帧头这一块包含了40比特的内容，咱来给它拆开细说。前5比特是“指示器”，像信号灯似的在干活。 Bit1是保留位，发消息的时候填个0就行，收的人也不理会它。Bit2是负载指示位，要是动态报文这位置了1，说明前两个字节是Message ID；要是静态报文这位置了1，那这前12字节就是网络管理向量。 Bit3是空帧指示位，填0表示真的有内容，填1意味着后面都是0，让发消息的一方省事不少。Bit4是同步帧指示位，填1就说明这是同步帧，能把全网时钟都拉齐。Bit5是启动帧指示位，得和Bit4配合着看才生效，冷启动的节点必须先收到这个开机信号才算合法。 接下来11比特是ID，相当于身份证号。0x00是留着给无效报文用的，有效ID从1到2047都能挑，直接对应到时隙编号上。7比特的Payload Length用来量体裁衣定长度，最多能传254字节或者127个字。静态时段里的同一Cycle里长度必须一致，可以通过设置gPayloadLengthStatic一次性搞定。 11比特的CRC专门负责把头里的信息再核对一遍，只对ID、长度和那两个指示器算一遍账。6比特的Cycle Count记录了这消息发了多少个周期，范围0到63，用来防丢包或者防重复。 说到有效负载就得分动静两派来看了。要是静态报文的负载指示位被点亮了，那前12个字节就全得留给网络管理向量用；要是动态报文的位被点亮了，前两个字节就得是Message ID；剩下的地盘都归用户数据霸占着。 帧尾这部分比较简单，就是把前面头和负载的内容全塞进24比特的CRC计算域里接收方用同一种多项式去校验一遍。 到了实际传输这一步可没那么容易了，FlexRay不是“从Header开始发”的那种方式。它得先跳一段TSS（低电平持续3到15个周期）再加上FSS和BSS开场舞，专门给接收方打个招呼说“我来了”。 每发一个字节前还要再缀上一个BSS当节拍器让接收端随时能踩上点儿。字节末尾用FES收尾之后还得跟上11比特隐性位来界定通道空闲。上面的图就能看出动静两种报文在时序上的区别：动态报文在FES后面会多一段DTS（Dynamic Trailing Sequence），方便接收方精准掐表知道什么时候结束。 最后咱们再把这些关键点串一串：如果碰到现场问题能快速定位是头信息错了、负载丢了还是时序乱了。