如何将 Simulink 用于 ISO 26262 项目

研究传统汽车和自动驾驶汽车安全相关嵌入式系统的汽车工程师们正在寻求高效的方法，以实现 ISO^® 26262 [1] 标准规定的严苛流程。此标准是一项针对道路车辆开发的功能安全标准。

随着自动驾驶汽车成为众多媒体关注的焦点，与之相关的建议层出不穷。然而，这些建议往往侧重于最新的编码方法或 Bug 清除工具。行业专家很早便认识到，保障安全不止于软件及编码方式 [2]，更在于正确地实现系统和满足需求。

使用 Simulink^® 进行基于模型的设计，以连续时间和离散时间仿真为基础，让您在进入试验场测试或执行车队测试之前，预先在各种驾驶条件和故障场景下设计和测试您的整个系统。它还支持 ISO 26262 规定的流程活动，包括工具鉴定。IEC Certification Kit 详细说明了这种支持，并提供了来自国际认证机构 TÜV 南德的工具证书和报告。

本文介绍经 TÜV 南德认证的使用 Simulink 开展 ISO 26262 项目的工作流。它首先介绍 ISO 26262 和基于模型的设计，然后介绍以下活动：

• 需求开发
• 设计建模
• 设计验证
• 代码生成
• 代码验证
• 工具鉴定

ISO 26262 和基于模型的设计

ISO 26262 包含手动设计与代码以及基于模型的设计方面的指导原则。特别是，其中还列出基于模型的设计的 5 个不同用例 [3]：

• 规范化软件安全需求
• 开发软件架构设计
• 在使用或不使用代码生成的情况下设计和实现软件单元
• 设计、实现和集成软件组件，包括从软件组件模型生成代码
• 静态和/或动态验证

它还确认了使用基于模型的设计的一些好处 [3]：

除了使用 MBD 的具体原因（例如仿真或代码生成）之外，明确定义的语法和语义也是实现模型所述信息或工作产品的可理解性、明确性、正确性、一致性和可验证性等标准的基础，尤其在多方合作时更是如此。

该标准提及图形化建模，并指出建模工具采用半形式化方法进行软件开发。它还指出，建模不仅可以获得要实现的功能（嵌入式软件），而且还能仿真实际的物理系统（车辆模型和环境模型），以生成完整的系统模型：

模型以及建模和编码规范，可用于从更高的抽象层面设计、实现和集成软件。

此外，

模型还可以用来实现或支持验证活动（例如，通过仿真在测设备的环境对闭环控制进行硬件在环测试时需要用到被控对象模型）。将模型用于验证目的可以尽早高效检测工作产品（包括软件）中的错误/故障，更高效地生成测试用例，执行高度自动化的测试，甚至是实现形式化验证方法

图 1 显示一个典型的 Simulink 闭环系统模型。该模型由控制器、被控对象以及信号处理器组成。在 ISO 26262 标准中，系统要求和架构设计规范构成了软件开发的输入，但其意义远不止于此，因为从根本上来说安全是系统问题 [2]。

分配给软件的系统架构元素通常要经过精心设计，才能构成细节丰富的软件蓝图，以供您生成产品级代码。ISO 26262 将此模型的详细设计过程描述为“模型细化”[2]：

模型本身可能包含各种分层细化级别或对较低层级细化模型的引用（例如，每个模型元素的具有黑盒和白盒视图的层次结构）。

ISO 26262 根据汽车安全完整性等级 (ASIL) 为各种活动提供了推荐的方法。您可以此标准为指导基于用例建立合适的工作流。图 2 概述了 ISO 26262 流程。实线箭头表示开发活动，而虚线箭头表示验证和确认活动。

需求开发

在与安全相关的开发流程中，首当其冲的是编写功能和安全需求。ISO 26262 建议您利用“软件架构设计与软件安全需求之间的双向可追溯性”验证软件架构设计。为此，您可以使用 Requirements Toolbox™ 来编写需求，并将其追溯至模型、测试和代码。Requirements Toolbox 支持与其他工具进行的双向追溯，这些工具包括 Microsoft^® Word^®、Microsoft Excel^®，以及 IBM^® Rational^® DOORS^®。此外，您还可以使用 Simulink 和 Requirements Toolbox 来创建明确的形式化需求设定。需求的实现和验证状态可在 Requirements Toolbox 中进行监控和管理。需求链接可以显示在生成的代码中（图 3）。

