波音737 MAX Fiasco的5个经验教训

虽然我们将在几个月前收到关于737 MAX崩溃的完整报告，但我们不必等待从这些事件中汲取教训。1908年9月17日，Orville Wright和Lt Thomas Selfridge从Fort Meyer Virginia的Wright Flyer起飞。起飞后不久，赖特飞行员突然停下来，将飞机撞向地面，打伤了赖特并杀死了塞尔弗里奇。当其中一个木质螺旋桨在支撑线上分开并拉动时发生碰撞，这导致后方舵从垂直位置移动到水平位置1。这是导致死亡的第一次飞机失事。快进大约110年：飞机不再是由赖特和早期航空先驱驾驶的简单机械飞机，而是由数百万行软件驱动的高度复杂的电子系统。上个世纪的进步使航空旅行成为最安全的交通方式。

最近新闻头条由两起坠机事件主导，涉及波音公司新型737 MAX飞机在类似情况下六个月内相互撞击。这些灾难的后果可能只是在世界各地的飞机停飞，737 MAX的生产减少以及3月飞机的销量降至零时才开始。波音公司作为安全领导者的声誉受到的损害现在也受到质疑，因为已经开始调查研究中心的系统MCAS是如何开发和认证的。

对导致失去这些飞机的事件顺序及其原因的调查将需要相当长的时间才能完全暴露并由事故调查人员实现。但是，根据目前发布的信息，嵌入式系统公司和开发人员可以查看波音目前正在经历的惨败，并了解并提醒他们可以应用于自己的行业和产品的一些常规课程。让我们来看看这些课程。

人工智能长期以来一直是开发人员从事高性能计算和基于云的系统的工具。人工智能改变了网络监控方式，电子邮件扫描方式，甚至是我们与手机和设备交互的方式。虽然AI和机器学习总是感觉像是一个生活在实时嵌入式系统之外的遥远工具，但机器学习正在基于微控制器的系统中实现，事实上，它已经存在!

第1课 - 不要妥协您的产品以短期储蓄或赚钱

今天的企业和开发商面临着规范性的压力，要求他们尽快增加收入，降低成本并运送产品。口头禅不是品质。这不是安全。它不是用户友好的。口头禅是最大的短期增长，在我看来，只要短期增长最大化，不惜任何代价。现在，我不相信这是波音公司的口头禅，甚至是他们的意图，但考虑到他们似乎承担了客户和股东提供可以与空客A319neo竞争的飞机的压力，我相信我们可以看到他们可能已经开始屈服于这种规范性的压力。

这将我们带到第一课：不要冒险妥协您的产品以节省或赚更多钱。在短期内取得成功非常重要，但除了本季度和下一季度产生的销售额和收入之外，还有更多的业务。即使竞争对手发布竞争产品并且客户施加压力，重要的是要记住长期的叙述，而不是牺牲质量，声誉或使客户的业务处于危险之中。

第2课 - 识别并缓解单点故障

在正在开发的任何嵌入式系统中，了解潜在的故障模式以及这些故障对系统会产生什么影响以及如何减轻它们非常重要。团队有很多方法可以做到这一点，包括执行设计失败和影响分析(DFMEA)，分析设计功能，故障模式及其对客户或用户的影响。完成这样的分析后，我们就可以确定如何减轻故障的影响。

在可能影响用户安全的系统中，通常的做法是避免单点故障，例如传感器故障或单个输入。显然，如果单个输入突然提供垃圾数据，只有上帝知道该系统将如何响应，当你投入墨菲定律时，结果不会是积极的。当我读到MCAS系统依靠单个传感器进行决策时，我真的很吃惊。过去曾经致力于安全关键且强大的嵌入式系统，令人难以置信的是，单个传感器输入的使用将被认为是可接受的，并且在第二个传感器的输入中添加，如果传感器发生故障则会禁用系统似乎没有让事情变得更好2(但这真的取决于工程哲学和文化)。

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

我认为许多工程师可以从惨败中获得的一个有趣的教训是，我们不能假设或依赖我们的用户正确操作我们的设备，特别是如果这些设备是自主运行的话。我并不是说这是贬义的，而只是指出复杂的系统需要更多的时间来分析和排除故障。波音公司似乎认为，如果出现问题，用户就有足够的培训和经验，并且知道现有的程序足以弥补。对或错，作为设计师，我们可能需要使用“降低的期望”并尽我们所能来保护用户免受他自己的伤害。

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

Edsger Dijkstra写道：“程序测试可用于显示错误的存在，但永远不会显示它们的缺失。”我们无法证明系统没有错误，这意味着我们必须假设即使我们经过高度测试和认证的系统有缺陷。这应该改变每个开发人员思考如何编写软件的方式。我们应该开发缺陷策略，而不是试图在个案基础上暴露缺陷，这些缺陷策略可以检测到系统行为不正常或者输入看起来不正常。通过这样做，我们可以尽可能多地测试系统中的缺陷。但是当一个新的领域出现时，一般的缺陷机制​​有望能够检测到某些东西是不对的并采取纠正措施。

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

传感器和系统出现故障这一事实看起来似乎是一个明显的陈述，但我看到很多开发人员编写软件，好像他们的微控制器永远不会锁定，遇到单个事件扰乱或内存损坏。传感器将冻结，处理器将锁定，垃圾进入将产生垃圾。作为开发人员，我们需要假设事情会出错并编写代码来处理这些情况，而不是如果我们总是拥有一个在现场工作的系统，就像在实验室工作台上一样。如果你考虑到它会失败的事实来设计你的系统，那么你最终会得到一个强大的系统，它必须在最终找到失败的方法之前做很多艰苦的工作(如果有的话)。