第四章：协议转换核心：429到AFDX的映射规则、数据封装与解封装
好，咱们进入最核心的部分了。前面几章我们把ARINC 429和AFDX各自摸了个透，现在要做的，就是让这两个“语言不通”的系统能顺畅对话。说白了，就是给429的数据“穿上”AFDX的衣服，再让AFDX能把这衣服脱下来，还原出原来的数据。
我当年第一次做这个映射的时候，心里也犯嘀咕：429那32位的慢速数据，要塞进AFDX那复杂的以太网帧里，怎么塞？塞进去之后，对面怎么认？嗯，别急，咱们一步步拆解。
4.1 映射规则：从“谁是谁”到“怎么走”
映射规则，是转换器的“灵魂”。它决定了429总线上的每一个Label、每一个数据位，对应到AFDX网络里的哪个虚拟链路（VL）、哪个端口、哪个数据区。
核心原则就两条：
- 一对一映射： 一个429 Label，通常映射到一个AFDX的虚拟链路（VL）。为什么？因为一个Label代表一类参数（比如高度、空速），而一个VL在AFDX里也代表一个独立的逻辑通道。这样设计，故障隔离最干净。
- 数据内容映射： 429的32位字（含Label、SDI、Data、SSM、Parity），需要被“拆包”或“原封不动”地放入AFDX的Payload区。
我个人的习惯是： 先建立一张“映射表”。这张表是项目里最宝贵的文档之一。它长这样：
| 429 Label (八进制) | 429 参数名 | AFDX VL ID | AFDX 端口号 (UDP) | Payload 偏移 (字节) | Payload 长度 (字节) | 备注 |
|---|---|---|---|---|---|---|
| 203 | 气压高度 | VL 100 | 5001 | 0 | 4 | 原字封装 |
| 206 | 指示空速 | VL 100 | 5001 | 4 | 4 | 原字封装 |
| 210 | 航向角 | VL 101 | 5002 | 0 | 2 | 仅提取数据区 |
你看，这张表把“谁（Label）从哪来（429总线），要到哪去（AFDX的VL和端口），以及怎么放（偏移和长度）”都定义清楚了。没有这张表，你的转换器就是无头苍蝇。
避坑指南： 我曾经在一个项目中，因为映射表里把Payload偏移写错了1个字节，导致对面航电系统解析出来的高度数据全是乱码。排查了整整两天，最后发现是文档里一个笔误。所以，映射表一定要经过双人复核，最好能自动化生成。
4.2 数据封装：给429数据“穿衣服”
封装，就是把429的数据，按照映射表，打包成AFDX帧的过程。这个过程，我习惯分成三步走：
- 接收与校验： 从429总线收一个32位字，先做奇偶校验。如果校验失败，直接丢弃，并记录错误计数。这一步不能省，因为429总线在长距离传输时，偶尔会有位翻转。
- 提取与重组： 根据映射表，决定是“原字封装”还是“提取封装”。
- 原字封装： 把整个32位字（含Label、SDI等）原封不动地拷贝到Payload缓冲区。优点是简单，缺点是浪费带宽。我一般用在调试阶段。
- 提取封装： 只提取Data字段（通常是20位），甚至只提取其中几个有用的位，然后拼接到Payload里。优点是高效，缺点是解析逻辑复杂。
- 构建AFDX帧： 填充以太网头、IP头、UDP头，然后把Payload放进去，最后计算并填入FCS（帧校验序列）。
下面是一个简化的封装代码示例，我用C语言风格写，方便你理解：
// 假设从429总线收到一个32位字
uint32_t arinc429_word = 0x203A5B2C; // 示例数据
// 1. 提取Label (位 31-29, 但通常用位 8-1)
uint8_t label = (arinc429_word >> 24) & 0xFF; // 简化处理
// 2. 查映射表，找到对应的VL和Payload偏移
// 假设查表得到：vl_id=100, offset=0, length=4
uint16_t vl_id = 100;
uint16_t payload_offset = 0;
uint16_t payload_length = 4;
// 3. 将429字拷贝到AFDX帧的Payload缓冲区
uint8_t afdx_payload[1472]; // 最大AFDX Payload
memcpy(&afdx_payload[payload_offset], &arinc429_word, payload_length);
// 4. 构建AFDX帧（伪代码）
// build_afdx_frame(vl_id, afdx_payload, total_payload_length);
注意： 这里有个字节序的问题。ARINC 429是高位在前（MSB first），而AFDX网络通常是网络字节序（Big Endian）。如果你的嵌入式处理器是小端模式（比如ARM Cortex-M），直接memcpy会导致数据高低字节颠倒。我建议在拷贝前，统一用htonl()或自己写一个字节序转换函数。
4.3 数据解封装：把衣服“脱”下来
解封装是封装的逆过程。AFDX帧到了接收端，我们要把它还原成429总线能识别的数据。步骤也很清晰：
- 接收AFDX帧： 从以太网口收一个完整的AFDX帧，校验FCS、IP头、UDP端口。
- 解析头部： 提取VL ID、UDP端口号，然后查映射表，找到对应的429 Label和参数信息。
- 提取Payload： 根据映射表里的偏移和长度，从Payload里把数据拷贝出来。
- 重构429字： 如果是原字封装，直接拿过来用。如果是提取封装，需要把提取出来的数据放回429字的Data区，并重新计算Parity位。
- 发送到429总线： 把重构好的32位字，按照429的时序（速率、间隔）发送出去。
这里有个细节，你想想看：AFDX是“尽力而为”的，但429总线要求严格的速率。所以解封装后，不能直接把数据怼到429总线上，必须有一个速率适配的缓冲队列。我一般用一个FIFO，以AFDX的接收速率写入，以429的发送速率读出。
我建议： 在解封装时，增加一个“超时”机制。如果某个Label对应的AFDX帧超过一定时间（比如100ms）没收到，就认为数据失效，并在429总线上发送一个“无效”的SSM码（比如全1）。这样下游设备就知道数据不可用了。
4.4 实战中的“坑”与“填坑”
做这个转换，有几个地方特别容易出问题，我跟你分享一下我的血泪史：
- 速率不匹配： 429有高速（100Kbps）和低速（12.5Kbps），AFDX是100Mbps。如果429侧是低速，而AFDX侧疯狂发数据，你的缓冲区会爆掉。解决办法：在封装侧做去重，只发送变化的数据，或者做降采样。
- 时间戳对齐： 429数据本身不带时间戳，但AFDX帧可以带。我习惯在封装时，把本地硬件时间戳写入AFDX帧的Payload头部（自定义字段）。这样接收端就能知道这个数据是什么时候采集的，方便做数据融合。
- 冗余设计： AFDX有双冗余（A/B网），但429没有。所以转换器需要把429数据复制两份，分别从A网和B网发送。接收端则要处理冗余帧的丢弃逻辑。
嗯，说到冗余，我记得有一次在实验室调试，A网和B网都正常，但接收端总是报数据重复。查了半天，发现是接收端的去冗余算法里，时间戳比较的精度不够，把两个网卡收到的同一帧当成了不同帧。最后把比较精度从毫秒级改到微秒级，问题就解决了。
好了，这一章的内容就这些。映射规则是基础，封装和解封装是手艺活。你只要把映射表做扎实，把字节序和速率适配处理好，这个转换器就成功了一大半。下一章，我们会聊聊如何用状态机来管理这个转换过程，让它跑得更稳。