卫星星载计算机OBC的选型是每一个做航天电子、微小卫星、载荷平台的人绕不开的一道坎。我前后参与过几个不同量级卫星平台的电子学方案评审和器件选型从立方星到几百公斤级的遥感小卫星都碰过踩过的坑不算少。这篇文章不打算写成一份器件手册而是想把“怎么选、为什么这么选、选错了会怎样”这条链路讲透。OBC也就是On-Board Computer星载计算机是整星电子学的“大脑”负责遥测遥控、姿态控制解算、载荷数据管理、总线调度、故障检测与恢复这些核心任务。它跟地面上的工控机、嵌入式板卡完全不是一个逻辑——地面上你追求的是性能、成本、开发效率而星上你首先要回答的是这东西在辐射、真空、极端温差、单粒子效应面前能不能活下来活下来之后还能不能算对。适合读这篇的人包括刚入行的卫星电子工程师、做载荷配套的嵌入式开发者、以及需要给整星选型做决策的系统总体人员。我会把OBC的核心架构、处理器选型、总线接口、存储与冗余设计、抗辐射考量、以及实操中怎么一步步把方案定下来都掰开讲清楚。1. 先搞清楚OBC到底在整星里干什么活选型之前如果不把OBC的职责边界划清楚后面所有的参数对比都是空中楼阁。我见过太多团队一上来就纠结“用不用FPGA”“主频要多少”结果连这台计算机要接几路总线、要跑几个控制周期都没定选出来的东西要么性能过剩、要么根本带不动。1.1 OBC的核心任务清单星载计算机的活儿粗分下来有这么几大类。第一类是遥测遥控TTC数据处理地面发上来的指令要解析、校验、分发星上的状态量要采集、打包、下传。第二类是姿态与轨道控制AOCS解算这是实时性要求最高的一块通常要求控制周期在几十毫秒到几百毫秒量级涉及陀螺、星敏、磁强计的数据融合以及动量轮、磁力矩器的指令输出。第三类是载荷数据管理尤其是遥感类载荷图像数据量大OBC往往要负责缓存、压缩、格式化再通过高速总线送往下传通道。第四类是总线调度与健康管理整星上各种设备挂在总线上OBC通常是总线主控负责轮询、仲裁、超时处理同时还要做看门狗、故障检测、安全模式切换。这四类任务对计算资源的需求差异极大。TTC和健康管理是典型的低速率、高可靠任务AOCS是硬实时任务载荷数据管理是高速率、可容忍一定延迟的任务。选型时如果把这些任务全部压在一台OBC上那对处理器的实时性和吞吐量要求就会非常高如果拆成主控OBC加载荷处理单元选型逻辑就完全不同。我个人的经验是中小卫星尽量把AOCS和TTC放在同一台高可靠OBC上载荷数据处理单独用一台性能更强的单元这样既保证了核心控制的确定性又不会因为载荷的突发流量拖垮控制回路。1.2 为什么OBC的选型逻辑和地面嵌入式完全不同地面嵌入式选型你打开立创或者Digi-Key按主频、内存、外设、价格一筛基本就定了。星上不行因为有三个地面几乎不用考虑的约束辐射环境、热真空环境、以及不可维修性。辐射环境里最要命的是单粒子效应SEE包括单粒子翻转SEU、单粒子锁定SEL、单粒子瞬态SET。SEU会让寄存器或存储器里的位翻转SEL可能导致器件大电流烧毁SET会让组合逻辑输出毛刺。地面上一颗芯片跑一年可能一次翻转都没有星上在轨可能每天都有。热真空环境意味着没有空气对流散热只能靠传导和辐射器件的结温控制比地面苛刻得多。不可维修性意味着你没法像地面设备那样“重启一下就好”所有故障恢复逻辑必须在设计阶段就固化进去。所以OBC选型的本质是在性能、抗辐射能力、功耗、开发难度、成本这五个维度里找一个平衡点。这个平衡点没有标准答案取决于你的轨道高度、任务寿命、整星预算和团队能力。2. 处理器架构怎么选MCU、DSP还是FPGA这是选型里争议最大的一块。我参加过好几次评审每次都有人拍桌子说“必须上FPGA”也有人坚持“MCU足够”。其实这三种架构各有各的适用场景关键看你的任务画像。2.1 抗辐射MCU低复杂度任务的稳妥选择抗辐射MCU是传统OBC最主流的选择典型代表是各种经过辐照加固的处理器核比如基于SPARC或ARM架构的宇航级器件。这类器件的优势非常明确开发工具链成熟、软件生态好、功耗低、抗辐射指标有保证。你写C代码跑RTOS做任务调度跟地面开发差别不大团队上手快。它的短板也很明显算力有限。宇航级MCU的主频通常被压得很低一方面是因为辐照加固工艺本身会限制频率另一方面是高频下的时序余量和功耗都更难控制。如果你要跑复杂的图像处理或者高更新率的控制算法MCU会很吃力。另外宇航级MCU的价格通常是同性能商业器件的几十倍甚至上百倍采购周期也长动辄半年以上。我个人的判断是如果OBC主要负责TTC、总线管理、简单AOCS解算抗辐射MCU是最优解。任务寿命五年以上、轨道环境恶劣的场合优先选有飞行 heritage 的型号别为了省成本去赌商业器件。2.2 FPGA灵活但门槛高的方案FPGA在星上的应用越来越广热词里FPGA相关的内容占了很大比例这跟它在星载电子里的地位是匹配的。FPGA的核心优势是并行处理和接口灵活性。你可以用一片FPGA同时实现多路CAN控制器、SpaceWire接口、图像预处理流水线、以及自定义的仲裁逻辑这是MCU很难做到的。但FPGA用在OBC上有几个必须正视的问题。第一是抗辐射。商用FPGA在辐射环境下配置存储器CRAM会发生翻转导致逻辑功能改变必须做配置刷新scrubbing和三模冗余TMR。第二是开发难度。FPGA开发需要专门的硬件描述语言能力验证工作量大一个时序违例或者跨时钟域处理不当在轨就可能出致命问题。第三是功耗和资源。高性能FPGA功耗不低热设计压力大。我的经验是FPGA适合做OBC里的协处理单元或接口桥接而不是单独承担整机主控。比如用MCU做任务调度和健康管理用FPGA做高速数据通路和自定义接口两者通过总线或并行接口协作。这样既发挥了FPGA的并行优势又保留了MCU在软件可靠性和开发效率上的长处。2.3 DSP与专用处理器特定场景的补充DSP在星载OBC里出现得相对少主要用在需要大量定点或浮点运算的场合比如某些高精度姿态解算或者载荷信号处理。热词里“fpga定点数”“fpga定点数据”这类搜索说明很多人关心定点运算的实现这其实反映了星上算力受限的现实——浮点运算单元在抗辐射器件里往往更稀缺定点实现是常态。专用处理器比如某些面向控制的SoC集成了处理器核和可编程逻辑算是MCU和FPGA的折中。选这类器件时要特别注意它的抗辐射认证等级和飞行 heritage别被“宇航级”三个字忽悠要看到具体的TID总电离剂量和SEL阈值指标。2.4 架构选型对比表架构类型算力抗辐射成熟度开发难度功耗适用场景抗辐射MCU低到中高低低TTC、总线管理、简单AOCSFPGA中到高中需加固设计高中到高接口桥接、高速数据通路、并行处理DSP中到高中中中信号处理、定点运算密集任务SoC核逻辑中到高中中到高中综合任务、需要软硬协同这张表不是让你照着选而是帮你快速定位。实际选型时我建议先把任务按实时性和吞吐量画个二维图落在哪个象限架构方向就清楚了。3. 总线接口CAN和SpaceWire怎么配总线是OBC的“神经”选错了总线后面所有设备的对接都会变成噩梦。热词里CAN和SpaceWire出现频率很高这两个确实是星上最常用的两种总线但它们的定位完全不同。3.1 CAN总线低速控制设备的主力CAN总线在星上主要用于低速控制设备互联比如磁力矩器、太阳翼驱动机构、温度采集单元、推进系统控制器。它的优势是多主架构、差分传输、抗干扰能力强、协议成熟。CAN的仲裁机制保证了高优先级报文能优先发送这对控制指令的实时性很友好。但CAN有几个坑要注意。第一是终端电阻热词里“can协议终端电阻”被搜了很多次说明这是常见问题。CAN总线两端必须各接一个120欧姆终端电阻中间节点不能接否则阻抗不匹配会导致通信误码。第二是总线长度与速率的关系CAN在1Mbps下总线长度不能超过40米星上虽然距离短但如果走线绕来绕去也要核算。第三是bus-off状态热词里“应用层整车can线进入bus-off”虽然是车载场景但星上同样会遇到。当CAN控制器检测到发送错误计数超过阈值会进入bus-off停止收发。OBC必须有bus-off恢复逻辑否则一条支路的故障会拖垮整个总线。CAN FD是CAN的升级版数据段速率更高、单帧数据更长热词里也有出现。星上如果载荷数据量不大CAN FD可以替代部分SpaceWire的功能简化总线架构。但CAN FD的抗辐射收发器选型要谨慎不是所有宇航级CAN收发器都支持FD。3.2 SpaceWire高速载荷数据的通道SpaceWire是专门为航天应用设计的高速串行总线速率从几十Mbps到几百Mbps用于载荷数据、大容量存储、高速传感器的互联。它的特点是点对点或路由交换、全双工、低延迟、协议简单。相比CANSpaceWire更适合大数据量传输比如相机图像、雷达原始数据。SpaceWire的选型要点在于接口IP的成熟度和路由配置。很多FPGA厂商提供SpaceWire IP核但宇航级应用要确认IP是否经过辐射验证。另外SpaceWire的链路初始化、时间码分发、故障恢复机制都需要在OBC软件里实现这部分工作量不小。3.3 总线配置的实操建议我一般建议中小卫星采用CAN为主、SpaceWire为辅的混合架构。控制类设备全部挂CAN载荷和存储挂SpaceWireOBC同时具备两种接口。这样既保证了控制的实时性和可靠性又满足了载荷数据的带宽需求。如果整星设备数量少、数据量小可以只用CAN把CAN FD用起来简化设计。如果载荷数据量特别大比如高分辨率遥感那SpaceWire甚至更高速的接口就是必须的OBC可能需要FPGA来做协议转换和路由。注意总线选型时一定要把总线负载率算清楚。CAN总线在重负载下延迟会显著增加一般建议控制在50%以下。SpaceWire虽然速率高但路由跳数和缓冲区深度也会影响实际吞吐。4. 存储与冗余设计别让单点故障毁掉整星OBC的存储系统包括程序存储、数据存储和参数存储。星上存储面临的挑战是单粒子翻转导致的位错误以及长期在轨的擦写寿命。4.1 程序存储EDAC和冗余引导程序存储器通常用PROM或Flash。PROM抗辐射好但不可改写适合存引导程序Flash可改写但需要EDAC错误检测与纠正保护。我的做法是引导程序放PROM应用程序放Flash并做EDAC同时保留一份黄金备份。如果Flash里的程序校验失败自动从备份区恢复或者切到安全模式等待地面指令。EDAC的实现方式有硬件和软件两种。硬件EDAC用专用芯片或FPGA逻辑速度快但增加器件软件EDAC用算法在读写时校验灵活但占用CPU。对于MCU方案我倾向于用带硬件ECC的存储器省心。对于FPGA方案可以在逻辑里实现EDAC但要注意EDAC本身的抗辐射设计。4.2 数据存储MRAM、FRAM还是NAND数据存储的选择取决于数据量和写入频率。MRAM和FRAM抗辐射好、写入快、寿命长但容量小、价格高适合存关键参数和日志。NAND Flash容量大、成本低但需要坏块管理和ECC且存在单粒子锁定风险。我参与过的一个项目OBC用FRAM存关键遥测参数用NAND Flash存载荷数据缓存两者都做了ECC。实测下来FRAM在辐射环境下的表现确实稳NAND则需要更复杂的纠错逻辑。如果数据量不大优先用MRAM或FRAM减少软件复杂度。4.3 冗余架构双机热备还是三模冗余冗余是OBC可靠性的最后一道防线。常见方案有双机热备、双机冷备、三模冗余TMR。双机热备是两台OBC同时运行一台主一台备主故障时切换冷备是备机不通电切换时间长但功耗低TMR是三台同时运行表决输出可靠性最高但成本和功耗也最高。中小卫星通常用双机热备切换时间在秒级。切换逻辑要设计得足够简单可靠避免切换本身成为故障源。我见过一个案例切换逻辑里用了复杂的握手协议结果主备机同时认为对方故障来回切换最后整星进入安全模式。切换逻辑越简单越好最好用硬件看门狗加简单的状态机实现。提示冗余设计时一定要做故障注入测试模拟主机关机、总线断线、存储器错误等场景验证切换逻辑的正确性。这个测试在地面做充分在轨才能放心。5. 抗辐射与热设计选型里最容易被低估的部分抗辐射和热设计是OBC选型里最“硬”的部分也是最容易在早期被忽略、后期付出惨重代价的部分。5.1 抗辐射指标怎么看选器件时抗辐射指标主要看三个TID总电离剂量、SEL单粒子锁定阈值、SEU单粒子翻转率。TID决定了器件能承受多少累积辐射单位是krad(Si)低轨卫星通常要求10-30krad中高轨和长寿命任务要求更高。SEL阈值决定了器件会不会被单粒子锁定烧毁宇航级器件一般要求SEL免疫或阈值高于80MeV·cm²/mg。SEU率决定了翻转发生的频率单位是错误数/器件/天这个指标直接影响EDAC和刷新策略的设计。我的经验是不要只看器件手册上的“宇航级”标签要拿到具体的辐射测试报告。有些器件标称宇航级但TID只有10kradSEL阈值也不高用在长寿命任务上就是隐患。另外系统级加固可以弥补器件级的不足比如用屏蔽增加TID余量用TMR降低SEU影响用限流保护应对SEL。5.2 热设计真空里没有风扇星上散热靠传导和辐射没有对流。OBC的功耗最终要通过安装面传导到结构板再辐射到太空。选型时要算清楚结温确保在最坏工况下不超过器件的降额限值。我一般会要求OBC的功耗在5W到20W之间具体取决于整星热控能力。功耗太低的OBC往往性能不足功耗太高则热设计压力大。如果OBC功耗超过20W就要考虑专门的散热路径比如热管或扩热板。热设计还有一个容易被忽略的点是温度循环。星上进出阴影区会导致温度剧烈变化焊点和封装材料会承受热应力。选型时要关注器件的温度循环寿命尤其是BGA封装的大芯片焊点疲劳是常见失效模式。5.3 抗辐射与热设计的协同抗辐射和热设计不是孤立的。比如为了抗辐射加屏蔽会增加重量也可能影响散热为了提高性能选高频器件功耗和发热都会增加热设计难度上升。选型时要把这两个维度放在一起权衡而不是先选器件再补热设计。我个人的做法是在方案阶段就画一张功耗-热阻-结温的链路图把每个器件的功耗、热阻、降额限值都列出来算出最坏情况下的结温。如果结温余量不足要么换低功耗器件要么改散热设计要么降频使用。6. 实操选型流程从需求到定型前面讲了这么多维度最后落到实操选型应该怎么一步步走。我把自己常用的流程整理出来供参考。6.1 第一步明确任务需求先把OBC要承担的任务列全包括控制周期、数据吞吐量、接口类型和数量、存储容量、任务寿命、轨道环境、整星功耗预算、成本预算。这些需求要量化不能写“高性能”“低功耗”这种模糊词。6.2 第二步初筛候选器件根据任务需求从宇航级器件库里初筛。重点关注飞行 heritage、辐射指标、供货周期、开发工具链。这一步不要贪多选3到5个候选就够了。6.3 第三步架构方案对比对每个候选画出OBC的架构框图包括处理器、存储器、总线接口、冗余设计。对比各方案的性能、功耗、成本、开发难度、风险。这一步最好做成表格方便评审。6.4 第四步关键指标核算对选定的架构核算关键指标CPU负载率、总线负载率、存储容量余量、功耗余量、结温余量、辐射余量。任何一项余量不足都要回到上一步调整。6.5 第五步原型验证选型不能只停留在纸面。做一块原型板把关键接口跑通做辐射测试如果条件允许做热真空测试。原型验证会发现很多纸面上看不到的问题比如时序违例、电源噪声、接口兼容性。6.6 第六步评审与定型原型验证通过后组织评审确认选型方案。评审时要特别关注风险项和应对措施比如供货风险、辐射风险、热风险。定型后器件的采购和筛选screening要严格按照宇航标准执行。注意选型流程不是线性的很多时候要迭代。比如原型验证发现功耗超标就要回到架构方案调整。迭代不可怕可怕的是跳过验证直接定型。7. 常见问题与排查技巧实录这一部分是我在实际项目中遇到过的典型问题整理成速查表希望能帮你少走弯路。7.1 常见问题速查表问题现象可能原因排查思路解决方法CAN通信误码率高终端电阻缺失或阻值不对测量总线两端电阻应为60欧姆左右补接120欧姆终端电阻CAN节点频繁bus-off发送错误计数超阈值检查线缆屏蔽、共地、波特率配置增加bus-off恢复逻辑检查物理层FPGA配置丢失CRAM单粒子翻转读取配置回读对比原始配置增加配置刷新scrubbing和TMR存储器数据错误SEU导致位翻转读取EDAC错误计数启用EDAC增加定期刷新OBC结温超标功耗过高或散热路径不畅测量安装面温度核算热阻降频、增加散热路径、换低功耗器件主备切换失败切换逻辑复杂或握手协议缺陷做故障注入测试观察切换过程简化切换逻辑用硬件看门狗SpaceWire链路不稳定链路初始化或时钟抖动检查链路速率、电缆长度、连接器降低速率优化时钟设计检查连接器7.2 独家避坑技巧第一个坑是忽略总线负载率。我见过一个项目CAN总线上挂了十几个节点负载率算下来超过70%结果控制指令延迟严重姿态控制周期抖动。后来把非关键设备移到另一条总线负载率降到40%以下问题解决。总线负载率一定要在方案阶段算清楚留足余量。第二个坑是EDAC配置错误。EDAC的纠错能力和存储器的组织方式有关配置错了可能只能检错不能纠错或者纠错引入额外延迟。我建议EDAC配置完成后做错误注入测试手动翻转一位看系统能否正确纠正。第三个坑是热设计余量不足。地面测试时OBC功耗正常但在真空环境下散热能力下降结温超标。热真空测试必须做而且要在最坏工况下做比如最高环境温度加最大功耗。第四个坑是器件筛选不到位。宇航级器件采购后还要做筛选screening包括温度循环、老炼、密封性检查等。我见过因为筛选不严在轨出现器件失效的案例。筛选流程不能省这是用血泪换来的教训。7.3 调试工具与手段调试OBC时遥测数据是生命线。所有关键状态量都要下传包括CPU负载、存储器EDAC计数、总线错误计数、温度、电压、电流。地面测试时可以用仿真器单步调试但在轨只能靠遥测。所以遥测设计要足够细致能定位到具体模块。另外看门狗要分级。一级看门狗在处理器内部检测软件死循环二级看门狗在FPGA或独立芯片里检测处理器完全失效三级看门狗在地面通过遥测超时判断。分级看门狗能覆盖不同级别的故障。8. 选型之外团队能力与供应链的考量最后想聊两个容易被忽略但实际影响很大的因素团队能力和供应链。8.1 团队能力匹配选型不能只看器件性能还要看团队能不能驾驭。FPGA方案性能好但如果团队没有硬件描述语言开发经验验证工作跟不上风险就很大。抗辐射MCU方案性能一般但软件团队熟悉开发效率高反而是更稳妥的选择。我的建议是选型时把团队能力作为一票否决项。如果团队没有某类器件的开发经验要么提前培训要么选更熟悉的方案要么引入外部支持。别为了追求“先进”而选一个团队hold不住的方案。8.2 供应链与国产化宇航级器件的供应链是另一个大问题。进口器件采购周期长、价格高、有出口管制风险。国产宇航级器件近年来进步很快很多型号已经有了飞行 heritage价格和供货周期也更有优势。选型时我一般会优先考虑有飞行 heritage 的国产器件同时保留进口器件的备选方案。关键是要拿到器件的辐射测试报告、筛选报告、可靠性数据不能只看宣传资料。供应链风险要提前评估尤其是长寿命任务器件的长期供货能力很重要。8.3 成本与进度的平衡OBC选型还要考虑成本和进度。宇航级器件贵开发周期长测试工作量大。如果任务预算有限、进度紧张就要在性能和成本之间找平衡。我的经验是核心控制部分用高可靠器件非关键部分可以用商业器件加系统级加固这样既能保证可靠性又能控制成本。但有一条底线涉及整星安全的功能绝不能用商业器件赌。比如看门狗、安全模式切换、关键存储这些必须用经过验证的宇航级器件。选型这件事说到底是在约束条件下找最优解。没有完美的方案只有最适合当前任务的方案。我踩过的坑告诉我早做需求分析、早做原型验证、早做风险识别比后期补救要省力得多。希望这些经验能帮到正在做OBC选型的你。