航天FPGA软件测试中的风险分析：评审桌上最难过的关

引言：“风险分析”四个字，到底在分析什么

你经历过这样的评审会吗？项目耗时三个月，FPGA的设计、编码、仿真样样齐全，测试大纲写得工工整整。专家翻了翻文档，突然停下来，抬头问你一句：“你们的风险分析呢？我怎么没看到？”

然后整个会议室安静了。

有人急忙翻出一份几页的风险分析报告，列举了几条技术难点和应对措施。专家扫了一眼说：“你这是产品立项阶段的风险评估吧？FPGA软件的测试风险分析不是这样做的。”

好一点的，评审推倒重来；差一点的，直接被叫停。风险分析这个在很多项目里被看作“锦上添花”的东西，在航天FPGA领域，是一条硬杠杠。作为唯一一份介于FPGA和软件之间的文档——FPGA项目比传统软件多了一份《可编程逻辑器件软件可行性和风险分析报告》，但传统的软件风险管理文档反而可以酌情裁剪。

一、风险分析到底是什么

先给一个基本定义：航天FPGA软件测试中的风险分析，是一套系统化识别、评估和控制可能影响FPGA最终“在轨服役”状态的因素的方法。它回答的不是“程序里有没有bug”这种微观问题，而是“在太空这个舞台上，这台设备可能因为什么原因、以什么概率、导致什么后果的失效”。

最精辟的理解方式是一句话：风险分析就是把“万一出事”“是哪些事”“有多大概率”“后果多严重”“我们能做什么”这五个问题，变成一份可追溯、可验证、可审查的证据链。

在载人航天实际工程中，风险分析与控制对策制定被切分在三个关键节点：初样阶段初期、初样转正样、执行飞行任务前。初样阶段初期的分析覆盖飞行任务要求、软件产品成熟度及已有的技术和管理能力，进行全生命周期内外部风险识别；初样转正样时做风险再识别、再分析，针对迭代过程中新增的完善性需求做综合分析；到了飞行任务前，重点看技术难度高、飞行环境作用复杂、地面验证有局限性的三类风险。换句话说，风险分析不是一次性的作业，而是贯穿全周期的生命线。

二、测试中的风险分析要包含哪些内容

一份规范的FPGA软件测试风险分析报告，至少要包含以下四个层次。

第一层：风险识别。 把FPGA软件从“地面测试环境”到“在轨服役环境”切换过程中可能遭遇的所有故障模式、触发条件及触发机制列出来。具体而言，可以从功能故障、环境参数扰动、硬件老化损耗、单粒子效应、接口瓶颈、工具链异常、软件状态迁移异常等维度展开。尤其是FPGA与软件的差异——FPGA使用硬件描述语言（HDL），包含组合逻辑、时序逻辑、时钟树及各类IP核，风险分析的对象不仅有代码，还有布局布线后的物理实现。

第二层：风险评估。 使用风险评价指数法（RAC法）。将风险可能性分为5个等级（从“极不可能”到“频繁发生”），后果严重性分为4个等级（从“轻微”到“灾难”），形成5×4的风险评估矩阵。风险指数R = 可能性等级 × 严重性等级：

• 最大风险：R ≥ 20，不可接受；
• 高风险：12 ≤ R < 20，必须积极管理；
• 低风险：4 ≤ R < 12，经评审后可接受；
• 最小风险：R < 4，不经评审即可接受。

在航天工程实战中，风险识别通常在初样阶段初期就要完成覆盖需求、接口、时序三个维度的识别；初样转正样再进行一轮再识别。

第三层：风险排序与控制措施。 按R值高低排定优先级，对每个识别出的风险，提出三类控制措施：一是规避——修改设计从根本上消除风险；二是减缓——接受风险存在但不接受其后果，通过冗余设计、时序约束、看门狗等手段降低发生概率或严重程度；三是转移——通过外包测试来降低内部负担。每一个控制措施都必须对应到具体的设计或测试环节，并且形成闭环验证。

