10. 安全性

第10章 安全性

吉尔斯：看在上帝的份上，小心点……如果你受伤或者被杀了，我会很生气的。
威尔洛：嗯，我们尽量不去送命。这是我们整个使命宣言的一部分：不要被杀掉。
吉尔斯：很好。

——《吸血鬼猎人巴菲》，第三季，剧集“安妮”

“不要杀任何人”应该是每个软件架构师使命宣言的一部分。

过去，软件可能导致人们死亡、受伤或造成损害的想法，牢固地属于电脑失控的科幻领域；想想在如今年代久远但依然经典的电影《2001：太空漫游》中，HAL有礼貌地拒绝打开舱门的场景，使得戴夫在太空中陷入困境。

可悲的是，并不只有在电影中。随着软件开始控制我们生活中越来越多的设备，软件安全已成为一个关键问题。

软件（由0和1组成的字符串）能够造成杀伤或破坏的想法，仍然是一个不自然的概念。公平地说，造成灾难的并不是0和1本身——至少不是直接的。关键在于它们连接到了什么。软件及其运行的计算机必须以某种方式与外界相连，才能造成损害。这是个好消息。不过，坏消息是这个好消息并不是那么好。软件总是与外界相连的。如果你的程序在自身之外没有任何可观察到的效果，它可能就没有存在的意义。

2009年，舒申斯卡亚水电站的一名员工使用网络远程——并且意外地——通过几次错误的击键激活了一台未使用的涡轮机。离线涡轮机制造了一个“水锤”，淹没然后摧毁了工厂并杀死了数十名工人。

还有许多其他同样臭名昭著的例子。Therac 25致命的辐射过量，阿丽亚娜5号爆炸和一百起鲜为人知的事故都造成了伤害，因为计算机与环境相连：涡轮机，X射线发射器和火箭的转向控制，在刚刚引用的例子中。臭名昭著的Stuxnet病毒是为了故意造成损害和破坏而创建的。在这些情况下，软件命令其环境中的某些硬件采取灾难性的操作，而硬件执行了。执行器是将硬件连接到软件的设备；它们是 0 和 1 世界与运动和控制世界之间的桥梁。向执行器发送一个数字值（或在与执行器对应的硬件寄存器中写入一个位串），该值被转换为某种机械动作，无论好坏。

但与外界的连接并不一定意味着机器人手臂、铀离心机或导弹发射器：连接到一个简单的显示屏就足够了。有时，计算机所要做的就是向其人类操作员发送错误的信息。1983年9月，一颗苏联卫星向其地面系统计算机发送数据，该计算机将该数据解释为美国向莫斯科发射的导弹。几秒钟后，计算机报告了第二枚导弹在飞行。很快，出现了第三个，然后是第四个，然后是第五个。苏联战略火箭军中校斯坦尼斯拉夫·叶夫格拉福维奇·彼得罗夫做出了一个惊人的决定，无视计算机，认为它们是错误的。他认为美国极不可能只发射几枚导弹，从而招致大规模的报复性破坏。他决定等待，看看导弹是否真实 —— 也就是说，看看他的国家的首都是否会被焚烧。正如我们所知，事实并非如此。苏联系统将罕见的阳光条件误认为是飞行中的导弹。你和/或你的父母很可能把你的生命归功于彼得罗夫中校。

当然，当计算机出错时，人类并不总是能够正确处理。2009年6月1日的暴风雨夜晚，从里约热内卢飞往巴黎的法国航空447号航班坠入大西洋，造成机上228人全部遇难，尽管飞机的引擎和飞行控制系统工作得非常完美。直到2011年5月才被找回的空客A-330的飞行记录器显示，飞行员们从未意识到飞机已经进入了一个高空失速状态。测量空速的传感器被冰堵塞，因此变得不可靠；自动驾驶仪因此断开。人类飞行员认为飞机速度过快（并且有结构故障的危险），而实际上飞机速度过慢（并且正在下坠）。在从35,000英尺高度坠落的整个三分钟以上的时间里，飞行员们一直在尝试拉起机头并减小油门以降低速度，而他们真正需要做的是降低机头以增加速度并恢复正常飞行。很可能增加了混乱的是A-330的失速警告系统的工作原理。当系统检测到失速时，它会发出响亮的听觉警报。当软件“认为”迎角测量值无效时，它会停用失速警告。这可能发生在空速读数非常低的情况下。这就是AF447发生的情况：其前进速度下降到60节以下，迎角极高。由于这个飞行控制软件规则，失速警告几次停止后又重新启动。更糟糕的是，每当飞行员向前推动操纵杆（增加空速并将读数带入“有效”范围，但仍然处于失速状态）时，警告就会响起，然后当他拉回时警告就停止。也就是说，做正确的事情得到了完全错误的反馈，反之亦然。这是一个不安全的系统，还是一个操作不当的安全系统？最终，像这样的问题在法庭上决定。