设计建模

您可以将基于模型的设计与 Simulink 和 System Composer 结合使用，以详细说明您的软件架构设计。其中既包括静态方面（即具有模块层次与接口信息的结构），也包括动态方面（即涉及函数、逻辑、数据与控制流的行为）。

使用 Simulink，您还可以从高级可执行规范到准备用于产品级代码生成的详细设计，全面细化软件单元和组件的功能模型。典型的细化包括：

• 使用 Simulink Control Design™ 离散化工具将模块从连续时间（S 域）转换为离散时间（Z 域）
• 使用 Fixed-Point Designer™ 将数据从双精度转换为单精度或定点
• 使用 Stateflow^® 添加诊断、模式逻辑、状态机和调度

对于 ASIL A 到 D，ISO 26262 强烈推荐使用建模规范。为此，您可以使用 MAB 指导规范 [4] 和 Simulink 中提供的 ISO 26262 高完整性规范。Simulink Check™ 会自动检查是否符合这两种规范。它可以在编辑时标记问题，例如插入不符合要求的模块。您还可以包含自己的规范和检查，这些规范和检查也可以配置为编辑时检查。

设计验证

ISO 26262 推荐了多种静态和动态方法，用于验证软件设计和实现，包括单元级和集成级活动。对于基于模型的设计，它声明“测试对象可以是从该模型派生的代码和/或模型本身，具体情况视软件开发流程而定”。

Simulink Test™ 提供了在 Simulink 中执行 ISO 26262 验证和确认活动所用的框架。您可以使用它为模型以及从模型生成的代码编写、管理和执行基于仿真的系统化测试。图 4 显示 Test Sequence 模块和 Test Assessment 模块的示例。

IEC Certification Kit (for ISO 26262) 中的 TÜV 南德报告阐明了 Simulink Test 在自动执行验证和确认中所起的作用：

[Simulink Test] 可用于对 Simulink 模型和生成的代码自动执行核心验证和确认活动。以下用例反映了根据功能安全标准 ISO 26262 在软件开发流程中需要执行的活动：

• 开发并执行 Simulink 模型测试
• 开发并执行测试，以验证模型与代码之间的等效性（背靠背测试）
• 评估测试结果
• 生成测试报告
• 确定需求与测试用例之间的可追溯性

ISO 26262 建议进行结构化覆盖率分析，以确定测试的完整性并识别非预期的功能。其中列出了三种提高严格性的方法。对于 ASIL-D，强烈建议使用后两种方法。

• 语句覆盖率
• 分支覆盖率
• MC/DC（修正条件/决策覆盖率）

该标准指出，对于基于模型的设计，“可以在模型级别使用类似结构化覆盖率度量方法，对模型执行结构化覆盖率分析”。它还指出，如果结构化覆盖率不足，则“应指定额外的测试用例或应提供合理性说明”。

Simulink Coverage™ 为模型和生成的代码提供了结构化覆盖率分析，并且很容易在使用 Simulink Test 执行的测试中启用。如果您的模型覆盖率不足，您可以使用 Simulink Design Verifier™ 自动生成额外的测试用例，以达到要求的覆盖率，包括 MC/DC。Simulink Check 包括模型测试控制板，用于根据 ISO 26262-6:2018 的第 9.4.3 条和第 9.4.5 条（图 5），评估基于需求的测试用例和结果的完整性和质量指标。

IEC Certification Kit 为 Simulink Check、Simulink Coverage（包括模型和代码覆盖率）、Simulink Design Verifier 与 Simulink Test 提供了工具鉴定支持，以及 TÜV 南德证书和报告。

代码生成

ISO 26262 指出，“软件单元的实现包括生成源代码和转换为目标代码”。为此，您可以使用 Embedded Coder^® 从 Simulink 和 System Composer 模型生成 C、C++ 和 AUTOSAR 代码。代码可以遵循 MISRA C^®:2012 自动代码规范 [5]。ISO 26262 还指出，基于模型的设计和手写代码的代码规范可以不同，并以 MISRA^® 为例进行说明。

IEC Certification Kit 为适用于 C、C++ 和 AUTOSAR 的 Embedded Coder（包括 ASIL A 到 D）提供了工具鉴定支持。其 TÜV 南德认证报告指出：

Embedded Coder 满足 ISO 26262 的工具支持和自动化相关要求。

Embedded Coder 通常应用于以下三种用例之一：

