波音为什么在737 Max 8上犯这样低级错误呢?

Test Ninja 软件质量报道 2019-03-17

一周前,埃塞俄比亚航空一架服役仅 4 个月的波音 737 MAX 8 客机坠毁,机上 149 名乘客和 8 名机组成员全部遇难。这是半年以来坠毁的第二架波音 737 MAX 8飞机。

波音 737 MAX 诞生于波音与空客两家巨头的竞争之中。2010 年,空客开发了A320 neo新机型,并宣称它的新发动机能够提高燃油效率和运营效率。迫于竞争压力,波音 737 飞机不得不更新换代,2011 年 8 月 波音公司董事会批准了 737 MAX 项目。波音宣称,搭载了新发动机的 737 MAX 将会比空客 A320 省油 16%、比 A320 neo 省油 4%,而且航程也会超越 A320 neo。的确,737 MAX优点不少,如官方网站宣称,它也成为最畅销的机型,总订单超过5000架。

成也萧何,败也萧何。

波音737 Max 8之前宣称的优势集中在新发动机上,但空难的导火索可能也来源于新发动机。由于737MAX的新发动机明显大一号,不得不把安装的位置往前移一些位置。因为发动机的位置靠前了,抬头力矩变得很大,使得飞机在飞行时头部容易“翘起来”,而机头翘会容易导致飞机失速坠毁。这很不安全,这时有两种解决方案:

  1. 重新设计一下机身,保证飞机的安全;

  2. 用打补丁的方式,弥补发动机带来的问题。


第1个选项自然极大增加成本,通过适航标准的历程也会很长,所以波音选择了第二种方式,专门设计了一套自动预防失速系统(automated stall-prevention system),其中当传感器传来的数据显示飞机进入失速姿态(stall)时, MCAS程序会启动并专心干一件事儿——自动压低机头,让飞机俯冲来提升速度。

但是,如果机头降低的幅度非常大时,导致机头无法抽回而坠机。当飞行员发现飞机在俯冲不妙时,会操作飞机拉起机头,而5秒钟后MCAS程序又会把机头按下去、让飞机俯冲;飞行员只好再将机头拉起来,MCAS按下去,飞行员拉起来,MCAS按下去......如此PK下去,最终的结果可想而知。

的确,737 Max 8也有彻底关闭MCAS程序的方法,但那个设置隐藏比较深,需要在触摸屏上进行相对复杂的操作才能完成,这样自然导致有些飞行员可能不熟悉关闭的方法。当飞行员处在紧张的时候,那样的操作估计更不容易完成。虽然驾驶舱有两名飞行员,因为MCAS程序是在飞行员手动操作飞行方式下起作用,而不是在自动巡航时发挥作用。在手动操作飞行方式下,飞行员认为自己完全操控飞机,出现上述情况,可能认为是机械故障的问题,而忽视(甚至不知道)那是MCAS程序在暗暗操作。

看完这个故事,大家也许看出一些问题,例如,飞行员为什么不能第一时间想到MCAS程序在起作用?难道对飞行员的培训不足、还是飞机飞行手册没有突出标出这样的功能特性?其次,下列不合理的设计,在评审时没有被发现吗?

  • 起飞的时候速度偏低、仰头飞行,而且处在手动操作方式,属于正常,这时启动MCAS程序应该很不合适,不是吗?(两起空难都是在飞机起飞后不久发生的)

  • 一旦飞行员采取强制手段拉升飞机,MCAS程序是不是应该自动失效?如同汽车处在自动巡航控制(Cruise Control)模式时,一旦司机踩下刹车,自动巡航控制模式就自动取消。

  • 飞机从抬头被MCAS程序按下时,达到水平飞行而没有到俯冲时为什么MCAS程序不会根据其它传感器的数据而自动失去作用、把控制权交回给飞行员呢?

除此之外,据说737 Max 8只根据主传感器的数据就判断“有失速危险”,为什么不和另外两个备份的传感器进行数据比较、相互印证?如果两个或三个传感器数据都显示飞机失速,才采取行动,是不是更安全?如果仅仅根据主传感器的数据就作出判断,是不是有较大风险?因为单个传感器自身就可能出问题而传递错误数据。两个传感器或三个两个传感器同时出错的可能性要小多了,特别是出错的数据都一样。

根据关键软件开发与审定——DO-178C标准要求,关键软件的验证更为重要,这就是我经常提到的公式:

Verify = Review + Analysis +Test 

test虽是重要的验证活动,但对航空航天的实验很难做,要模仿各种真实场景很困难,而且代价很大。这时评审(review)和分析就显得特别重要DO-178C标准规定要做充分的评审和分析,例如,关键代码的每一行要被review三遍,详细要求见下列照片显示:

(来源:Leanna Rierson,崔晓峰译,关键软件开发与审定——DO-178C标准实践指南

在这样的严格评审下,上述问题一般都能发现的。为什么没有发现呢?不能说,Boeing公司不成熟、不优秀,很难相信问题是出自波音公司。但根据某些信息来源,将这部分软件分包给印度的团队开发,设计和代码可能是由不同的团队完成,这样沟通、衔接就容易存在某些问题,代码的评审和设计的评审可能由不同的、相差很远的两个地方(美国和印度)的团队进行的,中间的差异没有被发现。类似当年火星探测器坠毁事件有相似之处,没有完成端到端的验证评审)、设计和代码实现的一致性严格检查。正所谓,智者千虑必有一失,更何况是上述情况。这只是猜测,真正原因还要等波音自己揭晓,不过,也有朋友说,真正的细节原因可能永远不会公布,就和法航447的真实原因到今天都是未解之谜。

除了评审,分析(analysis)也很重要,DO-178C要求做如下分析:

  • 最坏情况执行时间分析

  • 内存余量分析

  • 链接和内存映像分析

  • 加载分析

  • 中断分析

  • 数学分析

  • 错误和警告分析

  • 分区分析

也有文章谈得没有做好FMEA(Failure Mode and Effect Analysis,失效模式和效果分析)分析但从目前判断看,设计缺陷是明显的如果不是设计缺陷,就是代码没有很好实现设计原意和要求。如果在评审设计、代码时,能很好地回答上面提的问题,可能两次空难就不会发生。如果真是这样的评审问题,那这个代价也就太大了。

文章已于修改

    发送中

    本站仅按申请收录文章,版权归原作者所有
    如若侵权,请联系本站删除
    觉得不错,分享给更多人看到