PDF安全攸关软件的验证
航空电子软件安全认证是通过基于目标的标准实现的
B. Scott Andersen 和 George Romanski，Verocel 公司
航空电子软件已成为当今飞机设计的基石。航空电子系统的进步减轻了飞机重量，从而降低了燃油消耗，实现了精确导航，提高了发动机性能，并带来了许多其他好处。这些进步已将现代飞机变成了飞行数据中心，计算机控制或监控着机载的许多关键系统。运行这些飞机系统的软件必须尽可能安全。
美国联邦航空管理局 (FAA) 及其欧洲对等机构，以及主要的飞机机身、发动机和航空电子设备制造商共同制定了航空电子软件开发人员的指导，最终形成了文件《机载系统和设备认证中的软件考虑因素》6，该文件在美国由非营利组织 RTCA 以 DO-178B 的名义发布，在欧洲由 EUROCAE 以 ED-12B 的名义发布。DO-178B 中的指导以目标和活动的形式存在，必须满足或执行这些目标和活动才能获得软件产品的认证。
安全评估和风险分析通过描述软件故障对飞机、机组人员和乘客的影响，帮助确定软件的 DAL（设计保证级别）。共有五个 DAL（直接引自 DO-178B 和 FAA 咨询通告 AC 25.1309-1A）：1
* 灾难性的： 会阻止飞机继续安全飞行和着陆的故障情况。
* 危险/严重-重大的： 会降低飞机能力或机组人员应对不利运行条件能力，以至于会出现以下情况的故障条件：(1) 安全裕度或功能能力大幅降低，(2) 身体不适或工作量过大，以至于无法指望飞行机组人员准确或完整地执行其任务，或 (3) 对乘员产生不利影响，包括对少数乘员造成严重或可能致命的伤害。
* 重大的： 会降低飞机能力或机组人员应对不利运行条件能力，以至于会出现以下情况的故障条件，例如，安全裕度或功能能力显著降低，机组人员工作量或损害机组人员效率的条件显著增加，或乘员感到不适，可能包括受伤。
* 轻微的： 不会显著降低飞机安全性的故障条件，并且涉及的机组人员操作完全在其能力范围之内。轻微故障条件可能包括，例如，安全裕度或功能能力略有降低，机组人员工作量略有增加，例如例行飞行计划变更，或对乘员造成一些不便。
* 无影响： 不影响飞机的运行能力或增加机组人员工作量的故障条件。
DO-178B 确定了一组软件级别定义 A 到 E，大致对应于 DAL，其中 A 级软件的临界性最高，E 级软件的临界性最低。要实现的目标取决于分配给项目的软件级别。本文讨论与 A 级相关的活动和目标。
软件工程 101
在 Nancy Leveson 的《Safeware: System Safety and Computers》一书中，作者在前言中引用了以下内容：“一个明显的教训是，大多数事故不是未知科学原理造成的，而是未能应用众所周知的标准工程实践。第二个教训是，事故不会仅仅通过技术手段来预防，而是需要控制系统开发和运行的所有方面。”4 定义和控制软件开发过程是创建安全攸关系统的首要关键。
DO-178B 中确定的目标和活动对于任何在大学软件工程课程中认真听讲的人来说都应该很熟悉。关键点是活动和工作产品是定义的且可重复的。必须确定软件生命周期模型，并且必须记录流程之间的转换标准。简而言之，所有事情都要书面记录下来。软件开发和验证团队使用计划和标准，并且对这些活动进行审核，以确保符合这些计划和标准。这些计划包括
* PSAC（软件认证方面计划）。向认证机构传达总体项目计划的主要手段。
* SDP（软件开发计划）。定义软件生命周期和开发环境。
* SVP（软件验证计划）。描述如何满足软件验证过程目标。
* SCMP（软件配置管理计划）。描述如何管理工件。
* SQAP（软件质量保证计划）。描述 SQA（软件质量保证）职能部门如何确保计划得到遵守并且标准得到满足。
DO-178B 要求存在三个标准：需求、设计和源代码。
必须提供与 SCMP 一致的 SCM（软件配置管理）系统。此外，必须提供问题跟踪或错误跟踪系统，以记录软件或标准和流程合规性方面的问题。所有这些活动、计划和标准（PSAC 除外）都是 SEI3 2 级或 3 级良好运行的组织应该具备的。
没有意外
安全是什么意思？如果将完全安全定义为完全没有风险，那么很难想象任何实用且有用的现实世界系统会是完全安全的。因此，特定系统的安全性是一个相对概念，由系统中已识别的潜在风险、每个风险发生的可能性以及为每个风险制定的缓解措施的有效性来定义。
为了清点和理解系统的风险，您必须首先了解系统应该做什么。否则，您怎么知道它是否做错了（或可能导致什么结果）？一套强大的需求是任何安全攸关系统的基础所必需的。此外，需求将出现在不同的抽象级别，从飞机机身的需求开始，下降到系统、可更换的线路单元、特定子系统的 CSCI（计算机软件配置项）、该子系统的高级需求和低级需求。存在的特定抽象级别将取决于飞机和项目的具体情况，但存在多个级别的需求和抽象是常见的。
让我们回到安全是什么意思的问题，答案的一部分可以概括为“没有意外”。软件的性能应使所有需求都得到满足。此外，应该没有意外功能。也就是说，软件应该只执行需求中指定的内容：不多也不少。您不希望在 30,000 英尺高的紧急情况下了解软件的隐藏额外功能。
可追溯性
说“系统应该没有意外功能”，会引发一个问题：谁的意外？随着需求在越来越低的级别上制定，需求说明必须包含更多细节和具体内容。较低级别的需求应该并且必须为实施者提供额外的价值，否则它们将只是其父需求的重述。您如何区分添加到较低级别需求的内容和仅是较高级别需求的分解或详细说明的内容？
管理需求级别（和其他项目工件）之间的关系是通过一个名为可追溯性的系统来完成的。可追溯性是需求或其他项目工件之间的映射，它在两个或多个项目之间提供可导航的关系。例如，高级软件需求可以追溯到一个或多个低级需求。如果这种映射显示了较高级别项目的分解和详细说明（且没有新行为），则无需进行额外的安全分析。如果较低级别的项目无法直接追溯到较高级别的项目，则可能存在此较低级别的项目引入了意外功能。在这种情况下，较低级别（未映射）的项目应进行安全评估。
可追溯性提供了一种从最高级别的需求开始，通过每个抽象级别跟踪到最低级别的映射的方法。从最低级别的软件需求开始，可追溯性继续到软件设计工件、源代码、验证方法和数据以及其他相关工件。您应该能够从系统级需求开始，然后依次跟踪每个相关需求，通过可追溯性映射一直到相关的代码和验证数据。
评审和独立性
每个需求和其他项目工件都必须经过评审，并且评审应基于项目计划文件中确定的标准。此外，根据软件级别定义确定的软件临界性，特定工件的评审可能需要具有独立性，DO-178B 将其定义为“职责分离，以确保完成客观评估。对于软件验证过程活动，当验证活动由项目被验证项目的开发者以外的人员执行时，并且可以使用工具来实现与人工验证活动等效的结果时，即可实现独立性。对于软件质量保证过程，独立性还包括确保采取纠正措施的权力。”
DO-178B 指南未指定必须如何执行评审。一些组织召开有多个（或许多）评审员的会议，收集会议记录，并以小组的名义签署评审意见。任何目睹或参与过小组评审的人都可能会证明，此类评审的有效性高度依赖于进行评审的人员的敏锐度和组织评审的文化。简而言之，这里的危险在于，如果每个人都负责，那么就等于没有人负责。
提供软件验证服务的公司 Verocel 采取了不同的方法来组织评审。它不是为给定的评审分配工程师小组，而是分配一名工程师，该工程师对工件及其评审的完整性和正确性负全部责任。分配的工程师向小组的其他成员甚至工件的发起人寻求帮助以回答问题、提供进一步的分析或见解或获得澄清的情况并不少见。但是，最终，只有一个签名出现在评审清单上，并且工件及其评审的质量责任由签署人承担。
工件组织和可追溯性的机制
项目工件的组织以及它们之间的可追溯性存在实际考虑因素。通常，项目有数百甚至数千个需求。应如何管理这些项目？如何维护它们之间的可追溯性？同样，DO-178B 提供了一组目标，但没有说明应如何实现这些目标。由开发团队在项目计划文件中提供如何实现每个目标的详细信息，包括工件组织和可追溯性。开发团队和认证机构（或其代表）必须就这些计划达成一致。
有几种商业产品可用于需求管理。一些组织使用文字处理器和电子表格（以及一些特定程序）来满足这些目标。Verocel 发现所有这些方法都不尽如人意，并开发了自己的需求和工件管理系统，该系统以关系数据库作为其后备存储。该系统名为 VeroTrace，直接管理需求文本，并保存对其他工件的引用，例如设计组件、源文件、测试程序和测试结果，这些工件在 CM（配置管理）系统中维护。VeroTrace 实现了可导航的可追溯性目标。再次强调，DO-178B 对这些事项没有规定性。可以想象，仅使用一叠纸质索引卡就可以创建一个有效的组织和可追溯性系统。实际上，大型软件开发项目需要某种类型的自动化来管理项目工件、它们的评审状态以及它们相关的可追溯性。
良好的需求
DO-178B 对良好需求的目标与以下方面有关：(a) 符合系统需求，(b) 准确性和一致性，(c) 与目标计算机的兼容性，(d) 可验证性，(e) 符合标准，(f) 可追溯性，以及 (g) 算法方面。DO-178B 提供了关于这些主题中每一个的具体细节。“符合标准”的目标表明存在需要符合的标准。实际上，项目计划文件很可能包含需求、设计组件、编码标准、测试开发标准以及软件开发其他方面的标准和开发指南。记录这些指南和标准为 SQA 提供了一种评估适用流程是否得到遵循以及在未遵循时要求采取纠正措施的方法。
需求开发标准包含其他标准。例如，需求应具有唯一的标识符，以便可以在其评审中以及通过可追溯性被其他需求或工件明确地引用。需求应具有某种版本标识符，以便可以识别更改并评估受影响的关系。必须识别需求作者，否则 无法保证评审的独立性。出于同样的原因，需求的评审必须识别评审员。DO-178B 目标通常会产生一组必须满足的次要的隐含活动和目标，以实现原始目标。
这听起来可能工作量过大，而且正确地完成这项工作确实是一项大量的工作。该系统的目的是提供一套可靠的需求，这些需求在相同抽象级别（必要时）和抽象级别之间具有可追溯性，以确保没有意外功能。只有这样，您才能开始断言软件是安全的。
瀑布模型
一种通常称为“瀑布模型”的软件开发过程通常遵循以下步骤：识别所有需求，完成架构和设计文档，然后编写代码。实际上，任何具有相当规模的系统都无法以这种方式构建。DO-178B 中的指南承认了这一点，并在第 3 节中指出：“本文档的指南不规定首选的软件生命周期，而是描述构成大多数生命周期的单独流程以及它们之间的交互。流程的分离并不意味着暗示执行流程的组织的结构。对于每个软件产品，都构建了包含这些流程的软件生命周期。”此外，DO-178B 第 12.1.4d 节指出，“反向工程可用于重新生成软件生命周期数据，这些数据不足或缺失，无法满足本文档的目标。”简而言之，重要的是满足 DO-178B 规定的所有目标，但目标的满足顺序不受限制。
也就是说，FAA 对反向工程的实践存在某些担忧，并委托 George Romanski（Verocel 公司）和 Mike DeWalt（当时的 Certification Services Inc.）研究该问题。（DeWalt 后来回到 FAA 担任飞机计算机软件首席科学和技术顾问。）研究《反向工程软件和数字系统》确定，接受调查的人中有 68% 在某个项目中使用过某种反向工程。该报告揭示了许多其他有趣的事实，但对于本次讨论而言，最重要的是软件开发过程不必是“瀑布模型”才能成功。2
验证和确认
确认：“我们是否在构建正确的产品？”验证：“我们是否在正确地构建产品？”5 FAA 委托进行反向工程研究的原因很明显，即担心反向工程工作可能只是重述代码正在做什么，而不是确定代码应该做什么。确认——确定我们是否在构建正确的产品——仍然是安全过程的重要组成部分，并且没有实现此目标的捷径。
反向工程研究使用了 Verocel 提供的来自 13 个项目的数据，总计 250,000 e-LOC（有效代码行数）。（例如，对于 C 程序，e-LOC 排除空行、注释行以及仅包含单个括号、else 或其他关键字的行。）这些项目中报告的问题被分配到以下类别：设计错误、注释错误、文档错误、错误处理问题、测试错误、结构覆盖问题、修改的功能、需求错误和代码错误。还包括关于如何发现这些问题的详细信息：评审、分析（用于反向工程工件的手动检查）、观察（与正在处理的特定工件无关的手动检查）、beta 测试/功能测试、结构覆盖分析或系统测试。
在发现的所有问题中，77% 是由工程师使用工程判断发现的，其中包括 54% 通过分析发现，8% 通过观察发现，15% 通过评审发现。也就是说，软件四分之三的问题是由工程师努力确定软件是否正在执行其应该执行的操作而发现的。只有在一组经过成功确认工作的项目工件上才能进行成功的验证工作。
软件验证
软件验证可以通过几种方法或组合方法来完成。最常见的方法是通过测试。基于需求的测试使用一组需求作为测试标准的基础，并生成结论性报告，说明被测软件是否满足这些需求。
第二种常见的验证方法是分析。某些需求很难或不可能通过测试来验证。例如，如果需求要求在特定操作期间锁定中断并形成临界区，则可能无法从外部检测到中断锁定。在这种情况下，应生成一份简短的分析文档，以提供证据证明满足了此需求。
测试和分析绝不是唯一可用的验证选项。例如，形式化方法可用于证明算法的正确性或对软件需求的忠实性。对于小型系统（例如压力传感器），可以使用穷尽输入测试来完全覆盖软件的输入空间。甚至产品服务历史记录也可以在某些有限的情况下使用。
结构覆盖率分析
DO-178B 对 SCA（结构覆盖率分析）的说法如下：“此分析的目标是确定需求驱动的测试程序未执行哪些代码结构。结构覆盖率分析可以在源代码上执行，除非软件级别为 A 且编译器生成的对象代码无法直接追溯到源代码语句。然后，应在对象代码上执行额外的验证，以确定此类生成的代码序列的正确性。编译器生成的对象代码中的数组边界检查是无法直接追溯到源代码的对象代码示例。”
SCA 背后的思想很简单：如果测试完成且软件完全满足需求，那么人们会期望在测试期间执行 100% 的代码。但是，存在一些原因可能导致这种情况并非如此。例如，软件中的稳健性检查可能具有不可达的执行路径，因为在正常测试条件下不可能创建它们所防范的异常。
SCA 中的差距也可能表明其他问题：基于需求的测试用例或程序中的缺点、软件需求中的不足或死代码，即无法追溯到任何需求的代码。应从系统中删除死代码，或者如果该功能对于软件是必要的，则应更新需求。
停用代码在飞行期间不打算执行。它具有相应的需求，并且应该存在于软件中。（也许此代码仅用于地面维护活动。）有必要证明停用代码不会在不打算运行该代码的模式下被意外执行。
除了显示被测软件中源代码或对象代码覆盖率的活动外，还必须执行进一步的分析，以确认代码组件之间的数据耦合和控制耦合。编译器的输出不可信。测试和结构覆盖率分析用于确认源代码和对象代码已完全覆盖，并且任何差异都已得到补救或记录。同样，链接器（或任何其他引用修复机制）也不可信。必须证明耦合和修复是正确的。SCA 数据以及控制耦合数据是可评审的工件。
图 1 显示了从 HLR（高级需求）到 SCA 报告及其评审清单的可追溯性网络。虚线表示可追溯性。请注意，此图仅是代表性的（并非完整）。例如，未显示用于分析验证的文档。即便如此，这仍然很好地概述了典型的可追溯性网络。
开发和验证工具
如前所述，编译器和链接器都不可完全信任。这些被认为是开发工具，因为它们创建了会飞行的工件。可以创建合格的开发工具，其输出无需检查。创建此类工具（及其验证）的指南与创建和验证飞行软件的指南相同。但是，有时，创建全套验证工件的巨大负担是值得的。合格的开发工具的输出无需进行进一步的验证工作。
对于创建合格的验证工具，要求的工作量较小。此类工具可以代替人工评审员来评审目标工件。合格的验证工具仅需要 DO-178B 概述的需求、基于需求的测试和适当的文档。例如，Verocel 有一个名为 VerOLink 的合格验证工具，可帮助进行控制耦合分析。
DER 的角色
在美国，认证机构是 FAA，但 FAA 不会为每个开发飞机软件的项目提供工程资源。相反，已经开发了一个 DER（指定工程代表）系统，该系统允许 FAA 将项目监督责任委托给经过专门培训且获得适当认证的工程师，这些工程师在行业内工作，既可以为独立公司工作，也可以为制造商自己工作。FAA 始终对项目进行最终签批，但 DER 完成了大部分工作，跟踪项目的进展并评估项目产生的材料。
分配给项目的 DER 将在项目的各个阶段举行一系列四次 SOI（参与阶段）会议。第一次会议 SOI-1 涵盖认证计划并审查关键材料，以确保项目顺利进行。这包括验证成功认证工作所需的流程和程序是否到位，是否存在一个良好且可靠的计划来满足每个已识别的 DO-178B 目标，以及 DER 和软件开发人员之间是否就项目的所有重要方面达成良好协议。第一次会议的目的是确保认证计划到位，并且每个人都同意，如果遵循该计划并生成工件，则应该不会有任何阻碍实现认证的因素。
第二次会议 SOI-2 审查第一次会议中的任何未决问题，评估计划的任何变更的影响，并探讨项目迄今为止开发的材料的质量。成功进行 SOI-2 的最低项目状态是 50% 的需求已开发和评审，50% 的设计工件已完成和评审，50% 的源代码已完成和评审，以及所有这些工件之间的可追溯性。本次会议的目的不是评估或评审已完成的需求集或其他工件，而是尽早识别流程中的任何问题，以便可以在更改成本相对较低且干扰最小的情况下采取纠正措施。为此类会议准备的材料量可能多于或少于此处确定的 50%，因为它完全由 DER 和开发团队之间设定目标和里程碑。
第三次会议 SOI-3 在开发完成且验证工作完成大约 50% 时举行。验证可以通过任何数量的机制完成，包括测试、分析、形式化方法或项目认证方面计划中描述和批准的任何其他方法。
最后一次会议 SOI-4 在为已完成的项目生成所有认证证据后举行，并且评审主要是评估软件包是否已准备好进行最终认证评估。
DER 处于对抗性角色。他或她也能够成为一种资产，协助项目团队识别其计划中的缺陷、流程中的缺陷，甚至作为促进者，通过提出团队尚未识别的建议或确定选项来帮助项目摆脱困境。不应将 DER 置于制定流程计划的位置；DER 的工作是评估而不是开发他或她稍后将评估的材料。优秀的 DER 非常严格，并有助于确保项目生成高完整性的软件。
总结
DO-178B 不是规定性的，但它在其标准和目标方面是全面的。并非 DO-178B 要求的所有内容都可以在一篇相对较短的文章中概括出来，但我们重点介绍了 DO-178B 如何提供指导来帮助生成安全软件的主要要点。必须开发良好的需求，并经过审查以确保它们与软件应该执行的操作的意图相符。这些需求和所有软件开发工件（包括设计、代码、测试、测试结果和结构覆盖率数据）都通过可导航的可追溯性网络连接，这有助于确保软件满足每个需求，并且没有意外功能。另一方面，结构覆盖率分析识别出未被基于需求的测试覆盖的代码，并且死代码（与任何需求无关的代码）可以被标记为删除。
所有这些都以可靠且有据可查的工程实践和成熟的软件开发环境为背景呈现。通过适当的程序和控制，有可能创建可以信任其安全性和他人安全的软件。
参考文献
1. 联邦航空管理局。1998。系统设计和分析，咨询通告 AC 25.1309-1A（6 月 21 日）。
2. 联邦航空管理局。2011。反向工程软件和数字系统，2011 年 4 月 [报告草案]。将由 FAA William J. Hughes 技术中心发布。
3. Humphrey, W. S. 1990。管理软件过程。SEI 软件工程系列。雷丁，马萨诸塞州：Addison-Wesley Publishing Company。
4. Leveson, N. 1995。Safeware: System Safety and Computers。Addison-Wesley Publishing Company。
5. Rakitin, S. R. 2001。从业人员和管理人员的软件验证和确认，第二版。诺伍德，马萨诸塞州：Artech House。
6. RTCA。1992。机载系统和设备认证中的软件考虑因素 (DO-178B)。
喜欢它，讨厌它？请告诉我们
B. Scott Andersen 是 Verocel 公司的高级软件工程师。他在软件行业拥有 30 多年的经验，涉及大面积微影、大容量网站开发、虚拟专用网络等多个领域，最近他是 Sun Microsystems 的 Jini 开发团队的成员，帮助构建 Java 的分布式计算模型。他是一位狂热的小联盟棒球迷（Lowell Spinners），并且可以发现他在业余无线电世界中涉足（呼号 NE1RD）。他拥有南伊利诺伊大学卡本代尔分校计算机科学学士学位。
George Romanski 是 Verocel 公司的联合创始人兼总裁。在过去的 40 年里，他一直专注于软件开发环境的生产。他的工作重点是编译器、交叉编译器、运行时系统以及用于嵌入式实时应用程序的工具。他曾担任 EDS/Scicon 的技术副总裁、Alsys 的工程副总裁以及 Aonix 的安全攸关软件主管。自 1992 年以来，他一直专注于安全攸关应用程序的软件。1999 年，他与人共同创立了 Verocel，这是一家专门从事安全攸关软件认证的公司。
© 2011 1542-7730/11/0800 $10.00
最初发表于 Queue vol. 9, no. 8—
在 数字图书馆 中评论本文
更多相关文章
Sanjay Sha - 企业应用程序的可靠性
企业可靠性是一门学科，它确保应用程序以一致、可预测且经济高效的方式交付所需的业务功能，而不会损害可用性、性能和可维护性等核心方面。本文介绍了一组企业可以应用的核心原则和工程方法，以帮助他们驾驭复杂的企业可靠性环境，并交付高度可靠且经济高效的应用程序。
Robert Guo - MongoDB 的 JavaScript Fuzzer
随着 MongoDB 随着时间的推移变得更加功能丰富和复杂，开发更复杂的方法来查找错误的需求也在增长。三年前，MongDB 在其工具包中添加了一个自制的 JavaScript fuzzer，现在它是我们最多产的错误查找工具，负责在两个发布周期内检测到近 200 个错误。这些错误涵盖了从分片到存储引擎的各种 MongoDB 组件，症状范围从死锁到数据不一致。fuzzer 作为 CI（持续集成）系统的一部分运行，它经常在新提交的代码中捕获错误。
Robert V. Binder, Bruno Legeard, Anne Kramer - 基于模型的测试：它处于什么位置？
您可能听说过 MBT（基于模型的测试），但像许多未使用 MBT 的软件工程专业人员一样，您可能对其他人使用此测试设计方法的经验感到好奇。从 2014 年 6 月中旬到 2014 年 8 月初，我们进行了一项调查，以了解 MBT 用户如何看待其效率和有效性。2014 年 MBT 用户调查是 2012 年类似调查的后续调查，向所有评估或使用过任何 MBT 方法的人开放。它的 32 个问题包括 2013 年高级自动化测试用户大会上分发的一项调查中的一些问题。一些问题侧重于 MBT 的效率和有效性，提供了管理者最感兴趣的数据。
Terry Coatta, Michael Donat, Jafar Husain - EA 的自动化 QA 测试：事件驱动
对于数百万游戏爱好者来说，在 Electronic Arts 担任 QA（质量保证）测试员的职位似乎是一个梦想的工作。但从公司的角度来看，与 QA 相关的开销可能看起来非常可怕，尤其是在大型多人游戏时代。
© 保留所有权利。