当这一版即将出版时，波音公司仍在从其737 MAX飞机的停飞中恢复过来，此前发生了两起似乎至少部分由一个名为MCAS的软件引起的坠机事故，该软件在错误的时间将飞机的机头推下。这里似乎也涉及到了故障的传感器，以及一个令人困惑的设计决策，该决策导致软件仅依赖一个传感器来确定其行为，而不是飞机上可用的两个传感器。此外，似乎波音公司从未在传感器失效的条件下测试过该软件。该公司确实提供了一种在飞行中禁用该系统的方法，尽管当你的飞机尽其所能要杀死你时记住如何做到这一点可能对机组人员要求过高——尤其是他们最初并不知道MCAS的存在。总共，在两起737 MAX飞机的坠机事故中，有346人遇难。

好的，恐怖故事讲得够多了。让我们来谈谈它们背后的原则，以及这些原则如何影响软件和架构。

安全涉及系统有能力避免进入导致或导致其环境中的参与者遭受损害、受伤或失去生命的状态的能力。这些不安全的状态可能由多种因素引起：

• 遗漏（事件未能发生）。
• 差错（错误地发生了不希望发生的事件）。这个事件在某些系统状态下可能是可接受的，但在其他状态下则是不希望发生的。
• 时序。 提前（事件发生在所需时间之前）或延迟（事件发生在所需时间之后）的时序都可能潜在地成为问题。
• 系统值问题。这些问题分为两类：粗略的错误值是可以检测到的错误值，而细微的错误值通常是不可检测的。
• 序列遗漏和插入。在一系列事件中，要么缺少了一个事件（遗漏），要么多插入了一个意外的事件（插入）。
• 乱序。一系列事件到达了，但顺序没有按照预定的顺序。

安全还涉及检测这些不安全状态并从中恢复，以防止或至少最大限度地减少由此产生的伤害。

系统的任何部分都可能导致不安全状态：软件、硬件部分或环境可能以意外的不安全方式运行。一旦检测到不安全状态，潜在的系统响应类似于在可用性中列举的响应（在 第4章中）。应识别不安全状态，并使系统安全通过

• 从不安全状态恢复或将系统置于安全模式后继续操作，或

• 关闭（故障安全），或

• 过渡到需要手动操作的状态（例如，如果汽车中的助力转向失效，则手动转向）。

此外，应立即报告和/或记录不安全状态。

为安全而架构首先需要识别系统的安全关键功能——正如上文所概述的，那些可能导致伤害的功能——使用如失效模式和影响分析（FMEA；也称为危害分析）和故障树分析（FTA）等技术。FTA是一种自上而下的演绎方法，用于识别可能导致系统进入不安全状态的故障。一旦识别出故障，架构师需要设计机制来检测和减轻故障（最终是危害）。

本章概述的技术旨在发现系统运行可能导致的潜在危险，并帮助制定应对这些危险的策略。

10.1 安全性通用场景

在此背景下，我们可以构建安全性的通用场景，如表10.1所示。

表10.1 安全性的通用场景

