狮航737MAX事故给我国软件验证的启示

10月29日印尼狮航波音737 MAX 8/9在雅加达坠机，造成189人丧生的事故近期传遍网络。根据FAA的紧急适航指令Emergency Airworthiness Directive得知：

http://rgl.faa.gov/Regulatory_and_Guidance_Library/rgad.nsf/0/83ec7f95f3e5bfbd8625833e0070a070/$FILE/2018-23-51_Emergency.pdf

这是由于高迎角传感器（AOA）将错误的数据（erroneously input）输入给了飞行控制系统，从而引起错误的机头降低指令，使得驾驶员难以判断和控制飞机状态造成的。

由于信息非常有限，很难说是设计缺陷，还是验证不足。我从网上还发现了一篇文章写得很好，是一位机长写的，大家可以参考。

http://roy737.blog.caixin.com/archives/192154

这个事故对我们国内机载软件的启示

对于飞行控制软件来说，如果存在面临这样错误数据输入的可能性，就要进行充分的验证。在DO 178C的6.4.4.2软件健壮性测试中，第c项要求包括:

“the possible failure modes of the incoming data should be determined, especially complex, digital data strings from an external system”。

这里面我们可以看出，对于机载软件来说，来自外部的复杂输入，应该分析验证输入的所有可能的失效模式，才能有效验证软件的健壮性和系统的安全性。

无独有偶，在轨道功能安全标准EN 50126中，也对轨道复杂系统的失效机理进行了阐述。

文中可以看出，来自外部的“Disturbance Threat”输入是造成不安全不可靠的原因。这与DO 178C的要求如出一辙。

软件失效风险分析做什么

如图1所示，软件失效风险分析非常直观:

就是要把软件来自外部的各种failure modes分析清楚，列出所有可能的输入情况，特别是各种Disturbance Threat，要求软件对这样的输入做出设计响应，然后依据这些输入设计测试用例进行验证。

在型号软件失效风险报告中，最集中的问题就是不知道如何开展一个失效风险分析的步骤。现在很简单:按照上图，沿着这些外部系统，一个一个过，把每个系统的每个输入的每个失效模式都分析一遍就行了。

如果工作量太大，那就需要给出取舍的理由和原因，这是整个分析工作的核心所在，能把这个取舍标准、分析策略说清楚的，分析报告做的一定很优秀。

每个系统我知道，每个输入我也知道，每个失效模式我怎么知道？如果存在这样的问题，请看文尾硬广告。

对软件测试的启示

软件测试的依据是需求，不光包括功能需求，还包括这些以failure modes为代表的隐含异常处理需求。

研发组织在资源充分时，可能会通过失效风险分析、健壮性分析这样的工作将这些异常需求识别出来；但有的时候，这些异常需求，会始终保持隐含状态直到交付使用。这就对测试验证造成了很大的困扰，需要软件测试人员具备将其分析识别出的能力，等于是在给研发阶段的设计遗漏补课。

难点

无论是设计阶段的失效风险分析，还是测试阶段的健壮性测试，都需要“尽可能多”地识别来自外部的失效模式failure modes，这是一个“大开脑洞”的过程，到底有多少failure modes往往是具体操作中最容易让人头疼的事情，没人能证明“绝对够了”，而只能证明自己“已经尽力了”。

好在适航等功能安全的理念不是让我们去证明自己绝对无遗漏，而是至少要证明能够规避已经出现过的failure modes。对于外部可能的数据异常、时序异常、逻辑异常、状态异常、故障异常等等复杂的情况，我们需要建立有效的手段去认识，分析，规避。才能表明自己采用了可信的方法去提高软件的功能安全。

硬广告：综上所述，在这里仍然推荐我们的软件失效模式数据库产品，能够支撑码农、测农们，有效控制嵌入式软件失效风险，提高软件健壮性，增强系统功能安全！欢迎从业者们关注咨询！