本文经授权转载自公众号“民用飞机”。文中介绍的民机系统安全性需求的来源、分配和V&V等内容，对不同行业的功能安全从业人员都有一定的借鉴意义。

本文从适航规章 25.1309 入手，介绍了系统安全性需求的捕获过程、层级划分、确认验证方法，对于民用飞机安全性工作具有借鉴意义。

一、引言

民用飞机安全性需求，最初来源于公众利益和适航的要求。

2019 SSJ 空难照片

伴随着多次空难事件的发生，公众从自身利益出发，要求政府对空中飞行活动进行管理，确保航空器的设计、制造和维修能够达到一定的安全性水平。因此适航规章及相关咨询材料规定了飞机能在预期环境中安全飞行的要求，以保护公众利益。

伴随着民用飞机设计技术的发展，其实现的功能得以不断扩展，复杂电子硬件和软件得到广泛应用，飞机航电系统、飞控系统、推进系统、液压系统、电源系统的关系也日益密切。

针对这样一类复杂系统，需要考虑当系统单个或多个功能丧失或异常时，对飞机、机组及乘客造成的安全性影响。

深陷泥潭的 737MAX

此外还需考虑执行不同功能的系统之间的相互影响。据此得出失效状态的发生概率和影响程度之间的约束关系。

即随着失效状态影响程度的加深，其故障发生概率要求越来越小。失效状态影响程度与概率要求的大致关系如下所示。

通常，一个灾难级失效状态的发生概率必须小于 1E-9/FH 量级，危险级失效状态的发生概率必须小于 1E-7/FH 量级，较大影响失效状态的发生概率必须小于 1E-5/FH 量级，较小影响失效状态的发生概率必须小于 1E-3/FH 量级。

这是一个公众、飞机制造商和飞机运营商都能够接受的安全性水平，反映了适航条款 25.1309 的精髓，也建立了整个飞机系统安全性的基础。

二、安全性需求的捕获

在复杂机载系统设计过程中，应尽早完成功能和安全性需求的捕获，以指导系统方案设计。

安全性工作应针对以下方面提出具体的安全性需求：

a) 系统架构方案；

b) 接口系统；

c) 系统安装布置；

d) 软硬件设计。

系统安全性需求主要来源于飞机级、本系统和接口系统的安全性评估过程。

• 首先，应追溯飞机级安全性需求，并分解传递至系统及其子系统；

• 其次，应完成系统级 FHA、PSSA、CCA 等安全性评估过程，产生相应的安全性需求，并分解传递至系统、子系统和设备；

• 再次，为了支持接口系统的安全性设计，需满足接口系统提出的针对本系统的安全性需求，并分解传递至系统、子系统和设备。

所有的安全性需求应纳入 SRD、ICD、STS、PS 等相关需求文件。安全性评估与安全性需求的关系，如下所示。

在安全性需求捕获过程中，应充分识别系统适用的适航条款、咨询通告、问题纪要和公司/行业标准，并将其纳入安全性评估过程。

此外，不应忽视接口系统安全性需求。

• 一方面，本系统需要充分捕获来自接口系统的需求。例如，飞控系统为了支持起落架系统前轮转弯功能，需捕获起落架系统对飞控系统脚蹬位置信号的安全性要求；

• 另一方面，本系统的正常工作还需要接口系统等提供支持，因此应对相关接口系统提出需求，并落实在接口系统的需求文件中。

所有这些安全性需求，可分为以下几类：

a) 系统功能研制保证等级 FDAL；

b) 项目（软/硬件）研制保证等级 IDAL；

c) 系统/设备的可用性/完整性定量指标；

d) 功能/设备独立性要求。

三、安全性需求的层级

安全性需求存在于飞机级、系统/子系统级和设备级。

• 在飞机级，安全性需求通过基于飞机功能（如俯仰控制、地面减速等）的飞机级 FHA 而产生，并通过 PASA 分解至各系统。相应的安全性需求应落实进飞机级需求文件。

• 在系统/子系统层级，安全性需求通过系统 FHA 而产生。系统 FHA 应充分捕获飞机级分配的安全性需求，并通过 PSSA 分解至各设备。相应的安全性需求应落实进系统/子系统级需求文件（SRD，ICD等）。