1. 为用于产品级代码生成的模型生成 C 代码
2. 为用于产品级代码生成的模型生成 C++ 代码
3. 从用于产品级代码生成的模型为 AUTOSAR 应用软件组件生成 C/C++ 代码和文件

Embedded Coder 提供了针对内存和速度优化代码的选项。此外，您还可以实现特定于处理器的优化，这些优化利用了适用于 ARM^® 和 Intel^® 的 SIMD^® 等硬件加速器。通过使用 ISO 26262 中所述的模型到代码、处理器在环 (PIL) 测试，您可以验证优化后的代码在预设的容差范围内是否与仿真结果匹配。

可执行目标代码是使用编译器和链接器从生成的源代码中产生的。IEC Certification Kit 中的工作流支持对代码生成器、编译器和处理器进行优化。只要使用 PIL 测试来验证可执行目标代码，这种优化就对大规模生产 ECU 来说至关重要。

代码验证

ISO 26262 提供了多个用于验证软件设计和实现的选项。使用基于模型的设计，您可以在软件在环 (SIL) 测试期间使用 Simulink Coverage 对模型覆盖率和代码覆盖率进行比较，也可以直接使用 Simulink Code Inspector™。

最后，您可以使用 Polyspace Bug Finder™ 检查是否符合 MISRA 要求。如果您的项目既有自动生成代码的软件，也有手动编码的软件，则使用 MISRA 检查和代码覆盖率分析非常有用。如果要求更加严格，您可以使用 Polyspace Code Prover™ 证明不存在运行时错误，例如除以零。

IEC Certification Kit 为 Polyspace^® 产品提供了工具鉴定支持，以及 TÜV 南德证书和报告。

在编译和生成了可执行代码后，您可以使用 PIL 测试对目标处理器上执行的代码重用模型测试（图 6）。

ISO 26262 强烈建议对 ASIL C 和 D 进行背靠背测试。它指出在有代表性的目标硬件环境中进行测试的重要性，并强调了解测试环境与硬件环境之间的差异的必要性：

测试环境与目标环境之间的差异可能出现在源代码或目标代码中。其中一个例子就是由于处理器数据和地址的字长不同所导致的差异。

但是，正如每位计算机科学家都应了解的那样 [6]，不同平台之间存在着诸多的潜在数值差异来源，对于浮点数据尤为如此。某些数值误差起初很小，随后逐渐累积和增大，这种情况在反馈控制系统中特别明显。因此，ISO 26262 列出了各种用于背靠背测试的在环方法：

软件单元测试可以在不同环境中执行，例如：

- 模型在环测试；
- 软件在环测试；
- 处理器在环测试；以及
- 硬件在环测试。

Simulink Test 可自动执行在环测试，包括使用 Embedded Coder 的 SIL 和 PIL 以及使用 Simulink Real-Time™ 的 HIL，并提供通过/失败报告，其中包含来自 Simulink Coverage 的覆盖率度量。

工具鉴定

ISO 26262-8 说明了其他支持过程，包括更改控制、配置管理和文档。这些过程分别由 Simulink 工程、Simulink 模型差异识别与合并以及 Simulink Report Generator™ 提供支持。

该标准还提供了工具分类和鉴定指导。它要求用户针对其特定项目进行工具鉴定。IEC Certification Kit 提供了典型用例、参考工作流、工具分类分析、软件工具文档、工具鉴定计划和验证测试，有助于对工具进行有效的预鉴定。如果您的项目涉及受支持的用例并需要遵循参考工作流，您可以通过修改认证套件的模板文档，并在开发环境中执行验证测试，以生成必需的工具鉴定交付物。

TÜV 南德负责审查并审核 MathWorks^® 工具开发和质量流程，以及 Bug 报告功能和工具预鉴定交付物，并在每次产品发布时对结果进行认证。IEC Certification Kit 包括 TÜV 南德提供的证书和报告。若要获得这些证书和报告，需要遵循适当的验证和确认工作流。该套件提供了基于典型工具用例的参考工作流，例如本文中强调的参考工作流。

此外，该套件还提供了更详细的信息，包括 ISO 26262 目标与 Simulink 支持功能的对应关系（图 7）。

ISO 26262:2018 确认，Simulink 和 Stateflow 适用于软件架构和软件单元设计表示法，可作为自动代码生成的基础（图 8）。

请注意，使用经鉴定的工具并不能确保相关软件或系统的安全性。