ISO 26262标准及如何使用一般工具来帮助进行认证

汽车越来越依赖电子产品，制造商也越来越多地转向电子产品和软件方面的创新，以赋予他们竞争优势。一辆现代豪华汽车可能有多达 100 个不同的嵌入式处理器，运行超过 1 亿行代码。有了这么多的软件，基本上不可能把它弄好。如今，据估计 60-70% 的汽车召回涉及软件。

汽车系统中软件缺陷的风险很高，因为软件控制着车辆的许多安全关键方面，包括油门、变速箱和制动器。因此，安全关键型汽车软件的开发需要严格的标准和缜密的方法。

2011 年，ISO 26262 作为开发安全关键型汽车电子系统的国际标准发布，其在全球范围内的使用正在增加。它基于更通用的 IEC 61508 安全标准，但引入了针对汽车的改进。本文试图总结标准中对嵌入式软件开发人员最重要的一些关键方面。它首先简要介绍了 ISO 26262，并描述了如何使用一般工具来帮助进行认证。接下来描述了工具如何获得用于认证的资格。上一节讨论的关键要点是，该标准的大部分内容都涉及健壮的软件开发，并且如果使用得当，

ISO 26262

本文档使用术语 ISO 26262 或“标准”来表示 ISO 26262 中涉及软件的部分；特别是 ISO 26262-6:2011 道路车辆 — 功能安全 — 第 6 部分：软件级别的产品开发。

ISO 26262 是一个基于风险的标准。虽然它承认不可能将风险降至零，但它要求对风险进行定性评估，并采取措施将风险降至“合理可行的最低水平”（ALARP）。

ISO 26262 中使用的词汇涉及故障、错误和故障，其中“故障可以表现为错误……而错误最终会导致故障”。要理解的最重要的术语是“汽车安全完整性等级”或 ASIL。ASIL 是对电子元件风险的分类。D 级代表风险最高的部件，A 级代表最低风险（当风险被认为低于 ASIL A 时，使用附加标签 QM）。该级别是通过遵循适用于危害的评估过程来分配的。每个潜在危险事件都按其可能造成的伤害严重程度进行分类，其中 SIL0 表示没有伤害，而 SIL3 表示对生命的威胁。评估中的其他重要因素是暴露，范围从 E0（极低概率）到 E4（非常可能），

ASIL 是通过综合考虑这些因素来确定的。很明显，在严重性、暴露性和可控性方面得分较高的危险将被指定为 ASIL D。但是，如果发生概率非常低，则可以将严重性较高的危险指定为 ASIL A。

一旦 ASIL 被确定为危险，它就会被减轻危险的安全目标和由此产生的安全要求继承。然后 ASIL 规定了软件的最低测试要求。

使用工具帮助认证

ISO 26262 明确承认软件验证工具对于满足测试要求至关重要。因此，该标准要求此类工具本身是合格的。需要注意的重要一点是，使用的工具本身可能不完善，这些不完善可能会破坏整个系统的安全案例，因此该标准要求评估工具置信度 （TCL）。这是通过评估两件事来确定的：

如果测试工具失败，则无法满足测试要求的可能性，以及

用户可以检测到工具故障的概率

该值的范围可以从 TCL1（最低置信度）到 TCL3（最高置信度）。两个因素用于确定 TCL：工具影响 （TI） 和工具错误检测 （TD）。

工具影响用于描述工具中潜在故障的后果。TI1 用于有争议的工具本身故障 a） 不能导致系统故障，并且 b） 不能防止故障被检测到。否则使用 TI2。

TD 是对工具报告故障的能力的置信度评估，其中 TD1 表示最低置信度，TD3 表示最高置信度。

一旦评估了工具置信度和错误检测，就可以根据表 1 中的信息确定 TCL。

例如，考虑一个虚构的动态分析工具 Cov，它可用于测量通过在给定测试套件上运行软件实现的代码覆盖率。假设 ASIL 为 D（风险最高），相应的安全要求是测试套件必须达到 100% 的分支覆盖率。

Cov 的工具影响显然是 TI2，因为如果它未能正确报告覆盖率指标，则可能无法满足代码覆盖率要求。

判断工具错误检测可能很棘手。假设 Cov 有一个缺点，它有时无法检测代码的某些部分，因此无法测量这些部分的代码覆盖率，并且在这种情况下它没有发出警报，而是简单地从其报告中省略了该信息。没有经验的工具用户可能不会注意到遗漏，因此可能会无意中错过覆盖目标。在这种情况下，工具可能会被判断为 TD2。

因此，参考表 1，Cov 的 TCL 将为 TCL2。

工具资质

