1. 星载计算机选型的底层逻辑为什么不能直接照搬地面方案很多人第一次接触星载计算机OBCOn-Board Computer选型时习惯性地拿地面工控机或者嵌入式开发板的思路去套——看主频、看内存、看接口数量、比价格。这套逻辑放在地面没问题放到天上就是灾难。我自己刚开始做航天电子那几年也犯过这个毛病拿工业级ARM核心板做了个方案结果一查辐射指标单粒子翻转率SEU高得离谱根本没法用。星载计算机和地面计算机最本质的区别在于运行环境的极端性。太空里没有空气对流散热温差可以从零下几十度到零上一百多度还有高能粒子、宇宙射线、单粒子效应这些东西在持续轰击芯片。一颗芯片在地面跑十年不出问题到了轨道上可能几天就被打翻了。所以选OBC的第一原则不是性能而是可靠性设计——你的系统能不能在辐射环境里活下来能不能在出错之后自己恢复。这就引出了OBC选型的几个核心维度处理器架构、抗辐射等级、总线接口、冗余架构、软件生态。这几个维度不是孤立的它们互相制约。比如你选了高性能的FPGA做处理核心就得考虑FPGA的配置存储器CRAM在辐射下会不会丢配置你选了CAN总线做星内通信就得考虑CAN控制器在单粒子事件下的总线锁定问题。每一个选择背后都有一堆坑。这篇文章主要面向几类人一是刚入行做航天电子设计的工程师需要一套系统的选型方法论二是做FPGA或嵌入式开发想往航天方向转的朋友需要了解星载和地面的差异三是项目管理者需要理解OBC选型中的关键权衡点以便做技术决策。我会从架构设计、核心器件选型、总线接口、冗余策略、实操验证几个层面展开尽量把每个选择的“为什么”讲清楚。注意本文讨论的是通用星载计算机选型方法论不涉及任何具体型号的采购建议或供应商推荐。所有参数和案例均基于公开的工程实践经验。2. 处理器架构怎么选从MCU到FPGA再到SoC的取舍2.1 三种主流架构的适用场景对比星载计算机的处理器架构大致分三类抗辐射MCU/CPU、SRAM型FPGA、抗辐射SoC。这三类没有绝对的优劣关键看任务需求。抗辐射MCU/CPU的典型代表是经过辐射加固的PowerPC或SPARC架构处理器。这类器件的优势是软件生态成熟、开发门槛低、功耗可控。你拿过来就能跑实时操作系统任务调度、内存管理这些都有现成方案。缺点是性能天花板明显主频通常在一两百兆赫兹量级算力有限。适合做星务管理、遥测遥控、姿态控制这类对算力要求不高的任务。SRAM型FPGA比如Xilinx的Virtex系列抗辐射型号是另一条路线。FPGA的优势是并行处理能力强、接口灵活、可重构。你可以用FPGA实现自定义的协处理器、图像处理流水线、高速接口协议栈。但FPGA有个致命问题SRAM型FPGA的配置存储器对辐射敏感单粒子翻转会导致配置位翻转轻则逻辑功能异常重则整个设计崩溃。所以用FPGA做OBC核心必须配套配置刷新机制和三模冗余TMR设计。抗辐射SoC是近些年的趋势把处理器核和FPGA逻辑集成在一颗芯片上。这类器件兼顾了处理器的软件生态和FPGA的灵活性但选型时要注意处理器核和FPGA逻辑之间的总线带宽、存储一致性、中断延迟这些细节。不是所有SoC都适合做OBC主控有些SoC的处理器核只是辅助角色算力不足以跑复杂任务。架构类型典型算力抗辐射能力开发难度适用任务抗辐射MCU/CPU100-500 MIPS高器件级加固低星务管理、姿控SRAM型FPGA取决于设计中需TMR刷新高图像处理、高速接口抗辐射SoC500-2000 MIPS中高中高综合任务、AI推理2.2 选型时的关键参数计算选处理器不能只看主频要算实际任务负载。我一般用这套方法估算先列出所有任务的最坏执行时间WCET然后算总负载率。比如星务管理任务每100ms执行一次每次WCET是5ms那负载率就是5%。姿控任务每10ms执行一次WCET是2ms负载率20%。把所有任务的负载率加起来如果超过70%说明处理器余量不足需要换更高性能的器件或者优化任务调度。对于FPGA方案要算逻辑资源利用率和时序余量。逻辑资源利用率建议控制在70%以内留出空间做TMR和后续功能扩展。时序余量要看最差情况下的建立时间和保持时间一般要求正余量不低于20%。我见过一个项目FPGA设计综合出来时序余量只有5%结果在辐照试验中温度变化导致时序违例功能直接挂了。实操心得选处理器时一定要留至少30%的性能余量。太空环境下的降额设计是硬性要求不是可选项。地面跑70%负载没事天上可能因为温度或辐射导致性能下降余量不够就是死机。2.3 FPGA做OBC核心的配置刷新设计如果你决定用SRAM型FPGA做OBC核心配置刷新是必须做的。原理很简单定期从外部存储器读取正确的配置数据重新写入FPGA的配置存储器把被辐射打翻的位纠正回来。刷新周期怎么定这取决于轨道辐射环境和FPGA的配置位数。低轨LEO环境下单粒子翻转率大约在10^-7到10^-5次/位/天量级。假设你的FPGA配置数据是100Mbit那每天预期的翻转次数就是10到1000次。如果刷新周期是1秒那两次刷新之间平均有0.0001到0.01次翻转概率很低。但如果刷新周期是1分钟翻转概率就上来了。我一般建议刷新周期不超过1秒对于高辐射轨道如MEO或GEO要缩短到100ms以内。刷新方式可以用外部处理器控制刷新或FPGA内部自刷新。外部处理器刷新更可靠因为处理器本身可以做冗余内部自刷新省资源但刷新逻辑本身也可能被辐射影响。// 简化的FPGA配置刷新状态机示意 module config_refresh ( input wire clk, input wire rst_n, output reg [23:0] addr, output reg [31:0] data, output reg wr_en, input wire [31:0] config_data, input wire refresh_trigger ); // 状态定义 localparam IDLE 2b00; localparam READ 2b01; localparam WRITE 2b10; localparam DONE 2b11; reg [1:0] state; reg [23:0] cnt; always (posedge clk or negedge rst_n) begin if (!rst_n) begin state IDLE; addr 24d0; wr_en 1b0; end else begin case (state) IDLE: begin if (refresh_trigger) begin state READ; addr 24d0; end end READ: begin data config_data; // 从外部存储器读取 state WRITE; end WRITE: begin wr_en 1b1; state DONE; end DONE: begin wr_en 1b0; addr addr 1; if (addr 24hFFFFFF) begin state IDLE; end else begin state READ; end end endcase end end endmodule这段代码只是示意实际工程中要考虑刷新过程中的读写冲突、刷新带宽对正常逻辑的影响、刷新失败的重试机制。刷新逻辑本身也要做TMR否则刷新控制器挂了整个FPGA就失控了。3. 总线接口选型CAN、SpaceWire与高速总线的博弈3.1 CAN总线的星载适用性与局限CAN总线在地面车载领域用得很多很多人就想直接搬到星上。CAN的优势是成熟、便宜、抗干扰能力不错、多主架构。但星载CAN有几个坑要注意。首先是CAN控制器的抗辐射问题。商用CAN控制器芯片比如常见的MCP2515没有经过辐射加固单粒子事件可能导致控制器进入bus-off状态或者寄存器翻转。我遇到过CAN控制器在辐照下突然停止发送复位后才能恢复。所以星载CAN要么用抗辐射型号要么在系统层面做总线冗余和控制器监控。其次是CAN总线的仲裁机制。CAN用非破坏性仲裁ID号小的报文优先发送。星上如果多个节点同时发数据低优先级节点可能一直抢不到总线。我见过一个项目姿控计算机的CAN报文ID设得比较大结果被遥测数据挤得发不出去姿态控制周期都乱了。解决办法是合理分配ID优先级关键控制指令用最小ID。CAN的速率也是个限制。标准CAN最高1MbpsCAN FD可以到5Mbps以上但星上长距离传输时速率要降额。如果星内通信距离超过几米1Mbps可能都跑不稳。这时候就要考虑SpaceWire或者LVDS。总线类型速率拓扑抗辐射考虑适用场景CAN1Mbps总线型需冗余监控低速遥测遥控CAN FD5Mbps总线型同上中速数据采集SpaceWire200Mbps点对点/路由需协议加固高速载荷数据LVDS数百Mbps点对点需编码保护图像/高速ADC3.2 SpaceWire的协议栈设计要点SpaceWire是专门为航天设计的高速串行总线速率可以到200Mbps甚至更高。它的物理层是LVDS链路层有字符级流控和错误检测。但SpaceWire协议本身没有端到端的可靠性保证需要上层协议来补。用SpaceWire做OBC和载荷之间的通信我一般会加一层包协议包含包序号、CRC校验、重传机制。SpaceWire的时间码功能可以用来做全局时间同步精度可以到微秒级。如果多个节点需要协同工作时间码是必须的。SpaceWire的路由器选型要注意端口数和阻塞特性。有些路由器的内部交换结构是阻塞的多个端口同时往一个端口发数据会丢包。选型时要看路由器的非阻塞带宽和缓冲区深度。我建议缓冲区深度至少能存两个最大包否则突发数据容易丢。3.3 总线冗余与故障切换策略星载总线的冗余设计一般有两种冷备份和热备份。冷备份是主总线故障后切换到备份总线切换时间可能到秒级热备份是两条总线同时工作接收端选优切换时间可以到毫秒级甚至微秒级。对于关键控制回路我建议用热备份。比如姿控计算机和敏感器之间的总线如果切换时间太长控制周期就断了姿态可能失稳。热备份的实现方式可以是双CAN总线或者双SpaceWire链路发送端同时发两份接收端做多数表决或先到先取。注意总线冗余不是简单地把线接两份就行。两条总线的电气隔离、地回路设计、切换逻辑的抗辐射加固都要考虑。我见过双CAN总线因为共地导致一条总线短路把另一条也拉挂的案例。4. 冗余架构设计从TMR到冷热备份的工程权衡4.1 三模冗余TMR的实现细节TMR是星载计算机最常用的冗余方式三个相同的模块同时执行输出做多数表决。理论上只要不超过一个模块出错系统就能正常工作。但TMR有几个工程细节容易翻车。首先是表决器的可靠性。表决器本身如果被辐射打翻TMR就失效了。所以表决器也要做加固或者用自校验逻辑。我一般建议表决器用三模冗余的表决器听起来有点绕但确实有必要。其次是共因故障。三个模块如果共用同一个时钟源、同一个电源、同一个存储器那这些共用部分出问题三个模块一起挂。TMR只能防独立故障防不了共因故障。所以TMR设计要尽量做到模块级隔离独立时钟、独立电源、独立存储器。第三是同步问题。三个模块如果不同步表决器就不知道哪个输出对应哪个周期。同步方式可以用硬件同步信号或者软件时间戳。硬件同步更可靠但布线复杂软件同步灵活但同步精度受处理器负载影响。4.2 冷备份与热备份的适用场景不是所有任务都需要TMR。TMR的成本高、功耗大、体积大对于非关键任务冷备份或热备份就够了。冷备份适合故障容忍时间长的任务。比如数据存储计算机挂了之后几分钟内恢复就行冷备份完全够用。冷备份的设计要点是故障检测和切换可靠性。故障检测可以用看门狗加心跳信号切换可以用继电器或模拟开关。继电器的抗辐射性能要查有些继电器在辐射下触点会粘连。热备份适合故障容忍时间短的任务。比如姿控计算机切换时间要控制在毫秒级。热备份的实现可以是双机热备两个模块同时运行一个主一个从或双机互备两个模块互相监控。双机热备的难点是状态同步主从之间的数据要实时同步否则切换后状态不一致。冗余方式故障容忍时间资源开销适用任务设计难点TMR零连续3倍以上姿控、关键控制表决器加固、同步热备份毫秒级2倍星务管理状态同步冷备份秒到分钟级1.5倍数据存储故障检测、切换4.3 冗余切换的实操验证方法冗余设计做完怎么验证它真的能工作我一般做故障注入测试人为制造故障比如拉低某个模块的电源、注入错误数据、模拟单粒子翻转看系统能不能正确检测并切换。故障注入可以在地面测试阶段做用故障注入板或者软件模拟。软件模拟方便但覆盖不了硬件故障故障注入板更真实但需要专门设计。我建议两种都做软件模拟覆盖逻辑故障硬件注入覆盖电气故障。切换成功的判据要明确切换时间、切换后的功能正确性、切换过程中的数据完整性。我见过一个项目切换时间达标了但切换过程中丢了几个控制周期导致姿态出现抖动。所以切换逻辑要保证切换过程对上层透明不能丢数据。5. 抗辐射设计与验证从器件选型到系统级试验5.1 辐射效应与加固策略太空辐射对电子器件的影响主要有三种总剂量效应TID、单粒子效应SEE、位移损伤DD。TID是长期累积的导致器件参数漂移、漏电流增大、最终失效。SEE是单个粒子击中导致的瞬态或永久故障包括单粒子翻转SEU、单粒子锁定SEL、单粒子烧毁SEB。DD主要是中子或质子导致的晶格损伤。选器件时TID指标一般要求达到100krad(Si)以上取决于轨道和任务寿命SEL阈值要高于80MeV·cm²/mg不锁定SEU率要满足任务要求。这些指标在器件的数据手册里都有但要注意测试条件和实际使用条件的差异。有些器件的TID指标是在特定偏置条件下测的你的实际电路偏置不同TID表现可能不一样。系统级加固策略包括降额设计电压、电流、温度都留余量、屏蔽用钽板或铝板遮挡、冗余TMR、备份、纠错编码EDAC保护存储器、看门狗监控处理器跑飞。5.2 辐照试验的实操流程辐照试验是验证抗辐射设计的必要环节。流程一般是试验方案设计→器件测试→板级测试→系统级测试→数据分析。试验方案要明确辐射源类型质子、重离子、伽马射线、注量率、测试向量、判据。测试向量要覆盖最坏工作模式不能只测空闲状态。我见过一个项目辐照试验时处理器跑的是简单循环结果在轨跑复杂任务时出现了SEU因为复杂任务下处理器内部状态更多翻转概率更高。板级测试时在线监测很重要。要实时记录电流、电压、关键信号一旦发现异常立即记录现场。我一般用示波器加逻辑分析仪同时抓示波器看电源和时钟逻辑分析仪看总线和控制信号。数据要带时间戳存储方便事后分析。系统级测试要把OBC和其他分系统连起来模拟真实工作场景。比如姿控OBC要和敏感器、执行机构连看辐照下控制回路会不会失稳。系统级测试更容易暴露接口兼容性和时序问题。5.3 在轨故障案例与经验总结我参与过的一个低轨遥感项目OBC用的是抗辐射FPGA加TMR设计。在轨运行三个月后遥测数据显示某一天出现了连续三次表决不一致。事后分析发现是时钟芯片在单粒子事件下输出毛刺导致三个FPGA模块同时采样到错误时钟TMR表决器也采到了错误数据。这就是典型的共因故障——时钟芯片是三个模块共用的它出问题TMR也救不了。后来改进方案是时钟源也做冗余三个模块各用一个时钟表决器用异步表决加时间窗机制。这个案例说明TMR设计要追到最底层的共用资源把所有共因故障路径都找出来。另一个案例是CAN总线在轨bus-off。某卫星的CAN总线在运行半年后某个节点的CAN控制器进入bus-off导致该节点失联。排查发现是CAN收发器在单粒子事件下输出错误电平导致总线错误计数累积到bus-off。改进方案是CAN控制器加自动恢复逻辑检测到bus-off后自动复位并重新初始化。实操心得在轨故障分析一定要结合遥测数据和地面复现。遥测数据能告诉你“什么时候出了什么问题”地面复现能告诉你“为什么出这个问题”。两者缺一不可。6. 软件生态与开发工具链选型时容易被忽视的维度6.1 实时操作系统RTOS的星载适配OBC的软件生态往往比硬件更影响开发效率。抗辐射处理器通常有配套的RTOS比如VxWorks、RTEMS、或者厂商自研的RTOS。选型时要看RTOS的确定性、内存占用、驱动支持、认证情况。确定性是星载RTOS的核心要求。任务调度延迟、中断响应时间、上下文切换时间都要有最坏情况保证。我一般要求中断延迟不超过10微秒任务切换不超过20微秒。这些指标在RTOS的数据手册里不一定有需要自己测。内存占用要算清楚。星载处理器的内存通常不大几十MB到几百MBRTOS内核加驱动加应用要留至少30%余量。我见过一个项目RTOS加驱动占了80%内存应用只剩20%后来加功能加不进去只能换处理器。6.2 FPGA开发工具链的选型考量FPGA开发工具链的选型要看器件支持、综合效率、仿真验证能力、抗辐射设计支持。Xilinx的Vivado、Intel的Quartus、Microchip的Libero各有优劣。抗辐射设计支持是个关键点。有些工具链有TMR自动插入功能可以自动把设计中的触发器做三模冗余。但自动插入的TMR不一定最优可能引入额外的时序问题。我一般建议手动TMR关键路径自动TMR做辅助。仿真验证能力要看时序仿真和故障仿真。时序仿真验证设计在 worst-case 条件下的时序余量故障仿真验证TMR设计在单点故障下的行为。故障仿真可以用故障注入工具在仿真中随机翻转触发器或组合逻辑看输出是否正确。6.3 软件验证与在轨维护策略星载软件的验证比地面软件严格得多。单元测试、集成测试、系统测试、验收测试每个环节都要有覆盖率要求。我一般要求语句覆盖率100%、分支覆盖率100%、MC/DC覆盖率100%。对于关键模块还要做形式化验证。在轨维护策略要考虑软件上注和参数调整。软件上注要保证完整性和安全性上注数据要加CRC校验和数字签名上注过程要分步确认上注失败要能回滚。参数调整要有限制不能随便改否则可能把系统改挂。我参与过的一个项目在轨软件上注时因为存储器写入时序问题上注了一半就失败了导致OBC变砖。后来改进方案是双区存储一个区跑当前软件另一个区接收新软件上注完成后原子切换。这样即使上注失败当前软件也不受影响。7. 常见问题与排查技巧实录7.1 选型阶段的典型误区误区一只看性能不看可靠性。我见过一个项目为了跑AI推理选了高性能GPU结果GPU的TID指标只有10krad根本扛不住任务寿命。后来只能加钽板屏蔽但屏蔽又导致散热问题。选型时可靠性指标是一票否决项性能再高可靠性不达标也不能用。误区二忽视软件生态。有些抗辐射处理器性能很好但RTOS和驱动支持很差开发效率极低。我一般建议选软件生态成熟的处理器哪怕性能低一点。开发时间也是成本而且软件bug比硬件bug更难查。误区三冗余设计过度。TMR不是万能的有些任务用冷备份就够了。过度冗余导致功耗、体积、成本都上去了可靠性反而可能因为复杂度增加而下降。冗余设计要基于任务的关键性关键任务TMR非关键任务冷备份。7.2 调试阶段的常见故障与排查故障现象可能原因排查方法解决措施FPGA配置丢失单粒子翻转读回配置数据对比加配置刷新CAN bus-off收发器故障查总线错误计数加自动恢复TMR表决不一致共因故障查共用资源隔离共用资源处理器跑飞SEU查看门狗日志加EDAC看门狗总线数据错误时序违例查时序余量降频或优化设计排查故障时先定位是硬件还是软件问题。硬件问题看电源、时钟、信号完整性软件问题看日志、看内存、看任务调度。我一般用二分法把系统分成两半先排除一半再排除另一半逐步缩小范围。7.3 独家避坑技巧汇总技巧一电源降额要算最坏情况。不是简单地把电压降10%要算最坏情况下的负载电流和最坏情况下的输入电压然后看电源芯片能不能稳住。我一般要求电源余量不低于30%。技巧二时钟树要加毛刺滤波。单粒子事件可能导致时钟毛刺毛刺会导致触发器误触发。时钟树上加RC滤波或施密特触发器可以滤掉窄毛刺。但滤波会引入延迟要算清楚对时序的影响。技巧三存储器要加EDAC。SRAM和DRAM都会受SEU影响EDAC可以纠正单比特错误、检测双比特错误。EDAC的纠错能力和延迟要算清楚不能影响处理器性能。技巧四看门狗要独立时钟。看门狗如果用处理器时钟处理器挂了看门狗也挂了。看门狗要用独立时钟源最好是独立电源。看门狗的喂狗逻辑要多条件不能简单定时喂否则处理器跑飞了还在喂狗。技巧五在轨数据要定期下传。在轨故障分析靠遥测数据遥测数据要定期下传不能等故障了才下传。我一般建议每天下传一次关键遥测包括电源、温度、总线状态、看门狗计数。8. 从需求到方案一个完整的选型决策流程8.1 需求分析与指标分解选型的第一步是需求分析。任务寿命、轨道类型、可靠性要求、算力需求、接口需求、功耗预算、体积重量限制这些都要明确。任务寿命决定TID指标。低轨5年任务TID要求一般100krad高轨10年任务TID要求可能到300krad。轨道类型决定辐射环境。LEO的SEU率比GEO低但南大西洋异常区SAA的辐射通量高要特别考虑。算力需求要量化。不是“我要跑AI”而是“我要跑多大的神经网络、多少帧率、多少精度”。量化之后才能选处理器。接口需求要列清单CAN几路、SpaceWire几路、LVDS几路、离散IO多少。功耗预算要算总和处理器、FPGA、存储器、接口芯片、电源转换损耗。8.2 方案对比与决策矩阵把候选方案列出来用决策矩阵打分。维度包括可靠性、性能、功耗、成本、开发难度、供货周期。每个维度给权重每个方案打分算加权总分。维度权重方案A抗辐射CPU方案BFPGATMR方案CSoC可靠性30%978性能20%598功耗15%867成本15%657开发难度10%846供货周期10%765加权总分7.56.67.2决策矩阵不是万能的但能帮你理清思路。加权总分高的不一定选还要看关键约束。比如供货周期如果是一票否决项那供货周期短的方案优先。8.3 原型验证与迭代优化方案定了之后先做原型验证。原型不用做全功能把关键路径打通就行。比如处理器加存储器加总线接口跑一个简单的任务验证基本功能。原型验证通过后做工程样机。工程样机要覆盖所有接口和所有工作模式做环境试验温度、振动、辐照。环境试验中发现问题迭代优化设计。迭代优化要有优先级。可靠性问题优先解决性能问题其次成本问题最后。我见过一个项目为了降成本换了便宜的连接器结果振动试验中连接器松动导致整个OBC失效。可靠性问题不能妥协。最后分享一个小技巧选型时多和用过的人聊。数据手册上的指标是理想条件下的实际使用中的坑只有用过的人知道。我一般会找同轨道、同任务类型的项目团队聊问他们用了什么方案、遇到了什么问题、怎么解决的。这些信息比数据手册值钱得多。