3、系统架构设计：分层架构、模块划分、冗余设计（双通道/三余度）、通信总线选型（ARINC 429/664）
好，咱们进入第三章。系统架构设计，说白了就是给EEC画骨架。这一步要是走偏了，后面所有代码、测试、认证全得跟着遭殃。我见过太多项目，上来就写代码，写到一半发现架构撑不住，推倒重来——那滋味，真不好受。
3.1 分层架构：把复杂问题拆成三块
EEC的软件架构，我个人习惯分成三层。为什么是三层？你想想看，飞机发动机的控制逻辑、硬件驱动、安全监控，这三件事的性质完全不同，硬揉在一起，后期维护就是噩梦。
- 应用层：负责核心控制算法。比如燃油计量、转速调节、推力管理。这一层只关心“要做什么”，不关心“怎么做”。
- 中间层：也叫抽象层。负责把硬件细节藏起来。比如读取传感器数值、输出执行器指令。我在这层做过一个“硬件抽象接口”，换传感器型号时，应用层代码一行都不用改。
- 底层：直接跟硬件打交道。包括CPU寄存器操作、中断处理、看门狗喂狗。这一层代码量最少，但最容易出bug。
关键原则：上层不能直接调用下层函数。必须通过中间层接口。我曾经在一个项目里发现有人为了省事，在应用层直接操作GPIO寄存器——嗯，后来那个模块在高温测试时随机死机，查了三天才找到原因。
3.2 模块划分：高内聚、低耦合
模块怎么切？我有个笨办法：先画数据流图。看哪些数据经常一起出现，哪些功能必须同时运行。然后按功能域切分。
典型的EEC模块划分如下：
| 模块名称 | 功能描述 | 关键接口 |
|---|---|---|
| 传感器管理模块 | 采集转速、温度、压力等信号 | 提供滤波后的工程值 |
| 控制律计算模块 | 执行PID、前馈、限幅等算法 | 输入传感器值，输出执行器目标 |
| 执行器驱动模块 | 控制燃油阀、放气活门等 | 接收目标值，反馈实际位置 |
| 故障诊断模块 | 监控各通道健康状态 | 输出故障代码和降级指令 |
| 通信管理模块 | 处理ARINC 429/664数据收发 | 提供收发缓冲区和协议解析 |
我的经验：每个模块的代码量控制在2000行以内。超过这个数，说明模块职责太杂，该拆了。我曾经维护过一个5000行的“万能模块”，里面既有控制算法又有通信协议——改一个bug能引出三个新bug。
3.3 冗余设计：双通道与三余度
EEC是安全关键系统，冗余设计是必须的。说白了，就是“别把所有鸡蛋放在一个篮子里”。
3.4.1 双通道架构
最常见的方案。两个完全相同的通道（A通道和B通道），同时运行。正常情况下，A通道输出控制信号，B通道热备份。如果A通道自检发现故障，立即切换给B通道。
这里有个坑：切换时间。我遇到过切换时间超过50ms的情况，发动机喘振了。后来我们规定：切换必须在20ms内完成，且切换过程中输出不能跳变。
3.4.2 三余度架构
更高安全等级的系统会用三余度。三个通道同时运行，输出采用“三取二”表决。也就是说，只要有两个通道结果一致，就采用那个结果。
注意：三余度不是简单的“三个通道复制三份”。每个通道的传感器、电源、时钟都必须独立。我曾经见过一个设计，三个通道共用同一个5V电源——结果电源一坏，三个通道全挂，三余度变成了零余度。
三余度的好处是：单个通道故障不影响系统运行，甚至两个通道故障（只要不是同一类故障）还能降级运行。代价是成本翻倍、体积重量增加、同步逻辑复杂。
3.4 通信总线选型：ARINC 429 vs ARINC 664
通信总线选型，说白了就是选“怎么把数据传出去”。EEC内部和外部设备之间，需要可靠、实时、确定性的通信。
3.5.1 ARINC 429
老牌总线，上世纪70年代的标准。特点是简单、可靠、慢。单根线速率只有12.5kbps或100kbps。我最早做EEC时用的就是429，那时候觉得够用了。
优点：
- 硬件实现简单，一个UART加几个电平转换芯片就行
- 电气隔离容易做，光耦一加就搞定
- 协议成熟，文档满天飞
缺点：
- 速率低，传输32位数据要花几毫秒
- 点对点通信，一个发送端只能接最多20个接收端
- 没有错误重传机制，丢了就丢了
3.5.2 ARINC 664（AFDX）
这是新一代航空以太网。速率100Mbps起步，支持全双工、交换式网络。说白了，就是把以太网搬到飞机上，但加了确定性传输保证。
优点：
- 带宽大，可以传输高清视频、海量数据
- 支持虚拟链路，逻辑上隔离不同数据流
- 有冗余管理，双网冗余自动切换
缺点：
- 硬件复杂，需要专用交换机和终端芯片
- 协议栈庞大，软件实现难度高
- 认证成本高，需要做大量符合性测试
| 对比项 | ARINC 429 | ARINC 664 |
|---|---|---|
| 速率 | 12.5/100 kbps | 100 Mbps |
| 拓扑 | 点对点 | 交换式星型 |
| 冗余 | 双线冗余 | 双网冗余 |
| 确定性 | 天生确定 | 需配置虚拟链路 |
| 成本 | 低 | 高 |
| 适用场景 | 传统EEC、简单传感器 | 新一代航电、大数据量传输 |
选型建议：如果项目是升级老机型，且数据量不大，继续用429没问题，省钱省事。如果是全新设计，且需要传输大量数据（比如发动机健康管理数据），果断上664。我最近一个项目就是混合使用——控制数据走429，监控数据走664，各取所长。
3.5 避坑指南
最后，分享几个我踩过的坑：
- 冗余通道不同步：两个通道的时钟源必须独立，否则一个晶振失效，两个通道同时漂移。我曾经吃过这个亏，后来每个通道都配了独立的温补晶振。
- 通信总线负载过高：429总线利用率超过80%时，延迟会急剧增加。我建议留50%余量。664虽然带宽大，但虚拟链路配置不当也会丢帧。
- 模块接口定义模糊：模块之间用全局变量传数据？千万别。必须用明确的接口函数，参数类型、范围、单位都要写清楚。我见过一个项目，两个模块对“温度”的理解差了100度——一个用摄氏度，一个用华氏度。
嗯，架构设计这部分就讲到这里。下一章咱们聊详细设计，包括状态机设计、时序分析、以及如何把架构落地成具体的代码结构。到时候见。