第四层：遗留风险与切断准则。 一个成熟的团队会把“做不到彻底规避或完全减缓”的风险单独拉出来，命为“遗留风险”。然后回答两个问题：这些遗留风险在什么条件下可以接受？到了哪个测试节点可以宣告“风险已被管理到安全程度”？

三、支撑标准有哪些

FPGA软件测试中的风险分析，在标准和规范中是有明确出处的。

（1）GJB 9433-2018《军用可编程逻辑器件软件测试要求》。 这是军用PLD软件测试的权威标准，建立了覆盖全生命周期的测试体系。标准首次明确定义了三种工况测试要求——典型工况、最大工况、最小工况——并创新性提出时序-功耗联合分析方法。从风险分析角度看，这三种工况覆盖了FPGA在太空温度波动和供电边界条件下的运行闭环，正是最常见的风险边界。

（2）ECSS-Q-ST-30-02C《Failure modes, effects (and criticality) analysis (FMEA/FMECA)》。 欧空局的太空产品保证标准，定义了FMEA/FMECA的实施原则与要求。对于复杂集成电路（包括ASIC和FPGA），采用功能分析方法。硬件失效引发的软件响应由硬件-软件交互分析（HSIA）解决，人为过失在流程FMECA中处理。

（3）ECSS-Q-ST-60-02C（已被ECSS-Q-ST-60-03C和ECSS-E-ST-20-40C取代）。 涵盖从起始到器件验证释放的全过程要求。标准特别强调“适当地规划和支持风险管理”是确保每一阶段成果固化、减少迭代回退的必要手段。

（4）GJB 9001C-2017质量管理体系。 强化了“基于风险的思维”，要求必须实施风险评估，涵盖经营、合同、生产、设计、服务等各方面。

四、实际操作怎么做：FMEA、FTA与运行剖面

风险分析不是凭空拍脑袋，在航天FPGA工程中，主要的实操方法有三种。

4.1 FMEA（故障模式及影响分析）

这是自下而上的归纳分析法。从每一级功能单元开始，问自己：这个单元可能以哪些方式“坏掉”？一旦坏了，上层模块会有什么反应？最终对整个系统造成什么后果？

在FPGA的风险分析中，FMEA适用于资源内部模块——比如SPI接口控制器可能因为SEU击穿寄存器导致片选误激发；时钟管理模块可能因PLL失锁导致整个域失步。

关键动作是三步：识别故障模式（Mode）→ 分析故障影响（Effects）→ 评定故障关键性（Criticality）。FPGA的FMEA同硬件与软件共同分析，采用功能分析方法，硬件失效引发的软件响应由HSIA单独处理。ECSS-Q-ST-30-02C明确规定，风险较高的区域应有针对性地重点分析。

4.2 FTA（故障树分析）

FTA是自上而下的演绎分析。从一个顶层的系统失效事件开始，逐层向下深挖，构建一棵“故障树”——一个故障现象可能是多个底层事件同时发生的“与门”结果，也可能是“或门”由任何一个触发导致的。

一个典型的FTA简化结构（文本表格形式）：

基于FTA的反向复合生成技术，能够为FPGA软件安全测试的激励随机生成提供依据。FTA与FMEA组合使用，已成为FPGA软件安全性分析的成熟方法。

4.3 运行剖面分析法

这是一条专门为航天FPGA定制的法则。传统软件风险分析方法在FPGA上并不直接适用——这恰恰是新手最容易踩的坑。由于FPGA是硬件化平台，其风险分析与常规软件存在根本性差异。

航天型号团队提出的解决方案是：在软件剖面分析方法的基础上，提炼出专门适用于航天型号FPGA的剖面运行方法。运行剖面的核心关注点：FPGA在同一工况或工作模式下持续运行的整体功能性、对故障和扰动的反应能力、与环境交联时各接口的协同性能。通过仿真工具对各种故障进行模拟并自动采集输出，就能获得失效率等度量数据。

4.4 FPGA风险分析的独特要素：软硬协同与硬错误

FPGA风险分析有三个独特的关注点：

硬错误向量：与纯软件的错误不同，FPGA可能因为硬件层面受冲击导致硬失效，比如电源对地短路、闩锁效应（SEL）、配置存储器物理破坏。风险分析必须识别这些模式。

