现代汽车中的驾驶辅助系统越来越多地提高了便利性和安全性。其中许多系统降低了人为失误的可能性，而人为失误仍然是事故的主要原因1。最近，自动驾驶汽车在大多数情况下甚至可以在没有任何直接人为控制的情况下运行。这样，防止事故的大部分责任就从驾驶员转移到汽车上，从而转移到制造商及其供应商身上。这意味着汽车的功能安全变得比以往任何时候都更加重要。因此，汽车的所有安全关键系统都需要根据 ISO 26262进行开发，该标准定义了开发过程的强制性要求。本文解释了需求可追溯性如何帮助成功且可持续地满足这些要求。
因汽车系统故障（而非人为失误）而引发的车祸可能会给汽车制造商带来非常严重的后果。品牌乃至整个公司的公众形象可能会受损，并对未来的销售产生不利影响。
此外，如果事故可以通过采用竞争对手使用的“常用”技术来避免，制造商可能要承担法律责任。这包括不是由制造商自己生产的系统，而是由其供应商生产的系统。
因此，汽车制造商必须要求其供应商采用最先进的方法来确保所购买系统的安全。他们通过审计来检查是否满足这一要求，即在会议期间，供应商必须说服汽车制造商，他们采取了必要的措施来保证其产品的安全。
什么是 ISO 26262？
ISO 26262 提供了一个框架和共识，用于建立和评估制造商开发技术所遵循的开发流程和方法。
需要评估汽车制造商需要做什么以及他们反过来需要从供应商那里得到什么。不同的标准提供了这样的共同基础。与汽车功能安全最相关的标准是 ISO 26262。
ISO 26262 标准建议在汽车系统开发过程中从硬件、软件和整个系统三个层面采取具体措施。当然，除了遵守标准之外，新技术可能会出现，并且这些技术的应用在一段时间后可能会成为强制性要求。ISO 26262 最初于 2011 年发布，但已于 2018 年 12 月更新，以适应最新的技术水平。
ISO 26262 要求对整个汽车的功能安全有一个总体概念，该概念必须通过由组件组成的系统架构来实现。在开发特定组件时需要采取哪些安全措施，取决于该组件的正确行为对汽车安全的重要性。
根据严重事故风险，必须为每个组件分配一个ASIL（汽车安全完整性等级）。最高 ASIL D 等级的组件的不正确行为很可能导致危及生命甚至致命的伤害，并且驾驶员无法控制局面。
如果系统发生故障导致的伤害程度较低、发生的可能性较小或驾驶员更容易控制，则系统会获得较低的 ASIL 等级。最低 ASIL 等级为 A。风险更低的系统不被视为安全关键系统，无需满足常规质量保证以外的任何特殊要求。
为什么满足 ISO 26262 会很困难？
“满足” ISO 26262 标准要求供应商说服审核员，每个组件都具有正确的 ASIL，并且至少考虑了该 ASIL 的所有“强烈推荐”点。当可以令人信服地证明某些建议“强烈推荐”的东西实际上没有必要时，就会有一定的灵活性，因为已经实施了更好的替代方案，或者因为该建议不适用于特定情况。
在成功完成审核后，审核员必须得出这样的结论：整个开发过程确保所有安全目标都能实现。供应商需要提供证据证明他们的开发过程确实保证了这一点。不幸的是，当所涉及的组件非常复杂时，这可能成为一项非常具有挑战性的任务——这种情况变得越来越常见。
开发组件的公司会生产工件（称为“工作产品”），例如需求文档、源代码或测试文档。ISO 26262 中包含的建议定义了必须生产的工件、需要对其执行的操作以及这些工件最终必须具备的属性。通常，这些建议同时涉及多个工件及其相互关系。
下图显示了 Enterprise Architect 模型 (RainSensing) 中一些关系的小示例，该模型用于实现雨量传感器的控制软件。一方面，它与它实现的软件要求 (SW-R 4.2.1.1) 相关。另一方面，它还与建模功能的相应测试以及在较低级别实现该模型的 Simulink 模型 (RainSensor) 相关。
请注意，该示例仅显示了与 RainSensing 工件直接相关的其他工件之间的关系。当然，这些其他工件反过来又与其他工件有关系，这些工件可能与 RainSensing 间接相关。
管理复杂性
许多现代汽车系统的大部分行为都是由软件定义的，因此，开发过程中的软件开发部分往往会产生大量的工件。软件使定义极其复杂的行为变得容易。然而，确保这种行为确实正确却不那么容易。
复杂性越高，系统可能的状态就越多。系统需要在所有情况下都正确运行，这意味着需要指定更多情况下的正确系统行为，即需要定义更多要求。必须实施和测试这些要求，由于复杂性增加，这将进一步增加满足 ISO 26262 所需的工件数量。
为了管理这种复杂性，组件通常会按层次细分为较低级别的较小组件，这些组件仅实现部分功能。这样，开发人员就可以集中精力解决更容易理解的较小局部问题。这是必要的，因为开发人员一次只能处理这么多信息，当他们必须考虑比他们实际能够处理的信息更多时，往往会犯错误。
因此，即使对于 ASIL A，也“强烈建议”采用软件组件的分层结构。不幸的是，在验证是否符合 ISO 26262 时，每个组件的层次细分都会增加相关的开发工件总数。
为什么可追溯性对于满足 ISO 26262 是必要的？
通常，大量的开发工件并不是最大的问题，因为它们之间的关系数量通常要大得多。组件的开发人员需要跟踪其实现的哪些部分实现了给定的安全要求，以及哪些测试用例（或其他措施）验证了这些实现确实有效。
为了实现更高抽象层次的要求，可能需要通过更技术细节的下级要求来细化这些要求。在由此产生的层次结构中，同一层次和不同层次上的需求之间的关系对于理解系统及其安全性的保障方式至关重要。因此，ISO 26262明确指出，需要确保这些开发工件之间的需求可追溯性。
需求可追溯性意味着开发人员能够将需求追溯到所需的其他开发工件，以确保这些需求确实得到满足。如上一节所述，这些开发工件通常包括其他需求、实施单元、描述验证措施及其结果的工件等。
为了保证可追溯性，必须以某种方式记录这些工件之间的相关关系。这些记录的关系称为“踪迹链接”，如果上下文清晰，则简称为“链接”或“踪迹”。
下图显示了与某一特定利益相关者需求（SH-R 2.1.1）相关的开发工件之间的一些可能的跟踪链接的示例。实际图表大约是这个的三倍。即使只有少数这些顶级需求，对这些链接的手动分析也将变得极具挑战性。
在 ISO 26262 没有明确要求的情况下，确保可追溯性也非常有用，因为您可能必须证明您满足了其他隐含需要可追溯性的建议。例如，如果您无法在审核实施的某个部分时生成正式的实施规范，那么正式的实施规范将无济于事。仅存在建议的工件是不够的，您还必须能够找到它们。
您还可以使用跟踪链接对您的系统执行不同类型的分析：
- 您可以通过检查工件之间是否存在这些规则所要求或禁止的关系来验证指南和建模规则是否得到正确应用。
- 由于需求和实现通常在多个抽象级别上定义，因此您还需要确保这些不同级别彼此一致。例如，较低级别上的子组件之间的相互依赖关系意味着此类相互依赖关系也必须存在于较高级别上。
- 在软件中实现行为的一个主要原因是，即使在汽车制造完成后很长时间，也很容易应用更改。影响分析可以提前显示软件更改会产生哪些影响，这样就可以快速识别和解决这些更改可能造成的安全违规行为。
在以下几种情况下，基于跟踪链接的覆盖率分析可以表明符合 ISO 26262 标准的建议：
- 可以计算源代码的测试覆盖率，以代替计算需求的测试覆盖率，或者作为计算需求的测试覆盖率的补充。
- 可以针对不同类型的测试来测量覆盖率，例如，稳健性测试与资源使用情况测试。
- 您可以通过设计规范检查软件架构和软件单元的覆盖范围。
- 与需求无关的软件单元可能会带来未指定的功能，这对于安全关键型系统来说非常成问题。
此外，您可以将可追溯性信息与其他技术结合使用，以提高其有效性。假设您使用基于需求的测试。那么您必须确保所有需求都以某种方式直接或间接地被测试覆盖。测试对需求的高覆盖率可以成为您软件质量的有力论据。
要计算需求的覆盖率，您需要表示需求层次结构的跟踪链接以及定义哪些需求被测试用例直接覆盖的跟踪链接。在此基础上，您可以计算哪些需求被间接覆盖。您可能希望以某种方式自动执行此步骤。
可追溯性的用处不仅限于审计。跟踪链接本质上是一种文档，它使工件之间的关系信息明确化。开发人员不了解工件之间的隐含关系很容易导致安全违规。
此类违规行为并不局限于编程错误：在 ISO 26262 中，组件之间的相互依赖性（“干扰”）意味着所有组件都需要根据其中任何组件的最高 ASIL 进行开发。忽略此类相互依赖性会使任何实现安全性的努力的有效性受到质疑。当组件在稍后的时间点被更改（可能是由其他开发人员更改）时，尤其可能发生此类错误。
我们如何实现可追溯性？
只需将一个工件的全局唯一标识符 (GUID) 与另一个工件一起存储或作为另一个工件的一部分存储，即可记录跟踪。例如，C 函数源代码中或上方的注释可能包含对测试文档特定部分的引用，这些部分描述了实现此函数时需要考虑的要求。
但是，在这种情况下，可追溯性只能是单向的。也就是说，当给定 C 函数时，我们可以轻松找到描述需求的文本，但反之则不然。对于双向可追溯性，我们还需要在需求文本中唯一地引用 C 函数。但是，如果将双向链接实现为两个单向链接，它们可能会因后续更改而变得不一致。
当以上述方式存储链接时，很难获得有关哪些类型的工件之间存在哪些链接的总体概述。但是，这可能是必要的，例如，确定测试对需求或源代码的覆盖范围。由于良好的测试覆盖率可以作为高质量软件的指标，因此此类信息在审计中非常有用。
或者，链接可以单独存储在其自己的文件中或作为数据库记录。这使得更容易获得概览并确保一致性。然而，另一方面，当处理单个工件时，与其他工件的链接存在哪些不太明显。因此，开发人员可能会忽略这些链接所代表的关系。此外，（隐式）现有关系的缺失链接可能会被忽视。两者都可能导致基于不完整信息的错误决策。
我们如何才能减少维护可追溯性的努力？
典型项目中的跟踪链接数量庞大，如果没有任何自动化，几乎不可能处理可追溯性。当试图理解可用信息时，这已经是一个问题，但在试图保持其最新和一致时，这更是一个问题。
理想情况下，链接应自动创建和更新，或尽量减少人工干预。要真正利用可追溯性，您需要能够对数据执行不同类型的分析（如上一节所述），而这些分析很少能够手动完成。幸运的是，存在一些支持这些用例的工具，但肯定还有改进的空间，许多项目需要定制解决方案或对现有解决方案进行调整。