场景部分	描述	可能的值
来源	数据源（传感器、计算值的软件组件、通信通道）、时间源（时钟）或用户操作	特定实例： 传感器 软件组件 通信通道 设备（如时钟）
触发事件	遗漏、多余或出现不正确的数据或时间	遗漏的特定实例： 值永远不会到达。 从不执行函数。 佣金的特定实例： 函数执行不正确。 设备产生虚假事件。 设备生成不正确的数据。 不正确数据的特定实例： 传感器报告不正确的数据。 软件组件产生不正确的结果。 计时故障： 数据到达太晚或太早。 生成的事件发生得太晚、太早或以错误的速率发生。 事件的发生顺序错误。
环境	系统操作模式	正常运行 降级的操作 手动操作 恢复模式
工件	工件是系统的某些部分。	系统的安全的关键部分
响应	系统没有离开安全状态空间，或者系统返回到安全状态空间，或者系统继续以降级模式运行以防止（进一步）伤害或损坏，或将伤害或损坏降至最低。建议用户注意不安全状态或防止进入不安全状态。并且记录该事件到日志中。	识别不安全状态以及以下一项或多项： 避免不安全状态 恢复 以降级或安全模式继续 关闭 切换到手动操作 切换到备份系统 通知适当的实体（人员或系统） 记录不安全状态（及其响应）
响应度量	返回安全状态空间的时间；造成的损坏或伤害	以下一项或多项： 避免进入不安全状态的数量或百分比 系统可以（自动）恢复的不安全状态的数量或百分比 风险暴露的变化：大小（损失）*概率（损失） 系统可以恢复的时间百分比 系统处于降级或安全模式的时间量 系统关闭的时间量或百分比 进入到恢复经过的时间（从手动操作、安全或降级模式）

安全场景示例为： 患者监护系统中的传感器在 100 毫秒后未能报告生命关键数值。记录故障，在控制台上亮起警告灯，并启用备用（低保真度）传感器。系统在不超过 300 毫秒后使用备用传感器监测患者。 图10.1 说明了这一场景。

图10.1 具体的安全场景示例

10.2 安全性策略

安全性策略可以大致分为：不安全状态避免、不安全状态检测或不安全状态修正。图10.2 显示了一套安全性策略的目标。

图10.2 安全性策略的目标

避免或检测进入不安全状态的逻辑先决条件是能够识别是什么造成的不安全状态。以下策略假定该功能，这意味着一旦你掌握了架构，就应该执行自己的危害分析或 FTA。你的设计决策本身可能引入了需求分析期间未考虑的新安全漏洞。

你会注意到这里介绍的策略与 第4章 中介绍的关于可用性的策略之间存在大量重叠。出现这种重叠是因为可用性问题通常会导致安全问题，并且因为修复这些问题的许多设计解决方案可以在这些质量要求之间共享。

图10.3 总结了实现安全性的架构策略。

图10.3 安全性策略

不安全状态避免

替代

这种策略采用保护机制（通常基于硬件）来执行具有潜在危险的软件设计功能。例如，可以使用看门狗、监视器和互锁等硬件保护设备代替软件版本。这些机制的软件版本可能缺乏资源，而单独的硬件设备提供和控制自己的资源。通常，只有当被替换的功能相对简单时，替换才有用。

预测模型

预测模型策略，如第4章中所述，预测系统进程、资源或其他属性的运行状况（基于监视状态），不仅要确保系统在其标称操作参数内运行，还要提供潜在问题的早期预警。例如，一些汽车巡航控制系统计算车辆与前方障碍物（或其他车辆）之间的接近速率，并在距离和时间变得太小可能碰撞时提醒驾驶员。预测模型通常与状态监测相结合，我们将在后面讨论。

不安全状态检测

超时

超时策略用于确定组件的操作是否满足其时限约束。这可以通过引发异常的形式实现，以指示组件在不满足其时限约束时出现失效。因此，这种策略可以检测超时和遗漏失效。超时是实时或嵌入式系统和分布式系统中特别常见的策略。它与可用性策略的系统监视器、心跳和 ping-echo也有关联。

时间戳

如 第4章 中所述，时间戳策略用于检测不正确的事件序列，主要是在分布式消息传递系统中。可以通过在事件发生后立即将本地时钟的状态分配给事件来建立事件的时间戳。序列号也可用于此目的，因为分布式系统中的时间戳在不同处理器之间可能不一致。

条件监测

这种策略涉及检查进程或设备中的条件，或验证设计期间做出的假设，可能通过使用断言。条件监测可识别可能导致危险行为的系统状态。但是，监视器应该简单（理想情况下是可证明的），以确保它不会引入新的软件错误或对整体工作负载产生重大影响。状态监测为预测模型和健全性检查提供输入。

健全性检查

健全性检查策略检查特定操作结果、组件输入、输出的有效性或合理性。这种策略通常基于对内部设计、系统状态或受审查信息性质的了解。它最常用于接口，以检查特定的信息流。

