ACM通信
你确定你的软件不会杀死任何人吗?
图片来源:Andrij Borys Associates, Shutterstock
从我所看到的、听到的和读到的，关于软件和安全的困惑和错误信息比比皆是。我在这个领域已经工作了近40年，大约从计算机开始被引入到安全关键系统的控制时开始。我想分享我所学到的。宣扬了太多不正确的信念，阻碍了进步，在某些情况下还不必要地付出了生命的代价。本专栏阐明了这一主题，因此我们提出的解决方案更有可能对安全性产生重大影响。
除了少数例外，直到大约1980年，软件才被用于直接控制安全关键系统，尽管它被用于为复杂系统提供计算能力，如航天器。直接控制非常有限，但现在这种犹豫几乎完全消失了，软件被用来控制大多数系统，包括可能涉及潜在的巨大甚至灾难性损失的物理系统。
最初，“嵌入式软件”被用来表示软件的这些新的控制角色，但最近术语“信息物理系统”开始流行起来。的数字这里展示了一个标准的信息物理控制回路。请注意，由于某种原因，信息物理系统通常忘记了控制可以，而且经常是由人类提供的。在一个稍微现实一点的模型中(但比这里需要的更复杂)，会有两个控制器，其中一个人控制器向一个计算机控制器提供控制信号。为了超越没有人类控制者的不寻常情况，我们实际上应该谈谈“网络-人-物理”系统。例如，即使是所谓的“无人驾驶”空中交通工具，通常也有一名地面操作员。的附录G提供了一个更真实和完整的模型STPA手册。4
数字一个网络-人-物理控制回路。
如在数字在这里，一个控制器(或多个控制器，可能是人工的、自动化的或两者兼有)将被控制过程的当前状态与控制目标进行比较，并向执行器发送控制信号，执行器可能是自动的或人工的。执行器将控制信号转换为被控制过程上的物理动作。传感器向控制器提供被控过程状态的反馈，使其能够确定被控系统的状态，并决定是否需要进一步的控制信号。执行器和传感器可以是软件、硬件、物理设备或人。
为了决定提供什么控制动作来满足其目标(需求)，控制器必须拥有受控过程当前状态的模型(当控制器是人类时，通常称为心智模型)。由不安全的控制动作引起的事故最常见的原因是受控过程的模型不正确:当飞机失速时，飞行员认为飞机没有失速，没有发出必要的控制动作以逃离失速;驾驶员没有看到行人，没有及时刹车以防止碰撞;武器控制员认为友军是敌人，并发起友军交火。飞行员、驾驶员和武器控制人员可以是人，也可以是计算机控制的，或者两者的结合。
涉及计算机(和人)的事故通常发生在它们对控制器当前状态的模型与被控过程的实际状态不匹配的情况下;控制器发出一个控制动作，该动作适用于不同的状态，但不是当前存在的状态。例如，当飞机没有失速时，软件控制员认为飞机处于失速状态，并发出一个控制动作以逃离不存在的失速，但却无意中将飞机置于危险状态。
从这个基础开始，让我们考虑一些关于软件和安全的最常见的误解。
误解1:软件本身可能是不安全的
软件不会着火或爆炸;这是一种抽象。只有物理实体才能对生命和财产造成损害:通常需要物理能量才能造成物理伤害。在数字在这一列中，软件向物理进程发送控制信号，这可能会产生物理影响。例如，核电站可能释放辐射，化工厂可能释放毒素，武器系统可能爆炸或无意中瞄准一个友好的目标。一个旧的事故模型将其描述为不受控制的能量。软件不释放能量;它只是释放一些可以用来发送控制信号的比特。
为了避免术语“软件安全”产生的误解，安全工程师有时会说“软件系统安全”，以表示软件行为对危险过程的贡献。另一个概念是说软件的贡献系统安全。不管怎样，如果孤立地考虑软件，而不包括被控制的物理过程，就不可能保证软件所控制的系统的安全性。
阿丽亚娜4号惯性参考系统软件在发射装置中非常安全。然而，当在阿丽亚娜5号重复使用时，它导致了爆炸和一颗卫星的损失。许多事故涉及重用的软件。3.不是软件不安全，而是软件控制的整个系统不安全。
误解2:可靠的系统是安全的;也就是说，可靠性和安全性本质上是一回事。因此，可靠性评估可以作为安全的代理
可靠性和安全性是不同的系统属性，有时甚至相互冲突。在软件对事故的贡献方面也是如此。系统组件(包括软件)可以100%可靠地运行，但仍然可能发生事故，通常是由于系统组件之间的不安全交互。此外，系统边界之外的更大环境(包括社会政策和决策)也很重要。举一个简单的现实世界的例子，设想你走到一个大的荒芜区域的中央，拿着枪，远离自己，然后开枪。如果附近没有任何人或任何东西，这把枪可以被认为是可靠和安全的。但是，考虑一下在拥挤的商场里做同样的事情。枪没有变，枪的可靠性没有变，动作(扣动扳机)也没有变。但安全性肯定有问题。
附带的侧栏突出了数百个类似损失中的三个例子。4只在系统级别(而不是组件级别)考虑可靠性是没有帮助的。复杂的系统几乎总是有许多需求(或目标)，而实现这些目标的方式是有限制的。例如，化工厂可能非常可靠地生产化学品(工厂的目标或任务)，但同时污染了工厂周围的环境。该工厂生产化学品可能非常可靠，但不安全。大多数安全关键型系统对如何实现任务或目标既有任务(非安全)要求，也有安全约束。“系统故障”或不能满足其要求并不等同于危险或事故。一个例外是，如果安全是系统的唯一目标;然而，即使是像空中交通管制这样的系统，除了安全目标之外，通常也存在诸如优化吞吐量等非安全目标。
一种常用的安全评估方法是使用概率风险评估来评估部件的可靠性，然后将这些值组合起来得到系统的可靠性。除了这种评估忽略了由“未失败”组件的交互所引起的事故之外(参见误解3)，大多数这些评估只包括随机硬件故障，并假设故障之间是独立的。因此，当系统只是硬件和相对简单时，它们提供了接近真正的安全评估。当这些概率风险方法被开发出来的时候，这样的系统已经存在了50多年;实际上，今天所有的系统(尤其是复杂的系统)都包含非随机成分，包括软件逻辑和人类做出的复杂认知决策。
我们需要停止假装这些对安全的概率估计与现实有任何关系，而不是把我们对安全的信心建立在它们之上。在我从事系统安全工程的40年里，我检查了数百个事故报告。几乎每一起事故都涉及一个系统，该系统有一个概率风险评估，表明事故可能/不会发生，通常以它确实发生的方式发生。
误解3:复杂系统中部件的安全性是一个有用的概念;也就是说，我们可以在脱离整个系统设计的情况下对软件的安全性进行建模或分析
虽然更复杂系统的组件可能有危险(可能导致某种类型的损失的状态)，但当组件不是整个系统所关心的时候，这些通常不太重要。例如，汽车或飞机上的阀门可能有锋利的边缘，可能导致操作人员的磨损或割伤。但更有趣的危险总是在系统层面上，阀门上的尖角并不影响阀门在核电站的核辐射无意释放或化工厂的有毒化学物质释放(例如)中所涉及的危险。
换句话说，安全主要是一个系统属性，而相关的危险是系统级的危险。当然，组件的行为可能导致系统危险，但是如果不将所有系统组件的行为作为一个整体来考虑，就无法确定其贡献。潜在有效的安全工程方法包括识别系统危险，然后消除，如果不可能，在系统级别预防或减轻它们。系统危害通常可以追溯到系统组件的行为，但反之则不然。一个人不能孤立地证明每个组件都是安全的，然后用这种分析得出结论，认为系统作为一个整体是安全的。
另一种说法是，系统组件的故障并不等同于危险。组件故障可能导致系统危险，但组件故障并不是发生危险的必要条件。此外，即使发生了组件故障，它也可能不会导致系统危险。这只是澄清关于可靠性和安全性区别的误解#2的另一种方式。
错误观念#4:软件可以通过测试、模拟或标准形式验证来证明是安全的
测试:详尽的软件测试是不可能的。这个问题可以通过检查“穷尽”在软件测试领域的含义来解释:
- 输入:软件系统的可能输入域包括有效和无效输入、输入的潜在时间有效性(一个输入可能在某个时间有效，但在其他时间无效)，以及当设计包含历史记录(几乎是所有的软件)时所有可能的输入序列。这个领域太大了，只能在现实的时间范围内涵盖非常小的一部分可能的输入。
- 系统状态:就像潜在输入的数量一样，这些系统中的状态数量是巨大的。例如，TCASan飞机避碰系统估计有10个40可能的状态。5需要注意的是，在自动驾驶(甚至非自动驾驶)车辆的实现中，避碰只是自动化的一小部分。
- 软件设计的覆盖率:用一个简单的覆盖率度量方法，比如“在测试期间，通过软件的所有路径都至少执行一次”，涉及大量不切实际的测试时间，甚至不能保证正确性，更不用说安全性了。
- 执行环境:除了到目前为止列出的问题之外，当软件输出与实际状态(受控过程)相关时，执行环境就变得重要起来而且它指的是经常变化的环境)，如天气、温度、海拔高度、压力等。环境包括使用系统的社会政策。
此外，正如Dijkstra多次引用的那样，测试只能显示错误的存在，而不能显示错误的不存在。
最后，也可能是最重要的，即使我们可以彻底地测试软件，几乎所有涉及软件的事故都源于不安全的需求。2，6测试只能显示软件与需求的一致性，而不能显示需求是否有缺陷。尽管测试对任何系统(包括软件)都很重要，但它不能用作可接受安全性的度量或验证。将一致性分析移到更高的级别(验证)只会转移问题，而不会解决问题。
系统和软件需求开发必然是一个系统工程问题，而不是一个软件工程问题。
仿真:所有的模拟都依赖于对系统执行环境的假设。自动驾驶汽车现在已经在模拟器中经历了数十亿起事故，而且一旦在真正的道路上使用，仍然会发生事故。这里描述的测试问题适用于这里，但更大的问题是，当开发和模拟中使用的假设不成立时，事故就会发生。换句话说，事故的发生是因为工程师们在工程设计中所说的“未知的未知”。我们无法确定未知的未知是什么。因此，模拟只能显示我们已经处理了我们想到的事情，而不是我们没有想到的，认为不可能的，或无意中被排除在模拟环境之外的事情。
正式的验证:几乎所有涉及软件的事故都源于不安全的需求，而不是实现错误。当然，在执行安全要求方面的错误也有可能导致事故;然而，在我40多年来所见的数百个与软件相关的事故中，没有一个与正确、完整和安全的需求的错误实现有关。当我观察那些声称是实现的软件逻辑导致了损失的事故时，我总是发现软件逻辑缺陷源于缺乏足够的需求。在本专栏侧边栏中显示的三个示例中，没有一个事故(以及我所见过的数百个其他事故)可以使用正式的验证方法来避免。形式化验证(甚至形式化验证)只能显示两个形式化模型的一致性。复杂的物理系统不存在完整的离散数学模型，即所示的受控过程数字在这一栏。
结论
所有这些都导致一个结论，处理计算机控制系统的安全的最有效的方法是专注于创建与安全相关的需求。系统和软件需求开发必然是一个系统工程问题，而不是一个软件工程问题。解决方案肯定不是构建一个软件架构(设计)，然后再生成需求，正如一些计算机科学家令人惊讶地建议的那样。7
可以描述潜在解决方案的一些特征。它可能涉及到使用系统的模型或定义。标准的物理或逻辑连接模型将不起作用。对于大多数这样的模型，分析只能识别组件故障。在某些情况下，可能会识别出导致危险的组件故障，但这是问题的简单部分，忽略了软件和人工。此外，为了达到最有效的效果，该模型应该包括控制人员和组织以及社会控制。当今最有趣的系统是社会技术系统。
利用功能控制模型，可以开发分析工具来分析复杂系统的安全性。在当今最复杂的系统上成功使用的一种方法的信息可以在其中找到建设更安全的世界1还有相关的网站http://psas.scripts.mit.edu/home/．
参考文献
1.莱韦森,净收益建设更安全的世界，麻省理工学院出版社，2012。
2.莱韦森,净收益安全软件:系统安全和计算机，addison - wesley, 1995年。
3.软件在宇宙飞船事故中的作用。美国航空航天协会航天器与火箭杂志(2004年7月)。
4.N.G.莱韦森和j.p托马斯STPA手册(2018);http://psas.scripts.mit.edu/home/materials/
5.莱韦森，N.G.等人。过程控制系统要求规范。软件工程汇刊SE-20， 9(1994年9月)。
侧边栏:由于系统组件之间不安全的交互而导致的事故的三个例子
一些海军飞机正在把导弹从一个地方运到另一个地方。一名飞行员执行了一项计划中的测试，瞄准前方的飞机(正如他被告知的那样)，发射一枚模拟导弹。显然，没有人知道“智能”软件的设计是为了在被命令发射的导弹位置不佳时替换另一枚导弹。在这种情况下，在假导弹和目标之间有一个天线，所以软件决定发射一枚位于不同(更好)位置的实弹。什么飞机部件出了问题?
这次损失涉及火星极地着陆器。为了安全着陆，有必要减慢宇宙飞船的速度。实现这一目标的方法包括使用火星大气层、降落伞和下降引擎(由软件控制)。一旦航天器着陆，该软件必须立即关闭下降引擎，以避免航天器损坏。着陆腿上的一些非常灵敏的传感器可以提供这些信息。但事实证明，当腿被展开时，噪声(传感器信号)会产生。这个预期的行为不在软件需求中。也许它不包括在内，因为软件不应该在这个时候运行，但软件工程师决定早点开始，以平衡处理器上的负载。该软件认为航天器已经着陆，并关闭了下降引擎，而航天器仍在距离行星表面40米的地方。飞船的哪些部件出了故障?
飞机的逆推力装置(用于在飞机着陆后减速)在飞机还在空中时被激活是很危险的。软件中设计了保护装置，以防止飞行员在飞机不在地面时错误地启动推力逆转器。不深入细节，软件确定飞机已经着陆的一些线索是车轮上的重量和车轮旋转速率，由于各种原因，这在这种情况下不成立。例如，跑道非常湿，车轮打滑。结果，飞行员无法启动逆推力装置，飞机冲出了跑道的尽头，撞到了一座小山上。飞机的哪些部件出了问题?
数字图书馆是由计算机协会出版的。版权所有©2020 ACM, Inc.