3. 飞行控制计算机（FCC）：处理器选型、架构设计、冗余策略
飞行控制计算机，我们内部常叫它FCC。这东西是导弹的大脑，所有控制律的解算、导航数据的融合、舵机的指令，全得靠它。说白了，导弹飞得好不好，能不能命中目标，FCC是核心中的核心。
我这些年经手过好几个型号的FCC设计，从早期的8位单片机到现在的多核DSP+FPGA架构，踩过的坑不少。今天咱们就聊聊处理器怎么选、架构怎么搭、冗余怎么做。
3.1 处理器选型：不是越强越好
很多人一上来就问：用i7行不行？我的回答是：行，但你得先问问导弹的电源和散热答不答应。
导弹上的处理器选型，有几个硬指标：
- 功耗：一般控制在5W以内，超过10W就得考虑主动散热，这在导弹上很难实现
- 温度范围：军品级要求-55°C到+125°C，工业级根本扛不住
- 实时性：控制周期通常是1ms-5ms，中断响应得在微秒级
- 抗辐射：高空飞行时宇宙射线多，单粒子翻转能把程序跑飞
我个人习惯把处理器分成三类：
| 类型 | 代表型号 | 适用场景 | 我踩过的坑 |
|---|---|---|---|
| 高性能DSP | TMS320C6678 | 复杂控制律、多传感器融合 | 散热没做好，飞了一半过热保护 |
| FPGA+软核 | Xilinx Kintex-7 + MicroBlaze | 需要硬件加速、接口种类多 | 时序约束没做严，上电就跑飞 |
| ARM Cortex-R | TI TMS570 | 安全关键、需要锁步核 | 这个系列我比较放心，很少出问题 |
我的建议：别盲目追新。我见过有人用最新的Zynq UltraScale+，结果开发周期拖了一年，因为驱动库不成熟。选成熟的、经过验证的芯片，比什么都重要。
3.2 架构设计：模块化是王道
FCC的架构，我习惯分成三个模块：
- 采集模块：负责读IMU、GPS、气压计等传感器数据
- 解算模块：跑控制律、导航算法、制导律
- 输出模块：生成舵机指令、控制发动机
这三个模块，我建议用不同的处理器或核来跑。为什么？
你想想看，如果采集和解算混在一起，采集任务卡住了，解算也跟着停。导弹在空中，控制周期一断，后果你懂的。
下面这张图是我常用的FCC架构：
经验之谈：我建议采集模块用FPGA做，因为它可以并行处理多个传感器接口，延迟低。解算模块用DSP，浮点运算快。输出模块用ARM，接口丰富，方便和舵机通信。
3.3 冗余策略：别让单点故障毁了任务
导弹飞出去，不可能回来修。所以FCC必须考虑冗余。我常用的策略有三种：
3.3.1 三模冗余（TMR）
三个一模一样的FCC同时运行，输出结果通过表决器取多数。这是最可靠的方案，但成本也最高。
我曾经在一个项目中用过TMR，三个C6678并行跑。结果发现一个问题：三个板子同时上电，电流冲击太大，电源直接保护了。后来加了软启动电路才解决。
注意：TMR不是简单的三份拷贝。三个模块必须同步，时钟要同源，否则表决器会疯掉。我见过有人用三个独立晶振，结果三个模块的时钟漂移不一样，表决结果全是错的。
3.3.2 双机热备
主FCC工作，备FCC待机。主FCC故障时，备FCC无缝切换。这种方案成本适中，但切换时间是个问题。
我记得有一次测试，主FCC挂了，备FCC切换花了50ms。对于控制周期1ms的导弹来说，50ms足够它翻好几个跟头了。后来我们优化了切换逻辑，把时间压到了2ms以内。
3.3.3 异构冗余
用不同架构的处理器做冗余。比如一个用DSP，一个用FPGA+ARM。这样即使一种处理器有设计缺陷，另一种还能工作。
我个人比较喜欢这种方案。虽然开发工作量翻倍，但安全性确实高。而且不同处理器的故障模式不一样，不会同时失效。
3.4 避坑指南
这些年我总结了几条FCC设计的教训：
- 电源设计别省钱：FCC对电源纹波很敏感，我见过因为电源纹波大，ADC采集值跳变，导致控制律输出抖动的案例
- 看门狗要独立：别用处理器内部的看门狗，它自己挂了看门狗也没用。用外部独立看门狗芯片
- 代码要防跑飞：我习惯在代码里加软件陷阱，所有未使用的中断向量都指向复位函数
- 通信要加校验：CAN总线、串口通信，一定要加CRC校验。我遇到过电磁干扰导致通信数据错一位，舵机直接打到极限位置的情况
最后说一句：FCC设计没有完美的方案，只有最适合的。你得在性能、成本、可靠性之间找平衡。多听听老工程师的经验，少走弯路。
公众号:蓝海资料掘金营，微信deep3321