从波音737 MAX惨败中学习的5个教训

1908年9月17日,奥维尔·赖特(Orville Wright)和中尉托马斯·塞尔弗里奇(Lt Thomas Selfridge)从维吉尼亚堡迈尔(Fort Meyer Virginia)乘坐怀特传单起飞。起飞后不久,莱特传单突然俯冲下来,将飞机驶入地面,炸伤了莱特,并杀死了塞尔弗里奇。当其中一架木制螺旋桨劈开并拉动支撑线而导致后舵从垂直位置移动到水平位置时,发生了坠机事故1。这是导致死亡的第一次飞机失事。快进了大约110年,飞机已不再是莱特人和早期航空先驱飞行的简单机械飞机,而是由数百万行软件驱动的高度复杂的电子系统。上个世纪的进步使空中旅行成为最安全的运输方式。

最近,新闻头条被两次坠机事件占据主导,这两次事故涉及波音公司的新型737 MAX飞机在相似的情况下彼此间隔六个月。这些灾难的后果可能只有在世界各地的飞机停飞,737 MAX的产量下降以及3月份飞机销量下降到零时才开始。由于已经开始调查作为调查中心的系统MCAS是如何开发和认证的,因此波音作为安全主管的声誉受到的损害现在也受到质疑。

对导致这些飞机损失和原因的事件顺序进行调查将需要相当长的时间才能完全暴露出来,并且要由事故调查员予以了解;但是,利用当前已发布的信息,嵌入式系统公司和开发人员可以查看波音公司目前正在经历的惨败,并学习并提醒他们可以应用于其自己的行业和产品的几条一般课程。让’检查这些课程。

第一课–不要妥协您的产品以节省或短期赚钱

如今,企业和开发人员面临规范压力,要求其增加收入,降低成本并尽快交付产品。口头禅不是质量。这不是安全。它不是用户友好的。口头禅是最大的短期增长,我认为,只要使短期增长最大化,便不惜一切代价。现在,我不相信这是波音的口头禅,甚至不希望他们这样做,但鉴于他们似乎受到客户和股东的压力,要求他们交付可以与空客A319neo竞争的飞机,我确实相信我们可以看到他们可能已经开始屈服于这种规范压力。

这使我们进入了第一堂课,不要冒险为了节省或赚钱而损害您的产品。短期内取得成功很重要,但是每一项业务除了在本季度和下一个季度产生多少销售额和收入外,还有更多的事情要做。即使在竞争中发布了具有竞争力的产品并且给客户施加了压力,也必须牢记长期的叙事方式,不要牺牲质量,声誉或危及客户的业务。

第二课–识别并缓解单点故障

在正在开发的任何嵌入式系统中,重要的是要了解系统的潜在故障模式,以及这些故障将对系统产生什么影响以及如何减轻这些故障。团队可以通过多种方式进行此操作,包括执行设计失败&效果分析(DFMEA),用于分析设计功能,故障模式及其对客户或用户的影响。一旦完成了这样的分析,我们便可以确定如何减轻故障的影响。

在可能会影响用户安全的系统中,通常的做法是避免出现单点故障,例如传感器故障或单次输入。显然,如果单个输入突然提供了垃圾数据,只有上帝知道该系统将如何响应,并且当您遵循墨菲定律时,结果将不会是肯定的。当我读到MCAS系统依靠单个传感器进行决策时,我确实感到吃惊。过去在安全性和鲁棒性强的嵌入式系统上工作过,令我感到困惑的是,使用单个传感器输入被认为是可以接受的,并添加了第二个传感器的输入,如果传感器出现故障,第二个传感器的输入将被禁用,这是不可接受的。似乎使事情变得更好2 (但这实际上取决于工程哲学和文化)。

第3课–不要以为您的用户可以处理它

我认为许多工程师可以从惨败中吸取一个有趣的教训,那就是我们不能假设或依赖我们的用户来正确操作我们的设备,特别是如果这些设备旨在自动操作。我并不是说要贬义,而是要指出复杂的系统需要更多的时间进行分析和故障排除。波音公司似乎认为,如果出现问题,那么用户将有足够的培训,经验和充分了解现有程序以进行补偿。对与错,作为设计师,我们可能需要使用“降低的期望”,并尽一切可能保护用户免受自己的伤害。

第4课–经过高度测试和认证的系统存在缺陷

Edsger Dijkstra写道:“程序测试可用于显示错误的存在,而从不显示错误的存在”。我们无法证明系统没有错误,这意味着我们必须假设,即使我们经过高度测试和认证的系统也存在缺陷。这将改变每个开发人员对软件编写方式的思考方式。与其尝试逐案地揭示缺陷,我们应该开发缺陷策略,以检测系统是否行为异常或输入中的某些东西看起来不正常。这样,我们可以从系统中测试尽可能多的缺陷,但是当现场出现新的缺陷时,一种通用的缺陷机制​​有望能够检测出某些问题并采取纠正措施。

第5课–传感器和系统出现故障

传感器和系统故障的事实似乎是显而易见的说法,但是我看到相当多的开发人员在编写软件时好像他们的微控制器永远不会锁定,遇到单个事件崩溃或内存损坏。传感器将冻结,处理器将被锁定,垃圾进入将产生垃圾。作为开发人员,我们需要假设会出错,并编写代码来处理这些情况,而不是假设我们始终拥有一个像在实验室工作台上那样都能在现场运行良好的系统。如果您在设计系统时会考虑它会发生故障的事实,那么最终您将获得一个健壮的系统,该系统必须付出大量的努力才能最终找到故障的解决方法(如果有的话)。

结论

尽管我们还需要几个月的时间才能获得关于发生和导致737 MAX坠毁的原因以及国会关于飞机如何通过认证和开发的听证会结果的完整报告,但我们不必等待这些结果从中吸取教训。他们。我们检查了一些重要的提醒,所有企业和开发人员都需要仔细考虑并确保他们不会在自己的系统上走类似的道路。您现在应该问的问题是,您目前正在采取什么妥协措施?您今天打算采取什么行动以确保明天不会造成自己的惨败?

参考文献

  1. //www.wired.com/2010/09/0917selfridge-first-us-air-fatality/
  2. //www.seattletimes.com/business/boeing-aerospace/a-lack-of-redundancies-on-737-max-system-has-baffled-even-those-who-worked-on-the-jet/

2 thoughts 上 “从波音737 MAX惨败中学习的5个教训”

  1. 作为航空航天嵌入式系统的设计者,我很难想象这样的系统将由受人尊敬的长期制造商进行设计,测试和生产。从独立的认证和安全人员到内部系统设计和系统验证人员,这里的情况和力量正在造成多层次的系统故障。很难理解使波音处于解释这一惨败状态的一系列事件。

发表评论

您的电子邮件地址不会被公开。 必需的地方已做标记 *

该网站使用Akismet减少垃圾邮件。 了解如何处理您的评论数据.