比较

比较策略允许系统通过比较许多同步或复制元素产生的输出来检测不安全状态。因此，比较策略与冗余策略（通常是可用性讨论中介绍的主动冗余策略）一起使用。当复制的组件的数量为三个或更多时，比较策略不仅可以检测不安全状态，还可以指示导致不安全状态的组件。比较与可用性中使用的投票策略有关。但是，比较可能并不总是导致投票；另一种选择是在输出不同时直接关闭组件。

抑制

抑制策略旨在限制与已进入的不安全状态相关的危害。此类别包括三个子类别：冗余、限制后果和障碍。

冗余

乍一看，冗余策略似乎类似于可用性讨论中提出的各种备用/冗余策略。显然，这些策略是重叠的，但由于安全性和可用性的目标不同，因此备份组件的使用也不同。在安全领域，冗余使系统能够在不希望完全关闭或进一步降级的情况下继续运行。

副本是最简单的冗余策略，因为它只涉及克隆组件。拥有相同组件的多个副本可以有效地防止硬件的随机故障，但它不能防止硬件或软件中的设计或实现错误，因为这种策略中没有嵌入任何形式的多样性。

相比之下，功能冗余旨在通过实现设计多样性来解决硬件或软件组件中的共模失效问题（其中副本同时表现出相同的故障，因为它们共享相同的实现）。这种策略试图通过增加冗余的多样性来处理设计故障的系统性。在给定相同输入的情况下，功能冗余组件的输出应相同。然而，功能冗余策略仍然容易受到规范错误的影响，当然，功能副本的开发和验证成本更高。

最后，分析冗余策略不仅允许组件的多样性，还允许在输入和输出级别可见的更高级别的多样性。因此，它可以通过使用单独的需求规范来容忍规范错误。分析冗余通常涉及将系统划分为高确定性和高性能（低保证）部分。高保证部分设计为简单可靠，而高性能部分通常设计为更复杂、更准确，但不太稳定：它变化更快，可能不如高保证部分可靠。（因此，这里不是指延迟或吞吐量意义上的高性能；相反，这部分比高保证部分更好地“执行”其任务。）

限制后果

抑制策略的第二个子类别称为限制后果。这些策略都旨在限制系统进入不安全状态可能导致的不良影响。

从概念上讲，中止策略是最简单的。如果确定操作不安全，则会在造成损坏之前中止该操作。这种技术被广泛用于确保系统安全地发生故障。

降级策略在组件失效时保持最关键的系统功能，以受控方式丢弃或更换功能。此方法允许单个组件失效以有计划的、有意和安全的方式优雅地减少系统功能，而不是导致整个的系统失效。例如，汽车导航系统可能会在失去GPS卫星信号的长隧道中继续使用（不太准确的）航位推算算法运行。

屏蔽策略通过比较多个冗余组件的结果并在一个或多个组件输出结果不同的情况下采用投票程序来掩盖故障。为了使这种策略按预期工作，投票程序必须简单且高度可靠。

屏障

屏障策略通过阻止问题传播来抑制问题。

防火墙策略是限制访问策略的特定实现，在 第11章 中有描述。防火墙限制对指定资源（通常是处理器、内存和网络连接）的访问。

互锁策略可防止因事件顺序不正确而导致的失效。此策略的实现通过控制对受保护组件的所有访问（包括控制影响这些组件的事件的正确顺序）来提供详细的保护方案。

恢复

最后一类安全策略是恢复，它的作用是将系统置于安全状态。它包含三种策略：回滚、修复状态和重新配置。

回滚策略允许系统在检测到故障时恢复到先前已知良好状态的已保存副本（回滚行）。此策略通常与检查点和事务结合使用，以确保回滚完整且一致。一旦达到良好状态，就可以继续执行，可能会采用其他策略（如重试或降级）来确保失效不会再次发生。

修复状态策略修复错误状态 —— 有效地增加组件可以胜任处理的状态集（即，没有失效）—— 然后继续执行。例如，车辆的车道保持辅助功能将监控驾驶员是否停留在车道内，并在车辆漂移时主动将车辆返回到车道线之间的位置（安全状态）。这种策略不适合作为从意外故障中恢复的手段。