ISO 26262 规定具有 TCL1 的工具不需要进一步鉴定，但 TCL2 和 TCL3 都要求必须使用至少一种工具鉴定方法，才能正确声称该工具合格。四种资格认证方法是：

使用信心增加，这意味着该工具已成功用于类似项目的跟踪记录。

对工具开发过程的评价，意味着工具开发者一直小心翼翼地遵循一个高质量的软件开发过程。

软件工具的验证，意味着该工具已经过严格的验证协议。

按照安全标准进行开发，即在开发过程中遵循严格的开发标准（如 ISO 26262 本身）。

对于较高的 ASIL 级别，强烈推荐后两种方法，因为它们产生高置信度。

工具鉴定并非微不足道，而且通常超出了大多数嵌入式软件项目本身的范围。幸运的是，大多数关心 ISO 26262 的工具供应商已经完成了获得认证的工作。最好的情况是供应商已经获得了专门从事该领域的独立机构的资格。独立认证意味着供应商已成功满足相当苛刻的要求，不仅让工具用户对其质量充满信心，而且为这些用户节省了大量的认证工作。

当然，要获得给定嵌入式系统的 ISO 26262 认证，开发人员必须自己制作案例，因此他们必须收集所有相关材料，包括所有工具资格。大多数供应商将提供一个“认证工具包”，其中包含该材料的易于使用的形式。

静态分析工具和 ISO 26262

ISO 26262 不要求使用任何特定类别的工具；相反，它指定了代码应该具有的属性，但通常只列出可用于提供证据证明代码确实具有这些属性的方法。在许多情况下，工具的使用实际上是强制性的（例如，如果不使用现代工具，基本上不可能收集准确的代码覆盖率指标）。在其他情况下，可能不清楚是否有可用的工具可以提供帮助。

与静态分析工具最相关的标准部分是第 8 节：软件单元设计和实现。静态分析工具最明显的应用之一是验证软件是否符合第 5.4.7 节规定和第 8.4.3.d 节要求的编码标准。汽车领域最好的例子当然是 MISRA C。自从早期版本首次发明以来，发现此类违规一直是静态分析工具的优势。

最新一代的静态分析工具仍然能够发现违反编码标准的情况，但它们还具有更多功能。它们的主要目的是发现严重的编程错误，例如那些可能导致程序崩溃或陷入未定义行为的错误。这些工具的设计足够灵活，可以使用它们来满足 ISO 26262 的其他一些要求。

最相关的部分之一是 8.4.4，其中列出了“在源代码级别进行软件单元设计和实现的设计原则……”以实现包括正确执行顺序、健壮性甚至代码可读性在内的属性。第 8.4.5 节继续列出应该用于验证软件是否符合要求的技术。列出的技术之一是静态代码分析。

ISO 26262 在几个方面引用了“稳健性”的概念。在软件单元设计和实现的上下文中，鲁棒性被认为包括防止“不可信的值、执行错误、被零除以及数据流和控制流中的错误”（8.4.4）。软件单元测试 （9.4.2） 和软件集成与测试 （10.4.3） 的稳健性特征包括“不存在无法访问的软件、有效的错误检测和处理”。

总结稳健性要求的一种合理方式是，应尽量减少可预防的严重软件缺陷的数量。这正是高级静态分析工具的最大优势。

粗略地说，这些工具从解析代码开始，然后创建整个程序的高保真模型。发现缺陷的分析通过以各种方式遍历模型寻找异常来进行。最复杂的算法通过探索代码路径来模拟程序的执行，但它们不是使用具体值来表示执行状态，而是使用一组抽象方程来模拟程序属性。

这些工具最重要的特性是，它们可以探索比最复杂的测试方案所能探索的更多的执行路径。即使代码已经过严格的覆盖要求测试，例如完整的 MCDC（ISO 26262 规定的最严苛的要求），也不能保证完全的路径覆盖。原则上，高级静态分析工具可以保证 100% 的路径覆盖（尽管在实践中，通常会做出牺牲以实现合理的可扩展性和精度）。因此，他们能够并且确实发现了传统测试遗漏的缺陷。此外，它们可以在开发周期的早期应用，甚至在编写单元测试之前。众所周知，越早发现bug，修复越便宜，

结论

任何安全关键编码标准（尤其是 ISO 26262）的动机都是为了将​​软件故障对 ALARP 的风险降低到尽可能低的程度。这意味着不仅要遵守标准的最低要求，还要应用最佳实践技术来实现高质量。先进的静态分析工具的特性使其不仅在遵守法律条文方面非常宝贵，而且对于保持其精神 - 开发健壮和可靠的软件。

审核编辑：郭婷