硬件-软件交互分析：由于FPGA承载着大量软硬协同功能，硬件故障可能导致软件层面做出错误决策，反之亦然。这是一个两个方向的风险传播路径，必须用HSIA覆盖。

辐射软错误与配置存储位翻转：SRAM型FPGA的配置比特流在轨翻转风险，按照ECSS标准体系，要通过SEE测试、失效率计算等方法专门评估。

五、评审中为什么容易被质疑

从实际评审经验来看，专家对风险分析的质疑，集中在下面五个方面。

质疑一：“你的风险识别是片面的，怎么证明你的故障模式枚举完整？” ——这是因为很多报告的故障模式只关注功能逻辑，而把时序、功耗、接口物理层、单粒子SEU等重要维度漏掉了。评审的潜台词是：“你敢说，你在轨遇到的风险，都写在文档里了？”

质疑二：“你的评估等级没有客观依据，尤其是发生概率的取值缺乏量化支撑。” ——有的报告直接给分给得很“随意”，没有参考历史数据、元器件寿命曲线或失效率指标，也没有引用环境剖面标准。

质疑三：“你辨识出风险了，但为什么没有三种工况的全覆盖？” ——很多团队只对FPGA的典型工况做测试，而GJB 9433-2018要求的是对关键配置项实施三工况×三批次的充分测试，并且结合门级仿真与静态时序分析进行协同验证。

质疑四：“FPGA在设计上是否可能存在共因故障或冗余逻辑共性缺陷？” ——“冗余”本身是一套对抗故障的方法，但实现冗余的那部分逻辑会不会在同一个芯片内被同一颗高能粒子同时摧毁？评审专家一旦意识到TMR模块间缺乏物理隔离或逻辑多样性，会马上触发红牌。ECSS体系中，共因故障分析是冗余设计的必要项。

质疑五：“你没有结合运行剖面，只用了‘举例法’，而不回答整个任务期间FPGA的动态运行特征。” ——举例法识别出来的风险是“例子”，不代表全貌。专家看到这份报告，内心一定在计算：你们整个任务生命周期——发射、在轨日常、应急模式、安全模式——这个FPGA所有状态的覆蓋，你们分析到了吗？

六、典型问题和学习路径

6.1 典型问题

忽略软硬件交互分析：FPGA的许多故障模式在被评估时只停留在硬件层面，而忘记问一句“这个硬件故障会让嵌入式处理器误判吗？会让TSI误动作吗？”答案在很多评测中是被漏掉的。HSIA恰好是用来覆盖硬件失效引发软件响应的唯一分析工具。

风险分析后没有闭环：报告洋洋洒洒好几十页，识别出几十个风险，但没见哪个风险被“消灭”，也没有哪个设计或测试用例是直接为消灭某个中高风险而新增的。评审的定论很简单：这是“纸上谈兵”。

对初学和专业提升者，建议从以下五个方向逐步铺开学习：

• 入门训练：从ATE/QEM/SIM等工具入门，了解故障仿真和并行测试方法。
• 进阶1：掌握GJB 9433-2018中三工况、时序-功耗联合分析的实施方法。
• 进阶2：学习FMEA（自下而上）+ FTA（自上而下）的故障枚举及分析技术，尤其是FPGA侧的多类故障模式。
• 进阶3：掌握HSIA方法——分析硬件系统与FPGA间所有接口，建立故障模式如何在硬件-软件-接口-环境之间传递的交互模型。
• 进阶4：学会利用MBSE工具或形式化方法做早期可靠性和安全性评估，在航天器等安全关键应用中将分析阶段前移，消除后期隐患。

七、结语

航天FPGA的软件风险分析，是一个从底层晶体管到顶层飞行任务，从地面测试台到GEO轨道深空之间，沿着故障树和功能模型一点一点丈量出来的过程。在评审会上，会发问的专家问的往往不是“你们的程序正确吗？”，而是“你知道你们最大的威胁在哪里，而且证明你们做了有意义的防守了吗？ ”

这就是风险分析这门“看不见的学科”在航天工程里的意义。