企业官网建设流程全解析

1. 星载计算机选型的底层逻辑：为什么不能直接照搬地面方案

很多人第一次接触星载计算机（OBC，On-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的处理器核只是辅助角色，算力不足以跑复杂任务。

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 = 2'b00; localparam READ = 2'b01; localparam WRITE = 2'b10; localparam DONE = 2'b11; reg [1:0] state; reg [23:0] cnt; always @(posedge clk or negedge rst_n) begin if (!rst_n) begin state <= IDLE; addr <= 24'd0; wr_en <= 1'b0; end else begin case (state) IDLE: begin if (refresh_trigger) begin state <= READ; addr <= 24'd0; end end READ: begin data <= config_data; // 从外部存储器读取 state <= WRITE; end WRITE: begin wr_en <= 1'b1; state <= DONE; end DONE: begin wr_en <= 1'b0; addr <= addr + 1; if (addr == 24'hFFFFFF) 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最高1Mbps，CAN FD可以到5Mbps以上，但星上长距离传输时速率要降额。如果星内通信距离超过几米，1Mbps可能都跑不稳。这时候就要考虑SpaceWire或者LVDS。

3.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的成本高、功耗大、体积大，对于非关键任务，冷备份或热备份就够了。

冷备份适合故障容忍时间长的任务。比如数据存储计算机，挂了之后几分钟内恢复就行，冷备份完全够用。冷备份的设计要点是故障检测和切换可靠性。故障检测可以用看门狗加心跳信号，切换可以用继电器或模拟开关。继电器的抗辐射性能要查，有些继电器在辐射下触点会粘连。

热备份适合故障容忍时间短的任务。比如姿控计算机，切换时间要控制在毫秒级。热备份的实现可以是双机热备（两个模块同时运行，一个主一个从）或双机互备（两个模块互相监控）。双机热备的难点是状态同步，主从之间的数据要实时同步，否则切换后状态不一致。

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到几百MB），RTOS内核加驱动加应用，要留至少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 调试阶段的常见故障与排查

排查故障时，先定位是硬件还是软件问题。硬件问题看电源、时钟、信号完整性；软件问题看日志、看内存、看任务调度。我一般用二分法：把系统分成两半，先排除一半，再排除另一半，逐步缩小范围。

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 方案对比与决策矩阵

把候选方案列出来，用决策矩阵打分。维度包括：可靠性、性能、功耗、成本、开发难度、供货周期。每个维度给权重，每个方案打分，算加权总分。

决策矩阵不是万能的，但能帮你理清思路。加权总分高的不一定选，还要看关键约束。比如供货周期如果是一票否决项，那供货周期短的方案优先。

8.3 原型验证与迭代优化

方案定了之后，先做原型验证。原型不用做全功能，把关键路径打通就行。比如处理器加存储器加总线接口，跑一个简单的任务，验证基本功能。

原型验证通过后，做工程样机。工程样机要覆盖所有接口和所有工作模式，做环境试验（温度、振动、辐照）。环境试验中发现问题，迭代优化设计。

迭代优化要有优先级。可靠性问题优先解决，性能问题其次，成本问题最后。我见过一个项目，为了降成本换了便宜的连接器，结果振动试验中连接器松动，导致整个OBC失效。可靠性问题不能妥协。

最后分享一个小技巧：选型时多和用过的人聊。数据手册上的指标是理想条件下的，实际使用中的坑只有用过的人知道。我一般会找同轨道、同任务类型的项目团队聊，问他们用了什么方案、遇到了什么问题、怎么解决的。这些信息比数据手册值钱得多。