复杂软件系统的功能安全设计,第二篇
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
良好的流程并不能保证按照此流程设计的系统能达到所要求 的功能安全级别。连最终设计出的系统的优劣都无法保证。 按照劣质的流程也有可能设计出良好甚至是符合功能安全 需求的系统，但这样做要比按照良好流程设计出良好系统 要困难得多。此外，良好的流程可为诠释测试结果提供清 晰的背景。限定测试的内容不仅能够定义测试范围，而且 还间接地定义了需要用非测试方法验证的内容。随着对哪 些内容将通过何种方法进行验证有了清楚的了解，就有可 能对系统符合功能安全标准作出明确且具体化的要求。 例如，如果我们回到之前讨论的“五个九”口号，便很有 可能无法通过测试来证明一年中除最多 316 秒外系统都是 可靠的，因为要做到这点，我们必须在真实的负载条件下 将系统运行数年之久。不过我们也许可以用其他方法来证 明系统可在 316 毫秒内从错误中恢复，并可表明这是可以 接受的，因为在使用系统的环境中（比如客机，而非战斗 机）， 500 毫秒以内的任何错误均不会对客机控制产生明 显的影响。
复杂软件系统的功能安全设计，第二篇
Chris Hobbs，内核开发工程师; Nicola Vulpe, QNX 软件系统公司博士 chobbs@qnx.com、nvulpe@qnx.com
摘要
证明软件系统是否符合功能安全标准，以往主要依靠穷举测 试来解决。这种方法对于运行直到完成的简单确定性单线程 系统来说绰绰有余，但无法胜任目前的多线程系统。由于这 些系统非常复杂，因此无法将它们划归为确定性系统。 在本白皮书系列，第一篇将讨论复杂软件系统的测试局限 性，及在决定如何构建必须符合功能安全标准的复杂软件 系统时应该考虑的某些因素。 第二篇将建议如何结合严密的流程设计、统计测试和设计验 证来提高复杂软件系统的功能安全可靠性。本系列的后续文 章将探讨复杂软件系统具体的功能安全设计与验证策略。 规划功能安全时，我们必须精确地定义测量系统可靠性的标 准。这意味着要避免“五个九”这样轻率营销宣传口号：可 用时间达 99.999%；因此完全可靠，每年中只有 5 分 16 秒 的时间例外。这种口号毫无意义，除非就系统在一年中无 法可靠运行的时间分布提供更多的信息。 如果口号针对的是诸如飞机上的飞行控制系统，那么这 5 分 16 秒的故障是一次性发生（ 0.001% 的故障几率），还是 以每次 316 微秒的片断发生 100 万次（也是 0.001% 的故 障几率），其后果有天壤之别。请参见下表 1，了解“五个 九可用性” 的各种可能含义。 5 分 16 秒的故障可能导致灾难发生，而 316 微秒分布在 100 万个不同不可靠性事件中可能对系统的可靠性无丝毫 影响，甚至根本不会被察觉。实际上，如果每年 3.16 毫秒 的不可用时间分布在 100 万个事件中，并且相邻两个事件之 间具有足够长的可用时间，那么飞机的飞行控制系统可能完 全能容忍一个只有四个九 (99.99%) 可用性的系统。软件的 运行周期也同样值得关注。飞行控制系统很少能够持续运行 超过 20 小时，一般 20 小时后就会重新启动，强制复原。
定义足够的可靠性
系统的可靠性 是指在需要时，及时对事件作出正确响应的 能力；也就是说，它结合了系统 可用性 （系统及时对请求 作出响应的频率）及其 可靠性（作出正确响应的频率）。 换言之，可靠的系统即是在需要时可及时做出正确响应的 系统。
1
QNX 软件系统公司
ห้องสมุดไป่ตู้
复杂软件系统的功能安全设计，第二篇
确立验证方法
1
就软件而论，可对数据和信息进行复制，以不同的格式将 其存储在不同的位置，也可提供错误检测和错误纠正位来 防止出现数据丢失或损坏。时间（或进程）复制可在相同 或不同的处理器中多次执行同一计算，这有助于避免出现 可用性问题，特别是那些与 Heisenbug 相关的问题。 在此白皮书系列的后续篇章中，我们将更详细地探讨构建 和验证功能安全的专门技术。
两者都是缺陷，因为它们没有分配正确的字节数。在第一个 情形中，除非系统遵守严格的内存限制，否则这一缺陷不可 能生成错误，更不必说故障了。但第二个情形则很可能生成 一个错误，因为程序员认为他具有一个 10 字节的缓冲区， 写入的代码不仅仅会覆盖 x，而且会覆盖下五个字节中的任 何值。此错误当然会导致故障。
每年故障次数 1 10 100 1000 10,000 100,000 1,000,000 每次故障的持续时间 5 分 16 秒 32 秒 3.2 秒 316 毫秒 32 毫秒 3.2 毫秒 316 微秒 可能良性 可能引起灾难
证明系统安全完整性等级 (SIL) 的标准要求是要测量、验证 及展示系统的功能安全特性。如 Daniel Jackson 编著的 《 Software for Dependable Systems 》 中指出，此验证涉 及具体的指标、证据和专业知识。 具体指标 任何一个系统都不是绝对可靠的。因此所有关于系统可靠 性的指标都必须明确具体地描述出来，换言之，对于该系 统而言，“足够的可靠性”究竟是什么意思。 证据 指标中定义的系统足够可靠性要求由证据来支持。当然， 这也是包括认证机构、审核员和客户在内的每个人最关心 的。正如没有系统是绝对可靠的，任何验证方法都不是绝 对可信的。虽然这个事实令人难以接受，但是对于复杂系 统的验证来说确实如此。因此，此类系统的认证会牵涉到 使用其他方法搜集的证据。 诸如 IEC 61508 和 EN 50128 的标准列出了若干可行的验 证方法。第 4 页中的“验证功能安全”讨论了如何验证复 杂软件系统的功能安全。 专业知识 人为因素有时的确是故障发生的原因，但专业知识也常常能 够防止故障的发生。归根结底是相关专家（系统架构师、软 件设计师、流程专家、程序员、验证专家等）为足够可靠的 系统设定了要求，以此构建系统，并验证其是否满足需求。 组织和证明这些要求必须对运行环境和故障模式有深刻地了 解。没有哪两种软件设计方案是相同的，评估不同的解决方 案需要丰富的专业知识，以选择最能符合这些要求的设计。 最终，证明特定软件系统满足其定义的功能安全需求，还 需要对软件验证方法、待评估的软件系统及其所处的环境 有充分的了解。
流程的每个阶段都可有缺陷。其中某些缺陷是良性的，有些 缺陷被发现并得到纠正，即使无法纠正，至少可以防止其导 致错误，而有些会引发错误，并且不幸的是，有些错误会 导致故障。例如，疲劳或粗心的开发人员可能向分配 10 个 字节的内存，但可能会输入： char int 或： char int fred[1]; x; fred[100]; x;
3
QNX 软件系统公司
复杂软件系统的功能安全设计，第二篇
多重防线
假设所有缺陷都可能导致故障，在设计和构建功能安全系 统时，我们必须构筑多条防线： 隔离关键安全进程 设计系统时要识别出关键安全组件和进程，以便将它们隔 离，不会受其他组件或进程的影响。例如，汽车数字仪表 板虽然可能共享仪表盘上的某些显示区，但它始终和汽车 资讯娱乐系统隔离。 减少缺陷 了解系统的运行环境，使用合适的工具设计和构建适合该 环境的系统。为项目配备的人员应具有必需的专业知识和 经验，能够按照项目的足够可靠性要求选择、设计和构建 最佳的系统。例如，遵循最佳实践（首先，检查返回值或 发现异常），并确保工作环境能够为设计人员和开发人员 创作上乘作品提供条件。 防止缺陷成为错误 系统的设计和构建应确保缺陷不会成为错误。虽然理想的 解决方案是找到并清除代码中的缺陷，但必须始终假定某 些缺陷是无法检测到的。系统的设计应尽可能做到具有容 错能力，以便系统部署后这些缺陷不会造成错误。 例如，如果我们继续以 第 1 篇中描述的简单电梯系统例子 为例，我们可以安装一台计时器和楼层计数器，在指定的时 间后或在不打开电梯门的情况下运行超过指定次数的楼层后 使电梯在某一楼层停止并打开电梯门。此机制可确保如示例 中那样的缺陷（该缺陷会使电梯在各层间持续运行，不会停 止也不打开电梯门）不会成为错误，并导致故障。 防止错误成为故障 此外，假设任何软件都无法做到没有缺陷，而且这些缺陷 在某种情况下会导致错误，因此设计应防止这些错误转变 为故障。复制是防止错误转变为缺陷的常用方法。此方法 不仅在硬件中的应用广泛，而且还可应用于软件。 有各种复制模型可供使用，包括事务复制和组同步。事务 复制是指被动系统会与当前的主动系统进行同步，并在出 现第一个系统故障时接管主动系统；组同步是指所有非同 步系统均执行所有请求的任务，而请求者（也可以是客户 或委托人）接受并使用第一个结果，或接受所有结果，但 使用多数一致同意的结果。
验证功能安全
在采取一切可能措施确保软件系统功能安全后（例如，紧 张的工期以及其他压力并没有导致任何人在忙中出错或偷 工减料），系统的功能安全性仍然需要验证。系统的可靠 性指标一定要通过验收。对于复杂软件系统，验证必须至 少包含测试和设计验证。
1
Chris Hobbs 等，《Building Functional Safety into Complex Software Systems, Part I》。QNX 软件系统公司，2011 年。
2
QNX 软件系统公司
复杂软件系统的功能安全设计，第二篇
构建功能安全
验证只能表明某个系统是否能够 符合所定义的可靠性标准。在构 建系统之初就要考虑构建其功能 安全，所有构建工作都应遵循 一 个假设： 即所有软件系统都存在 缺陷，而这些缺陷可能会导致故 障的出现。
从缺陷到故障
在系统开发过程中，从最初构想 到设计和开发再到产品推出，每 个阶段都会有缺陷，然而可幸的 事，并不是所有的缺陷都会导致 故障。故障是一系列条件、决策 和行为的产物。图 1 说明了缺陷 如何成为故障的 James Reason 图 1：软件设计和开发中应用的、缺陷如何变成故障的 Reason 模型（经改良）。 模型，其中我们将防御措施进行 细分，来对应软件中的两个层 面：发布前和发布后防御（操作 员的漏洞）。发布前防御是那些 Heisenbug 在产品发布前实施的确认和验证活动，而发布后防御是构 建在系统本身之内的防御，在使用过程中将激活这些防御 很难确定 Heisenbugs 究竟会在系统的哪个部 措施以保护系统。每个故障的成因都可追溯至各个阶段中 分现身。它们对关键任务系统和安全关键系统 的缺陷，至少理论上如此。
功能安全所需的准备工作
确保软件系统的功能安全绝非举手之劳；这是一个费时费力 的过程，不能掉以轻心，但是会带来丰厚的回报。 与所有重要项目一样，首要任务是组建一支专家队伍，明确 定义功能安全的指标，运行场景，以及证明功能安全的论 据。从项目开始，根据指标制定的要求就应该成为项目不 可分割的一部分。 有五个关键任务需要处理；其中前两项必须在项目开始的时 候就解决，因为它们定义其他三项任务的要求。这五项关 键任务是： • • • • • 定义足够的可靠性 建立良好的开发流程 确定验证方法 构建功能安全 验证系统的功能安全
缺陷 错误 故障 代码中的错误，有可能导致不适宜的行为。 代码缺陷导致的不适宜的行为。 由与无法控制的错误导致的系统故障。
的威胁尤其大，被称为应用程序中的定时炸 弹，但是发现或清除它们的可能性几乎为零。
表 2：缺陷、错误和故障 例如，决策者可能决定使用某种语言（如 C）编写软件，这 种语言对预防编程错误的作用不大。管理层为小组分配工作 的形式可能不利于培养良好的编程习惯。开发人员的工作条 件可能会引起他们犯错：工具包不够、工期过于紧张、睡眠 不足等。设计人员和开发人员也是人，他们的设计和编写的 代码必然会有缺陷。测试和设计验证会错过其中的某些缺 陷，使之成为漏网之鱼。最后，发布后防御（如为修复错误 而编写的代码）本身也可能发生故障。
表 1：可能会影响飞行控制系统的“五个九”可用性。
因此，对可靠性的要求进行详细、全面的定义具有双重的 作用。首先，它为系统的功能安全验证提供了准确的衡量 标准。其次，明确了什么是真正的功能性需求，还可以排 除模糊（毫无意义）的需求，并从项目清单中去除为满足 这些需求所需要付出的精力和成本。
建立良好的流程
复杂软件系统的功能安全设计，第二篇
Chris Hobbs，内核开发工程师; Nicola Vulpe, QNX 软件系统公司博士 chobbs@qnx.com、nvulpe@qnx.com
摘要
证明软件系统是否符合功能安全标准，以往主要依靠穷举测 试来解决。这种方法对于运行直到完成的简单确定性单线程 系统来说绰绰有余，但无法胜任目前的多线程系统。由于这 些系统非常复杂，因此无法将它们划归为确定性系统。 在本白皮书系列，第一篇将讨论复杂软件系统的测试局限 性，及在决定如何构建必须符合功能安全标准的复杂软件 系统时应该考虑的某些因素。 第二篇将建议如何结合严密的流程设计、统计测试和设计验 证来提高复杂软件系统的功能安全可靠性。本系列的后续文 章将探讨复杂软件系统具体的功能安全设计与验证策略。 规划功能安全时，我们必须精确地定义测量系统可靠性的标 准。这意味着要避免“五个九”这样轻率营销宣传口号：可 用时间达 99.999%；因此完全可靠，每年中只有 5 分 16 秒 的时间例外。这种口号毫无意义，除非就系统在一年中无 法可靠运行的时间分布提供更多的信息。 如果口号针对的是诸如飞机上的飞行控制系统，那么这 5 分 16 秒的故障是一次性发生（ 0.001% 的故障几率），还是 以每次 316 微秒的片断发生 100 万次（也是 0.001% 的故 障几率），其后果有天壤之别。请参见下表 1，了解“五个 九可用性” 的各种可能含义。 5 分 16 秒的故障可能导致灾难发生，而 316 微秒分布在 100 万个不同不可靠性事件中可能对系统的可靠性无丝毫 影响，甚至根本不会被察觉。实际上，如果每年 3.16 毫秒 的不可用时间分布在 100 万个事件中，并且相邻两个事件之 间具有足够长的可用时间，那么飞机的飞行控制系统可能完 全能容忍一个只有四个九 (99.99%) 可用性的系统。软件的 运行周期也同样值得关注。飞行控制系统很少能够持续运行 超过 20 小时，一般 20 小时后就会重新启动，强制复原。
定义足够的可靠性
系统的可靠性 是指在需要时，及时对事件作出正确响应的 能力；也就是说，它结合了系统 可用性 （系统及时对请求 作出响应的频率）及其 可靠性（作出正确响应的频率）。 换言之，可靠的系统即是在需要时可及时做出正确响应的 系统。
1
QNX 软件系统公司
ห้องสมุดไป่ตู้
复杂软件系统的功能安全设计，第二篇
确立验证方法
1
就软件而论，可对数据和信息进行复制，以不同的格式将 其存储在不同的位置，也可提供错误检测和错误纠正位来 防止出现数据丢失或损坏。时间（或进程）复制可在相同 或不同的处理器中多次执行同一计算，这有助于避免出现 可用性问题，特别是那些与 Heisenbug 相关的问题。 在此白皮书系列的后续篇章中，我们将更详细地探讨构建 和验证功能安全的专门技术。
两者都是缺陷，因为它们没有分配正确的字节数。在第一个 情形中，除非系统遵守严格的内存限制，否则这一缺陷不可 能生成错误，更不必说故障了。但第二个情形则很可能生成 一个错误，因为程序员认为他具有一个 10 字节的缓冲区， 写入的代码不仅仅会覆盖 x，而且会覆盖下五个字节中的任 何值。此错误当然会导致故障。
每年故障次数 1 10 100 1000 10,000 100,000 1,000,000 每次故障的持续时间 5 分 16 秒 32 秒 3.2 秒 316 毫秒 32 毫秒 3.2 毫秒 316 微秒 可能良性 可能引起灾难
证明系统安全完整性等级 (SIL) 的标准要求是要测量、验证 及展示系统的功能安全特性。如 Daniel Jackson 编著的 《 Software for Dependable Systems 》 中指出，此验证涉 及具体的指标、证据和专业知识。 具体指标 任何一个系统都不是绝对可靠的。因此所有关于系统可靠 性的指标都必须明确具体地描述出来，换言之，对于该系 统而言，“足够的可靠性”究竟是什么意思。 证据 指标中定义的系统足够可靠性要求由证据来支持。当然， 这也是包括认证机构、审核员和客户在内的每个人最关心 的。正如没有系统是绝对可靠的，任何验证方法都不是绝 对可信的。虽然这个事实令人难以接受，但是对于复杂系 统的验证来说确实如此。因此，此类系统的认证会牵涉到 使用其他方法搜集的证据。 诸如 IEC 61508 和 EN 50128 的标准列出了若干可行的验 证方法。第 4 页中的“验证功能安全”讨论了如何验证复 杂软件系统的功能安全。 专业知识 人为因素有时的确是故障发生的原因，但专业知识也常常能 够防止故障的发生。归根结底是相关专家（系统架构师、软 件设计师、流程专家、程序员、验证专家等）为足够可靠的 系统设定了要求，以此构建系统，并验证其是否满足需求。 组织和证明这些要求必须对运行环境和故障模式有深刻地了 解。没有哪两种软件设计方案是相同的，评估不同的解决方 案需要丰富的专业知识，以选择最能符合这些要求的设计。 最终，证明特定软件系统满足其定义的功能安全需求，还 需要对软件验证方法、待评估的软件系统及其所处的环境 有充分的了解。
流程的每个阶段都可有缺陷。其中某些缺陷是良性的，有些 缺陷被发现并得到纠正，即使无法纠正，至少可以防止其导 致错误，而有些会引发错误，并且不幸的是，有些错误会 导致故障。例如，疲劳或粗心的开发人员可能向分配 10 个 字节的内存，但可能会输入： char int 或： char int fred[1]; x; fred[100]; x;
3
QNX 软件系统公司
复杂软件系统的功能安全设计，第二篇
多重防线
假设所有缺陷都可能导致故障，在设计和构建功能安全系 统时，我们必须构筑多条防线： 隔离关键安全进程 设计系统时要识别出关键安全组件和进程，以便将它们隔 离，不会受其他组件或进程的影响。例如，汽车数字仪表 板虽然可能共享仪表盘上的某些显示区，但它始终和汽车 资讯娱乐系统隔离。 减少缺陷 了解系统的运行环境，使用合适的工具设计和构建适合该 环境的系统。为项目配备的人员应具有必需的专业知识和 经验，能够按照项目的足够可靠性要求选择、设计和构建 最佳的系统。例如，遵循最佳实践（首先，检查返回值或 发现异常），并确保工作环境能够为设计人员和开发人员 创作上乘作品提供条件。 防止缺陷成为错误 系统的设计和构建应确保缺陷不会成为错误。虽然理想的 解决方案是找到并清除代码中的缺陷，但必须始终假定某 些缺陷是无法检测到的。系统的设计应尽可能做到具有容 错能力，以便系统部署后这些缺陷不会造成错误。 例如，如果我们继续以 第 1 篇中描述的简单电梯系统例子 为例，我们可以安装一台计时器和楼层计数器，在指定的时 间后或在不打开电梯门的情况下运行超过指定次数的楼层后 使电梯在某一楼层停止并打开电梯门。此机制可确保如示例 中那样的缺陷（该缺陷会使电梯在各层间持续运行，不会停 止也不打开电梯门）不会成为错误，并导致故障。 防止错误成为故障 此外，假设任何软件都无法做到没有缺陷，而且这些缺陷 在某种情况下会导致错误，因此设计应防止这些错误转变 为故障。复制是防止错误转变为缺陷的常用方法。此方法 不仅在硬件中的应用广泛，而且还可应用于软件。 有各种复制模型可供使用，包括事务复制和组同步。事务 复制是指被动系统会与当前的主动系统进行同步，并在出 现第一个系统故障时接管主动系统；组同步是指所有非同 步系统均执行所有请求的任务，而请求者（也可以是客户 或委托人）接受并使用第一个结果，或接受所有结果，但 使用多数一致同意的结果。
验证功能安全
在采取一切可能措施确保软件系统功能安全后（例如，紧 张的工期以及其他压力并没有导致任何人在忙中出错或偷 工减料），系统的功能安全性仍然需要验证。系统的可靠 性指标一定要通过验收。对于复杂软件系统，验证必须至 少包含测试和设计验证。
1
Chris Hobbs 等，《Building Functional Safety into Complex Software Systems, Part I》。QNX 软件系统公司，2011 年。
2
QNX 软件系统公司
复杂软件系统的功能安全设计，第二篇
构建功能安全
验证只能表明某个系统是否能够 符合所定义的可靠性标准。在构 建系统之初就要考虑构建其功能 安全，所有构建工作都应遵循 一 个假设： 即所有软件系统都存在 缺陷，而这些缺陷可能会导致故 障的出现。
从缺陷到故障
在系统开发过程中，从最初构想 到设计和开发再到产品推出，每 个阶段都会有缺陷，然而可幸的 事，并不是所有的缺陷都会导致 故障。故障是一系列条件、决策 和行为的产物。图 1 说明了缺陷 如何成为故障的 James Reason 图 1：软件设计和开发中应用的、缺陷如何变成故障的 Reason 模型（经改良）。 模型，其中我们将防御措施进行 细分，来对应软件中的两个层 面：发布前和发布后防御（操作 员的漏洞）。发布前防御是那些 Heisenbug 在产品发布前实施的确认和验证活动，而发布后防御是构 建在系统本身之内的防御，在使用过程中将激活这些防御 很难确定 Heisenbugs 究竟会在系统的哪个部 措施以保护系统。每个故障的成因都可追溯至各个阶段中 分现身。它们对关键任务系统和安全关键系统 的缺陷，至少理论上如此。
功能安全所需的准备工作
确保软件系统的功能安全绝非举手之劳；这是一个费时费力 的过程，不能掉以轻心，但是会带来丰厚的回报。 与所有重要项目一样，首要任务是组建一支专家队伍，明确 定义功能安全的指标，运行场景，以及证明功能安全的论 据。从项目开始，根据指标制定的要求就应该成为项目不 可分割的一部分。 有五个关键任务需要处理；其中前两项必须在项目开始的时 候就解决，因为它们定义其他三项任务的要求。这五项关 键任务是： • • • • • 定义足够的可靠性 建立良好的开发流程 确定验证方法 构建功能安全 验证系统的功能安全
缺陷 错误 故障 代码中的错误，有可能导致不适宜的行为。 代码缺陷导致的不适宜的行为。 由与无法控制的错误导致的系统故障。
的威胁尤其大，被称为应用程序中的定时炸 弹，但是发现或清除它们的可能性几乎为零。
表 2：缺陷、错误和故障 例如，决策者可能决定使用某种语言（如 C）编写软件，这 种语言对预防编程错误的作用不大。管理层为小组分配工作 的形式可能不利于培养良好的编程习惯。开发人员的工作条 件可能会引起他们犯错：工具包不够、工期过于紧张、睡眠 不足等。设计人员和开发人员也是人，他们的设计和编写的 代码必然会有缺陷。测试和设计验证会错过其中的某些缺 陷，使之成为漏网之鱼。最后，发布后防御（如为修复错误 而编写的代码）本身也可能发生故障。
表 1：可能会影响飞行控制系统的“五个九”可用性。
因此，对可靠性的要求进行详细、全面的定义具有双重的 作用。首先，它为系统的功能安全验证提供了准确的衡量 标准。其次，明确了什么是真正的功能性需求，还可以排 除模糊（毫无意义）的需求，并从项目清单中去除为满足 这些需求所需要付出的精力和成本。
建立良好的流程