企业官网建设流程全解析

卫星星载计算机（OBC）的选型，是每一个做航天电子、微小卫星、载荷平台的人绕不开的一道坎。我前后参与过几个不同量级卫星平台的电子学方案评审和器件选型，从立方星到几百公斤级的遥感小卫星都碰过，踩过的坑不算少。这篇文章不打算写成一份器件手册，而是想把“怎么选、为什么这么选、选错了会怎样”这条链路讲透。OBC，也就是On-Board Computer，星载计算机，是整星电子学的“大脑”，负责遥测遥控、姿态控制解算、载荷数据管理、总线调度、故障检测与恢复这些核心任务。它跟地面上的工控机、嵌入式板卡完全不是一个逻辑——地面上你追求的是性能、成本、开发效率，而星上你首先要回答的是：这东西在辐射、真空、极端温差、单粒子效应面前，能不能活下来，活下来之后还能不能算对。适合读这篇的人，包括刚入行的卫星电子工程师、做载荷配套的嵌入式开发者、以及需要给整星选型做决策的系统总体人员。我会把OBC的核心架构、处理器选型、总线接口、存储与冗余设计、抗辐射考量、以及实操中怎么一步步把方案定下来，都掰开讲清楚。

1. 先搞清楚OBC到底在整星里干什么活

选型之前如果不把OBC的职责边界划清楚，后面所有的参数对比都是空中楼阁。我见过太多团队一上来就纠结“用不用FPGA”“主频要多少”，结果连这台计算机要接几路总线、要跑几个控制周期都没定，选出来的东西要么性能过剩、要么根本带不动。

1.1 OBC的核心任务清单

星载计算机的活儿，粗分下来有这么几大类。第一类是遥测遥控（TT&C）数据处理，地面发上来的指令要解析、校验、分发，星上的状态量要采集、打包、下传。第二类是姿态与轨道控制（AOCS）解算，这是实时性要求最高的一块，通常要求控制周期在几十毫秒到几百毫秒量级，涉及陀螺、星敏、磁强计的数据融合，以及动量轮、磁力矩器的指令输出。第三类是载荷数据管理，尤其是遥感类载荷，图像数据量大，OBC往往要负责缓存、压缩、格式化，再通过高速总线送往下传通道。第四类是总线调度与健康管理，整星上各种设备挂在总线上，OBC通常是总线主控，负责轮询、仲裁、超时处理，同时还要做看门狗、故障检测、安全模式切换。

这四类任务对计算资源的需求差异极大。TT&C和健康管理是典型的低速率、高可靠任务，AOCS是硬实时任务，载荷数据管理是高速率、可容忍一定延迟的任务。选型时如果把这些任务全部压在一台OBC上，那对处理器的实时性和吞吐量要求就会非常高；如果拆成主控OBC加载荷处理单元，选型逻辑就完全不同。我个人的经验是，中小卫星尽量把AOCS和TT&C放在同一台高可靠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主要负责TT&C、总线管理、简单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 架构选型对比表

这张表不是让你照着选，而是帮你快速定位。实际选型时，我建议先把任务按实时性和吞吐量画个二维图，落在哪个象限，架构方向就清楚了。

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，用于载荷数据、大容量存储、高速传感器的互联。它的特点是点对点或路由交换、全双工、低延迟、协议简单。相比CAN，SpaceWire更适合大数据量传输，比如相机图像、雷达原始数据。

SpaceWire的选型要点在于接口IP的成熟度和路由配置。很多FPGA厂商提供SpaceWire IP核，但宇航级应用要确认IP是否经过辐射验证。另外SpaceWire的链路初始化、时间码分发、故障恢复机制都需要在OBC软件里实现，这部分工作量不小。

3.3 总线配置的实操建议

我一般建议中小卫星采用CAN为主、SpaceWire为辅的混合架构。控制类设备全部挂CAN，载荷和存储挂SpaceWire，OBC同时具备两种接口。这样既保证了控制的实时性和可靠性，又满足了载荷数据的带宽需求。

如果整星设备数量少、数据量小，可以只用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只有10krad，SEL阈值也不高，用在长寿命任务上就是隐患。另外，系统级加固可以弥补器件级的不足，比如用屏蔽增加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 常见问题速查表

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选型的你。