重新配置尝试通过将逻辑架构重新映射到（可能有限的）剩余运行的资源上来从组件失效中恢复。理想情况下，这种重新映射允许维护全部功能。当无法做到这一点时，系统可能会结合降级策略保持部分功能。

10.3基于策略的安全问卷

基于 第10.2节 中描述的策略，我们可以创建一组受策略启发的问题，如 表10.2 所示。为了大致了解为支持安全而做出的架构选择，分析师会询问每个问题并将答案记录在表中。然后，可以将这些问题的答案作为进一步活动的重点：文档调查、代码或其他工件分析、代码逆向工程等。

表10.2 基于策略的安全问卷

策略组	策略问题	支持与否（是/否）	风险	设计决策和位置	原因和假设
不安全状态回避	你是否使用替代，即更安全的、通常基于硬件的保护机制来存储具有潜在危险的软件设计功能？
	你是否使用预测模型根据受监视的信息预测系统进程、资源或其他属性的运行状况状态，不仅要确保系统在其标称运行参数内运行，还要提供潜在问题的早期预警？
不安全状态检测	是否使用超时来确定组件的操作是否满足其时限约束？
	是否使用时间戳来检测不正确的事件序列？
	你是否使用状态监测来检查进程或设备中的条件，特别是验证设计过程中的假设？
	是否使用健全性检查来检查特定操作结果的有效性或合理性，或者组件的输入或输出？
	系统是否使用比较来检测不安全状态，方法是根据同步或复制元素的数量比较生成的输出？
抑制：冗余	你是否使用副本（组件的克隆）来防止硬件的随机故障？
	你是否使用功能冗余通过实现设计多样化的组件来解决共模故障？
	你是否使用分析冗余（包括高保证/高性能和低保证/低性能替代方案的功能“副本”）来容忍规范错误？
抑制：限制后果	系统是否可以在确定为不安全的操作造成损坏之前中止操作？
	系统是否提供受控的降级，其中最关键的系统功能在组件失效时保持，而不太重要的功能被丢弃或降级？
	系统是否通过比较多个冗余组件的结果来屏蔽故障，并在一个或多个组件不同的情况下采用投票程序？
抑制：屏障	系统是否支持通过防火墙限制对关键资源（例如，处理器、内存和网络连接）的访问？
	系统是否控制对受保护组件的访问，并通过互锁防止因错误地对事件进行排序而导致的失效？
恢复	系统是否能够在检测到失效时回滚，即恢复到以前的已知良好状态？
	系统是否可以修复确定为错误的状态，而不失效，然后继续执行？
	在发生失效时，系统是否可以通过将逻辑架构重新映射到正常运行的资源上来重新配置资源？

在开始基于策略的安全调查问卷之前，你应该评估所审查的项目是否已执行危害分析或 FTA，以确定构成系统中不安全状态（要检测、避免、遏制或恢复）的内容。如果没有这种分析，安全设计可能会不太有效。

10.4 安全性的模式

系统意外停止运行、开始错误运行或陷入降级运行模式，即使不是灾难性的，也可能会对安全产生负面影响。因此，寻找安全模式的第一个地方是可用性模式，如 第4章 中描述的模式。它们都适用于这里。

• 传感器冗余。如果传感器生成的数据对于确定状态是安全还是不安全很重要，则应复制该传感器。这可以防止任何单个传感器失效。此外，独立软件应监控每个传感器——实质上，第4章 中的冗余备用策略适用于安全关键硬件。

  好处：

  • 应用于传感器的这种形式的冗余，可防止单个传感器发生故障。

  权衡：

  • 传感器冗余会增加系统成本，处理来自多个传感器的输入比处理来自单个传感器的输入更复杂。

• 监视器-执行器。此模式侧重于在向物理执行器发送命令之前使用的两个软件元素（监视器和执行器控制器）。执行器控制器执行必要的计算，以确定要发送到物理执行器的值。监视器在发送这些值之前检查这些值的合理性。这将值的计算与值的测试是分开的。

  好处：

• 在应用于执行器控制的这种形式的冗余中，监视器充当执行器控制器计算的冗余检查。

  权衡：

  • 监视器的开发和维护需要时间和资源。

  • 由于这种模式在执行器控制和监控之间实现了分离，因此这种特殊的权衡很容易操作，使监视器根据需要变得简单（易于生产但可能会错过错误）或复杂（更复杂但能够捕获更多错误）。