• 在设备层级，安全性需求来自系统/子系统安全性需求分解过程，并逐层往下分解为软硬件的高、低级别需求。相应的安全性需求应落实进设备级需求文件，以指导软硬件设计。

安全性需求层级架构，如下所示。

此外，安全性需求也可以通过共因分析形成。

四、安全性需求的确认和验证

安全性需求作为系统需求体系的一部分，应按照系统需求确认计划和验证计划中制定的步骤开展确认和验证工作。

当捕获到安全性需求之后，就应对这些需求开展确认，且随设计进展迭代进行。需求确认的目标是保证需求的正确性和完整性，减少出现系统内非预期功能或相关系统间非预期功能的潜在可能。

当系统软/硬件实现之后，就应逐级开展安全性需求的验证。首先是软/硬件层级的验证，然后是设备级验证、子系统/系统级验证和飞机级验证活动。

根据 SAE ARP4754A 提供的 “V模型”，可知需求确认工作主要集中在 “V模型” 的左侧，实施验证工作主要集中在 “V模型” 的右侧。在系统软/硬件实现之前，需完成大部分需求的确认工作，这样可尽量减小由于需求定义不全或错误造成后期设计更改的风险。在系统软/硬件实现之后，可根据系统集成工作的进展，针对需求逐级实施验证活动。

在实际的系统研发过程中，有些设计问题只有到验证阶段才能得到充分地理解和暴露，因此需求的确认工作会贯穿整个研制过程。

4.1 安全性需求的确认

安全性需求的确认方法主要包括：追溯性、分析、相似性、评审和模拟器试验。

a) 追溯性

• 通过检查较低层级需求能否满足已经过确认的较高层级需求，来保证系统需求的完整性；

• 由于部分系统安全性需求来自飞机级 PASA 和 CCA 的评估结果，因此追溯性常常可以用于系统安全性需求的确认。

b) 分析

• 通过开展 FHA、PSSA、CMA、FTA 等安全性评估过程和分析方法，对安全性相关需求进行确认；

• 由于大量的安全性需求（如研制保证等级要求），来自 FHA、PSSA、FTA 等评估结果，因此安全性分析可以直接用于安全性需求确认。

c) 相似性（工程经验）

• 如果已有先研型号的取证经验，且新研型号采用了相似设计，则可通过相似性来对需求进行确认。

d) 工程评审

• 在系统研制过程中，针对需求应进行多次评审和检查。进行工程评审时应选择具有多年工作经验的人员，以提高评审结果的置信度。

e) 试验

• 安全性需求的确认试验主要是FHA定级相关的模拟器试验，以及少量的飞行试验；

• 对于影响等级为I类的失效状态，由于已经考虑了最严苛情况，一般不需要进行确认（除非存在等级降低的可能）；

• 对于影响等级为II类的失效状态，考虑到飞机和机组安全及试飞成本，建议谨慎采用飞行试验的方法；

• 对于功能失效的影响体现在机体结构上的失效状态，由于模拟器无法模拟，因此不建议采用模拟器试验的方法。

总之，系统安全性需求的确认主要采用追溯性、安全性分析、模拟器试验等方法。需求的确认过程贯穿于整个研制过程并持续迭代，不断提高需求的正确性和完整性。

4.2 安全性需求的验证

验证的目的是用来表明每一层级的实现满足了相应层级的安全性需求。验证方法主要包括：检查或评审、分析、试验或演示。

a) 检查或评审

• 包括对安全性过程文件、数模、设备安装的可视化检查，以验证相应需求已得到了满足，通常使用检查单或评审会的形式来进行，最后应生成检查报告或评审记录。

b) 分析

• 通过对系统或设备进行详细的分析，来提供符合性证据。主要包括系统安全性评估和分析（SSA、FTA、FMEA/FMES等），并根据分析结果评估是否满足需求。

c) 试验或演示

• 通常可采用模拟器试验、铁鸟试验等，开展相关故障试验，以表明故障树等安全性分析过程的正确性，提高FTA、FMEA等验证数据的置信度。

总之，安全性需求的验证工作，主要通过 SSA、FTA、FMEA/FMES 等安全性分析方法开展验证。

五、总结

本文结合SAE ARP4754A，介绍了民机系统安全性需求的捕获过程、分解分配、确认验证。

系统安全性需求，是系统架构设计和软硬件设计的关键输入，其重要性不言而喻。

--- END ---