• 分离安全。安全关键系统必须经常被某些权威机构认证为安全。认证大型系统的成本很高，但将系统分为安全关键部分和非安全关键部分可以降低这些成本。安全关键部分仍必须经过认证。同样，安全关键部分和非关键部分的划分必须经过认证，以确保非安全关键部分对安全关键部分没有影响。

  好处：

  • 系统认证的成本降低了，因为你只需要认证整个系统的一小部分（通常很小）。

  • 成本和安全收益的增加是因为工作只集中在系统中与安全密切相关的部分。

  权衡：

  • 执行分离所涉及的工作可能很昂贵，例如在系统中安装两个不同的网络来划分安全关键和非安全关键消息。但是，这种方法限制了非安全关键部分中的错误的风险和后果，使其不会影响安全关键部分。

  • 分离系统并说服认证机构分离是正确的，并且非安全关键部分对安全关键部分没有影响是困难的，但比替代方案容易得多：让该机构将所有内容认证到相同的严格水平。

设计保证级别

分离的安全模式强调将软件系统分为安全关键部分和非安全关键部分。在航空电子设备中，区别更细。DO-178C，“机载系统和设备认证的软件注意事项”，是联邦航空管理局（FAA），欧盟航空安全局（EASA）和加拿大运输部等认证机构批准所有基于软件的商业航空航天系统的主要文件。它为每个软件功能定义了一个名为设计保证级别 （DAL） 的排名。DAL是通过检查系统中故障条件的影响，根据安全评估过程和危害分析确定的。故障条件按其对飞机、机组人员和乘客的影响分类：

• A：灾难性的。失效可能导致死亡，通常会导致飞机损失。

• B：危害。 失效对安全或性能有很大的负面影响，或由于身体不适或更高的工作负荷而降低机组人员操作飞机的能力，或导致乘客严重或致命伤害。

• C：主要。 失效会大大降低安全裕度或显着增加机组人员的工作负荷，并可能导致乘客不适（甚至轻伤）。

• D：轻微。 失效会略微降低安全裕度或略微增加机组人员的负荷。示例可能包括给乘客带来不便或例行航班计划更改。

• E：没有影响。 失效对安全、飞机操作或机组人员工作负荷没有影响。

软件验证和测试是一项非常昂贵的任务，预算非常有限。DAL 可帮助你决定将有限的测试资源放在何处。下次你乘坐商业航空公司的航班时，如果你看到娱乐系统出现故障或阅读灯一直闪烁，或许可以欣慰地认为，资金花在了为确保飞行控制系统正常工作而作的验证上了。

—PC

10.5 扩展阅读

为了了解软件安全的重要性，我们建议阅读软件故障时出现的一些灾难故事。一个古老的来源是ACM风险论坛，可在risks.org上找到。自1985年以来，彼得·诺依曼（Peter Neumann）一直对此进行调解，并且仍然很强劲。

SAE International 开发的 ARP-4761“民用机载系统和设备安全评估过程指南和方法”和美国国防部开发的 MIL STD 882E“标准实践：系统安全”中描述了两个突出的标准安全流程。

Wu和Kelly [Wu 04]在2004年发表了一套安全策略，基于对现有架构方法的调查，这启发了本章的大部分思考。

Nancy Leveson是软件和安全领域的思想领袖。如果你在安全关键系统工作，你应该熟悉她的工作。你可以从像[Leveson 04]这样的论文开始，它讨论了导致航天器事故的许多与软件相关的因素。或者你可以从[Leveson 11]开始，这本书在当今复杂的社会技术软件密集型系统的背景下处理安全问题。

美国联邦航空管理局是美国政府机构，负责监督美国领空系统，非常关注安全问题。其2019年系统安全手册是该主题的良好实用概述。本手册的 第10章 涉及软件安全。你可以从faa.gov/regulations_policies/handbooks_manuals/aviation/risk_management/ss_handbook/下载它。

Phil Koopman在汽车安全领域享有盛誉。他在网上提供了几个关于安全关键模式的教程。例如，参见youtube.com/watch?v=JA5wdyOjoXg和youtube.com/watch?v=4Tdh3jq6W4Y。Koopman的书《更好的嵌入式系统软件》（Better Embedded System Software）提供了更多关于安全模式的细节[Koopman 10]。

故障树分析可以追溯到 1960 年代初，但它的资源祖父是美国核管理委员会的 故障树手册，于 1981 年出版。NASA的2002年《航空航天应用故障树手册》是NRC手册的更新综合入门书。两者都可以在线下载PDF文件。

与设计保证级别类似，安全完整性级别 （SIL） 提供了各种功能的安全关键程度的定义。这些定义在参与系统设计的架构师之间建立了共识，同时也有助于安全评估。IEC 61508标准题为“电气/电子/可编程电子安全相关系统的功能安全”定义了四个SIL，其中SIL 4是最可靠的，SIL 1是最不可靠的。该标准通过特定领域的标准进行实例化，例如铁路行业的IEC 62279，标题为“铁路应用：通信，信号和处理系统：铁路控制和保护系统软件”。

在研究和开发半自动驾驶和自动驾驶车辆的世界中，功能安全正变得越来越重要。长期以来，ISO 26262一直是道路车辆功能安全的标准。还有一波新的规范，如ANSI/UL 4600，“自动驾驶车辆和其他产品安全评估标准”，它们应对了当软件接管方向盘时出现的挑战，无论是比喻意义上的还是字面意义上的。

10.6 问题讨论

1. 列出 10 种计算机控制的设备，这些设备目前是你日常生活的一部分，并假设恶意或故障系统可能使用它们来伤害你的方式。

2. 编写一个安全方案，旨在防止固定机器人设备（例如生产线上的装配臂）伤害某人，并讨论实现该目标的策略。

3. 美国海军的F/A-18“大黄蜂”战斗机是早期采用电传操纵技术的应用之一，其中机载计算机根据飞行员对操纵杆和方向舵踏板的输入，向控制面（副翼、方向舵等）发送数字指令。飞行控制软件被编程以防止飞行员发出可能使飞机进入不安全飞行状态的某些剧烈机动命令。在早期的飞行测试中，这通常涉及将飞机推向（甚至超出）其极限，飞机进入了一个不安全的状态，而“剧烈机动”正是挽救它所需要的——但计算机忠实地阻止了这些机动。由于设计用来保持飞机安全的软件，飞机坠入了海洋。编写一个安全场景来解决这种情况，并讨论可以防止这种结果的策略。

4. 根据slate.com和其他来源，德国一名少女因为忘记将她的Facebook生日邀请设置为私密，意外地邀请了整个互联网。在15000人确认他们将参加后，女孩的父母取消了派对，通知了警方，并聘请了私人保安来保护他们的家。尽管如此，还是有1500人出现了，导致了几起轻微伤害和不可估量的混乱。Facebook安全吗？请讨论。

5. 写一个安全方案来保护德国不幸的女孩免受Facebook的伤害。

6. 1991年2月25日，在海湾战争期间，美国爱国者导弹连未能拦截来袭的飞毛腿导弹，该导弹击中了一个军营，造成28名士兵死亡，数十人受伤。失效的原因是由于软件中随时间累积的算术错误，对启动以来的时间计算不准确。写一个解决爱国者失效的安全方案，并讨论可能阻止它的策略。

7. 作者詹姆斯·格雷克（James Gleick）around.com/ariane.html写道：“欧洲航天局花了10年时间和70亿美元才生产出阿丽亚娜5号，这是一种巨型火箭，每次发射都能将一对三吨重的卫星送入轨道。火箭在首航不到一分钟就爆炸了…是一个小型计算机程序，试图将 64 位数字塞入 16 位空间。一个错误，一个崩溃。在计算机科学史上记录的所有粗心的代码行中，这一行可能是最具破坏性的。写一个解决阿丽亚娜5号灾难的安全方案，并讨论可能阻止它的策略。

8. 讨论你认为安全性如何倾向于与性能、可用性和互操作性的质量属性进行“权衡”。

9. 讨论安全性和可测试性之间的关系。

10. 安全性和可修改性之间的关系是什么？

11. 考虑到法航447航班的故事，讨论安全性和易用性之间的关系。

12. 为自动柜员机创建故障列表或故障树。包括处理硬件组件故障、通信故障、软件故障、耗材耗尽、用户错误和安全攻击的故障。你将如何使用策略来适应这些错误？

---