ISO 26262-6:2018

七月 07, 2025

第 6 部分：软件级别的产品开发

道路车辆 — 功能安全

1 范围

本文件旨在适用于包含一个或多个电气和/或电子 (E/E) 系统的与安全相关的系统，这些系统被安装在已量产的道路车辆（不包括轻便摩托车）上。本文件不适用于特殊车辆中特有的 E/E 系统，例如为残障驾驶员设计的 E/E 系统。

注意：

存在其他特定于应用的安全标准，其可以作为对 ISO 26262 系列标准的补充，反之亦然。

已量产的系统及其组件，或在本文件的发布日期之前被开发的系统及其组件，不适用于本文件。对于已量产的系统及其组件，或在本文件的发布日期之前被开发的系统及其组件，本文件将制定不同的安全生命周期以使其在后续的升级换代中符合本文件的要求。通过制定安全生命周期，本文件解决了对未按照本文件开发的现有系统与按照本文件开发的系统的集成的问题。

本文件探讨了与安全相关的电子电气系统的故障行为可能造成的危险，其中包括这些系统之间的相互作用。本文件不涵盖与电击、火灾、烟雾、高温、辐射、毒性、易燃性、反应性、腐蚀、能量释放及类似危险相关的危险，除非这些危险直接由与安全相关的电子电气系统的故障行为引起。

本文件描述了一个功能安全框架，用于辅助对与安全相关的电子电气系统的开发。该框架旨在将功能安全集成到不同的开发框架中。有些要求具有明确的与实施相关的技术关注点，另一些则涉及开发流程，因此可被视为开发流程规范。

本文档不涉及 E/E 系统的标称性能。

本文件规定了汽车应用软件层面的产品开发要求，其中包括以下内容：

软件级别的产品开发的一般主题

软件安全需求规范

软件架构设计

软件单元的设计与实现

软件单元的验证

软件的集成与验证

嵌入式软件的测试

它还指定了与对配置软件的使用相关的要求。

附件 A 概述了本文件的目标、先决条件和结果。

2 规范性引用

下列文件在本文中被引用，其部分或全部内容构成本文件的要求。凡是注日期的引用文件，仅其版本适用。凡是不注日期的引用文件，其最新版本（包括所有的修改）适用于本文件。

ISO 26262-1, Road Vehicles — Functional Safety

Part 1: Vocabulary

ISO 26262-2:2018, Road Vehicles — Functional Safety

Part 2: Management of functional safety

ISO 26262-3:2018, Road vehicles — Functional Safety

Part 3: Concept phase

ISO 26262-4:2018, Road vehicles — Functional Safety

Part 4: Product development at the system level

ISO 26262-5:2018, Road vehicles — Functional Safety

Part 5: Product development at the hardware level

ISO 26262-7:2018, Road vehicles — Functional Safety

Part 7: Production, operation, service and decommissioning

ISO 26262-8:2018, Road vehicles — Functional Safety

Part 8: Supporting processes

ISO 26262-9:2018, Road vehicles — Functional Safety

Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses

3 术语和定义

就本文件而言，以下术语和定义适用于本文件。

ISO 和 IEC 在以下地址维护用于标准化的术语数据库：

IEC Electropedia: available at http://www.electropedia.org/

ISO Online browsing platform: available at http://www.iso.org/obp

4 规范需求

4.1 目的

本条款描述了如何：

a) 实现 ISO 26262 系列标准

b) 理解 ISO 26262 系列标准中被使用的表格

c) 根据相关的 ASIL（Automotive Safety Integrity Levels，汽车安全完整性级别）来解释每个条款的适用性

4.2 一般要求

当声称符合 ISO 26262 系列标准时，必须满足标准中的每一项要求，除非出现以下情况：

a) 已根据 ISO 26262-2 对安全措施进行制定，这表明要求不适用于此行为

b) 存在可被接受的不符合要求的理由，并已根据 ISO 26262-2 对此理由进行了评估

信息内容（包括注释和示例）仅被用于帮助理解或澄清相关要求，而不应被解释为要求本身。

安全措施的作用以结果的形式被呈现。“先决条件”是指前一个阶段应提供的信息。鉴于条款中的某些要求与 ASIL 相关或可能需要被特别地制定，此信息可能无需作为先决条件。

“进一步的支持信息”是可被放在考虑范围内的信息，但在某些情况下，ISO 26262 系列标准并不要求将前一阶段的结果作为此信息，并且可能将由负责功能安全措施的人员或组织以外的来源提供的内容作为此信息。

4.3 对表格的解释

根据其上下文，表格可被分为规范性表格和信息性表格。表格中列出的不同方法有助于实现相应的要求。表格中的每种方法都具有以下特征：

a) 连续的条目（用最左侧的序列号标记，例如 1、2、3）

b) 备选条目（用最左侧的数字和字母标记，例如 2a、2b、2c）

对于连续的条目，其适用于所有符合 ASIL 的被强烈推荐或被推荐的方法。允许使用表中未被列出的其他方法替代被强烈推荐或被推荐的方法，在这种情况下，应提供理由说明这些方法为何符合相应的要求。如果已为其中一个条目提供了符合相应要求的理由，则无需为其余的条目提供说明。

对于备选的条目，应根据所示的 ASIL 应用适当的方法组合，无论这些方法是否被列于表中。如果被列出的方法的对于 ASIL 的被推荐等级不同，则应优先选择对于 ASIL 的被推荐等级较高的方法。当选择不同的方法组合或选择其中一种方法时，应提供符合相应要求的理由。

注意：

基于表中被列出的方法的理由对于说明而言是充足的，但这并不代表表中未被列出的方法不合适。

对于每种方法，对于 ASIL 的被推荐等级的分类如下：

“++”表示该方法对于已被识别的 ASIL 而言是被强烈推荐的

“+”表示该方法对于已被识别的 ASIL 而言是被推荐的

“o”表示该方法对于已被识别的 ASIL 而言是不被推荐的

4.4 与 ASIL 相关的要求和建议

除非另有说明，否则应满足 ASIL A、B、C 和 D 的各个子条款中的要求或建议。这些要求和建议对应于安全目标的 ASIL。如果在开发早期阶段已按照 ISO 26262-9:2018，第 5 条对 ASIL 需求进行了分解，则应满足分解后得到的对 ASIL 的需求。

如果在 ISO 26262 系列标准中的描述中的括号内给出了某个 ASIL，则相应的子条款应被视为对于实现该 ASIL 的建议，而非要求。但与对 ASIL 的分解相关的描述中的括号符号与以上描述无关。

4.5 对于摩托车的适用性

对于适用 ISO 26262-12 要求的摩托车部件或元件，ISO 26262-12 的要求将取代本文件中的对应要求。被 ISO 26262-12 取代的 ISO 26262-2 的要求将在第 12 条中被定义。

4.6 对于卡车、巴士、拖车和半挂车的适用性

针对卡车、巴士、拖车和半挂车 (T&B) 的独有内容将被单独列出。

5 软件级别的产品开发的一般主题

5.1 目标

本阶段的目标是：

a) 确保合适且一致的软件开发流程

b) 确保合适的软件开发环境

5.2 概况

图 2 给出了软件开发的参考阶段模型。对配置软件的处理的详细信息请见附件 C。

注意 1：

敏捷软件开发中的开发方式或方法也适用于与安全相关的软件的开发，但如果以该形式制定安全措施，则应考虑 ISO 26262-2:2018，第 6.4.5 条。然而，敏捷软件开发中的开发方式或方法不可被用于忽略为实现功能安全所需的安全措施以及有关产品严谨性的基本文件、流程或安全完整性。

示例 1：

测试驱动的开发可被用于提高需求的质量和可测试性。

示例 2：

基于自动化构建系统的连续集成可以保证子流程的一致性，并有助于回归测试的进行。此类构建系统通常被用于执行代码的生成、编译和链接、静态代码的分析以及文档的生成、测试和打包。它可以重复地根据工具链以及对工具链的配置生成（修改后）可对比的软件、文档和测试结果的产物。

注意 2：

在开发特定项目的嵌入式软件时，也可以考虑网络安全，参见 ISO 26262-2:2018，第 5.4.2.3 条。为了能够开发软件，本条款讨论了涉及到的建模方法、设计和/或编程语言，以及应用指南和工具。

注意 3：

被用于软件开发的工具可以包括软件工具以外的工具。

示例 3：

在测试阶段使用的工具。

5.3 本条款中的输入项

5.3.1 先决条件

应提供以下信息：

5.3.2 进一步的支持信息

应考虑以下信息：

可用的已被认证的软件工具（参见 ISO 26262-8:2018，第 11 条）

在建模中使用的设计和编码规范，设计以及编程语言（来自外部源）

方法应用指南（来自外部源）

工具应用指南（来自外部源）

5.4 需求和建议

5.4.1 在开发某一产品的软件时，应采用以下软件开发流程和软件开发环境：

a) 适用于开发与安全相关的嵌入式软件，包括方法、指南、编程语言和工具

b) 支持在“软件开发生命周期中的各个子阶段”和“相应产物”之间保持一致性

c) 兼容系统和硬件开发阶段所需的交互和信息交换的一致性

注意 1：

对某项产品的软件的开发阶段、任务和活动（包括迭代步骤）进行排序，旨在确保相应产物在硬件级别的产品开发（参见 ISO 26262-5）和系统级别的产品开发（参见 ISO 26262-4）中的一致性。

注意 2：

软件工具标准评估报告（参见 ISO 26262-8:2018，第 11.5.1 条）或软件工具认证报告（参见 ISO 26262-8:2018，第 11.5.2 条）可以为工具的使用提供输入。

5.4.2 在选择设计、建模或编程语言时应考虑的标准是：

a) 定义应为明确易懂

示例：对语法和语义的明确定义或对开发环境的配置的限制。

b) 如果建模被用于对需求的设计和管理，则应根据 ISO 26262-8:2018，第 6 条来指定和管理安全需求

c) 实现对模块化、抽象化和封装化的支持

d) 对使用结构化设计的支持

注意：

在软件中，汇编语言可被用于不适合高级编程语言的部分，例如与硬件接口交互的底层软件、中断处理程序或时间关键型算法。然而，使用汇编语言可能需要适当地应用或制定所有软件开发阶段（例如第 8 条的要求）。

5.4.3 对于合适的建模、设计或编程语言的标准（见第 5.4.2 条），如果语言本身没有对此进行充分地定义，则应由相应的指南或开发环境来指定，同时应考虑在表 1 中被列出的主题。

示例 1：

MISRA C（参见参考文献 [3]）是编程语言 C 的编码指南，其中包括对自动生成代码的指导。

示例 2：

对于基于模型的开发并自动生成代码的情况，指南既可被应用于模型层面，也可被应用于代码层面。可以考虑参考合适的建模风格指南，例如 MISRA AC 系列。商业工具的风格指南也可以作为参考。

注意：

可以针对特定项目的开发对现有的编码指南和建模指南进行修改。

5.5 产物

5.5.1 根据第 5.4.1 条至第 5.4.3 条和第 C.4.1 条至第 C.4.11 条的要求对软件开发环境的文档进行归档。

6 软件安全需求规范

6.1 目标

本阶段的目标是：

a) 制定或细化源自技术安全概念和系统架构设计规范的软件安全需求

b) 定义实现过程所需的软件的与安全相关的功能和属性

c) 细化 ISO 26262-4:2018，第 6 条中的软硬件接口的需求

d) 验证软件安全需求和软硬件接口需求适用于软件开发，并兼容技术安全概念和系统架构设计规范

6.2 概况

在 ISO 26262-4:2018，第 6 条规定的系统架构设计阶段，技术安全需求会被细化并被分配给硬件和软件。软件安全需求规范尤其考虑了在硬件中存在的约束以及这些约束对软件造成的影响。子流程包括软件安全需求规范，以支持后续阶段的设计。

6.3 本条款中的输入项

6.3.1 先决条件

应提供以下信息：

符合 ISO 26262-4:2018，第 6.5.1 条规定的技术安全需求规范

符合 ISO 26262-4:2018，第 6.5.2 条规定的技术安全概念

符合 ISO 26262-4:2018，第 6.5.3 条规定的系统架构设计规范

符合 ISO 26262-4:2018，第 6.5.4 条规定的软硬件接口 (HSI) 规范

按照第 5.5.1 条对软件开发环境的文档进行归档后的资料

6.3.2 进一步的支持信息

应考虑以下信息：

硬件设计规范（参见 ISO 26262-5:2018，第 7.5.1 条）

软件中的非安全相关的功能和属性的规范（来自外部源）

6.4 需求和建议

6.4.1 软件安全需求应考虑软件所需的与安全相关的功能和属性，其故障可能导致被分配给软件的技术安全需求失效。

注意 1：

软件安全需求要么直接来自被分配给软件的技术安全需求，要么是对软件的功能和属性的需求（如果不满足该需求，可能会导致被分配给软件的技术安全需求失效）。

示例 1：

软件中与安全相关的功能可以是：

保证“正常功能被安全地执行”的功能

使系统“达到或维持某个安全状态或（功能）降级状态”的功能

与“对与安全相关的硬件元件的故障的检测、指示和缓解”相关的功能

与“对 OS（操作系统）、BSW（基础软件）或 APL（应用软件）自身的故障的检测、指示和缓解”相关的自检或监控功能

与“在生产、运行、服务和退役期间的板载和非板载测试”相关的功能

允许“在生产和服务期间对软件进行修改”的功能

与“性能或时间关键型操作”相关的功能

示例 2：

与安全相关的属性包括对于错误输入的鲁棒性、不同功能之间的独立性或不受干扰性，或软件的容错能力。

注意 2：

面向安全的分析（见第 7.4.10 条或第 7.4.11 条）可被用于识别额外的软件安全需求或提供证明这些需求已被实现的证据。

6.4.2 根据 ISO 26262-4:2018，第 6.4.1 条和第 6.4.3 条，从技术安全需求、技术安全概念和系统架构设计中得出的软件安全需求规范应考虑：

a) 符合 ISO 26262-8:2018，第 6 条规定的规范和对安全需求的管理

b) 对系统和硬件的配置

示例 1：配置参数可包括增益控制、带通频率和时钟预分频器。

c) 软硬件接口规范

d) 硬件设计规范的相关要求

e) 时间限制

示例 2：通过系统级别的响应时间得出的执行时间或反应时间。

f) 外部接口

示例 3：通信和用户接口。

g) 在车辆、系统或硬件中的每种操作模式以及操作模式之间的转换对软件产生影响

示例 4：操作模式包括关机或休眠、初始化、正常运行、测试或对闪存进行烧写时的（功能）降级模式或高级模式。

6.4.3 如果需要将对 ASIL 的需求分解应用于软件安全需求，则应遵守 ISO 26262-9:2018，第 5 条。

6.4.4 应充分细化 ISO 26262-4:2018，第 6 条中的软硬件接口规范，以允许软件正确地控制和使用硬件，并应描述每个与安全相关的软硬件之间的依赖关系。

6.4.5 如果嵌入式软件执行了除在第 6.4.1 条中规定的与安全需求相关的功能之外的其他功能，则应根据当前的质量管理体系提供关于这些功能及其属性的规范。

6.4.6 被细化后的软硬件接口的规范需要由系统、硬件和软件开发负责人共同地验证。

6.4.7 应按照 ISO 26262-8:2018，第 6 条和第 9 条对软件安全需求和软硬件接口规范的细化需求进行验证，验证时应提供以下内容：

a) 兼容软件的开发

b) 符合技术安全需求

c) 符合系统设计

d) 符合软硬件接口

6.5 产物

6.5.1 软件安全需求规范的范围为第 6.4.1 条至第 6.4.3 条以及第 6.4.5 条。

6.5.2 由第 6.4.4 条得出的软硬件接口（HSI）规范（已细化）。

注意：

该产物对应于 ISO 26262-5:2018, 第 6.5.2 条的产物。

6.5.3 根据第 6.4.6 条和第 6.4.7 条输出的软件验证报告。

7 软件架构设计

7.1 目标

本阶段的目标是：

a) 制定满足软件安全需求和其他软件需求的软件架构设计

b) 验证软件架构设计是否满足与目标 ASIL 对应的软件安全需求；

c) 对软件实现和软件验证的支持

7.2 概况

软件架构设计以层次结构的形式展现了软件架构的元素及元素之间的交互。设计中描述了软件组件之间的接口等静态层面，以及流程顺序和时序行为等动态层面。

注意：

软件架构设计不一定局限于一个微控制器或 ECU。本条款还讨论了每个微控制器的软件架构。

软件架构设计能够同时满足软件安全需求以及其他软件需求。因此，在此阶段中，与安全相关或非相关的软件需求将在同一个开发流程中被处理。

软件架构设计提供了实现软件需求和与目标 ASIL 对应的软件安全需求的方法，并管理了细节设计的复杂性和软件的具体实现方式。

7.3 本条款中的输入项

7.3.1 先决条件

应提供以下信息：

按照第 5.5.1 条对软件开发环境的文档进行归档后的资料

由第 6.5.2 条得出的软硬件接口（HSI）规范（已细化）

由第 6.5.1 条得出的软件安全需求规范

7.3.2 进一步的支持信息

应考虑以下信息：

符合 ISO 26262-4:2018，第 6.5.2 条规定的技术安全概念

符合 ISO 26262-4:2018，第 6.5.3 条规定的系统架构设计规范

符合 ISO 26262-8:2018，第 12 条规定的被认证的软件组件的可用性

符合第 6.4.5 条规定的软件的与安全非相关的功能和属性的规范以及其他软件需求（来自外部源）

7.4 需求和建议

7.4.1 为了避免在软件架构设计和后续开发中出现系统性错误，对软件架构设计的描述应符合在表 2 中被列出的特征：

a) 可理解性

b) 一致性

c) 简易

d) 可验证性

e) 模块化

f) 抽象化

注意：可以通过使用层次结构、分组表格或视图来对抽象化进行支持，以涵盖软件架构设计中的静态、动态以及部署方面的内容。

g) 封装

h) 可维护性

7.4.2 在软件架构设计的开发过程中，应考虑以下几点：

a) 软件架构设计的可验证性

注意：这意味着软件架构设计和软件安全需求之间的双向可追溯性。

b) 对可配置软件的兼容性

c) 软件单元设计和实现的可行性

d) 软件集成测试期间软件架构的可测试性

e) 软件架构设计的可维护性

7.4.3 为了避免系统性错误，软件架构设计应遵循在表 3 中被列出的原则，体现为以下几点：

a) 可理解性

b) 一致性

c) 简易

d) 可验证性

e) 模块化

f) 封装

g) 可维护性

注意 1：

由于在表 3 中被列出的原则互相并不排斥，因此有必要在这些原则之间选择适当的折衷方案。

注意 2：

高复杂性的指标可以是：

高度的分支控制或数据流

分配给单个设计元素的需求过多

单个设计元素的接口数量过多或设计元素之间的交互过多

复杂的类型或过多的参数

过多的全局变量

难以保证适当及完整地对错误进行检测和处理

难以达到目标的测试覆盖率

只有少数专家或项目参与者才能理解

注意 3：

这些属性和原则也适用于软件例程（例如中断服务例程）。

7.4.4 软件架构设计应深入到可识别软件单元的层次。

7.4.5 软件架构设计应描述：

a) 软件架构元素的静态设计层面

注意 1：静态设计层面应解决：

软件结构（包括其中的层次结构）

数据类型及其特性

软件组件的外部接口

嵌入式软件的外部接口

全局变量

约束（包括架构的范围和对外部的依赖）

注意 2：在基于模型的开发中，结构建模可以是整体建模过程的固有组成部分。建模的结构可能取决于所选的建模语言。

b) 软件架构元素的动态设计层面

注意 3：动态设计层面应解决：

事件和行为的功能链

数据处理的逻辑顺序

控制流以及进程的并发性

流经接口的数据流和全局变量

时间限制

注意 4：

为了确定动态行为（例如任务、时间片和中断），需要考虑不同的运行状态的情况（例如上电、下电、正常运行、校定和诊断）。

注意 5：

为了描述动态行为（例如任务、时间片和中断），需要指定通信关系及其中涉及的系统硬件（例如 CPU 和通信通道）。

7.4.6 软件安全需求应以层级结构的形式被划分并被分配（以软件单元为单位）给软件组件。因此，应确保开发的软件组件符合被分配给它的需求所要求的最高 ASIL。

注意：

在设计开发和需求分配的过程中，可能需要根据第 6 条拆分或进一步细化软件安全需求。

7.4.7 如果为了满足被分配给其的安全需求而使用未经修改的预先存在（未按照 ISO 26262 系列标准进行开发）的软件架构元素，则应按照 ISO 26262-8:2018 第 12 条对其进行认证。

注意 1：

使用已被认证的软件组件不会影响对第 10 和 11 条的适用性。无论如何，在第 8 和 9 条中被描述的一些行为可以被省略。

注意 2：

在对软件架构设计的验证过程中，应检查对按照 ISO 26262 系列标准开发的软件架构元素的复用的适用性。

7.4.8 如果嵌入式软件必须实现“不同 ASIL 的”或“与安全相关和非相关的”软件组件，则整个嵌入式软件都应符合软件组件中 ASIL 最高的软件组件的 ASIL，除非软件组件符合与 ISO 26262-9:2018 第 6 条兼容的共存标准。

7.4.9 如果使用软件分区（见附件 D）来实现软件组件彼此之间相互独立，则应确保：

a) 确保对共享资源的使用方式中不存在软件分区的干扰

注意 1：处于同一软件分区中的任务无法排除彼此之间的干扰。

注意 2：一个软件分区（的任务或函数）不能对其他软件分区的代码或数据造成影响，也不能请求其他软件分区的非共享资源。

注意 3：一个软件分区（的任务或函数）对共享资源的访问不能受到其他软件分区的影响。影响的范围包括相关资源的性能，以及对资源的调度式访问的速率、延迟、抖动和持续时间。

b) 对软件分区的支持由特定的硬件功能或等效的方式实现（此需求符合 ASIL D，符合第 4.4 条）

示例：硬件功能，例如内存保护单元（MPU）。

c) 对实现软件分区功能的软件架构元素的开发应符合分区中 ASIL 最高的需求的 ASIL

注意 4：一般来说，操作系统将提供或支持软件分区功能。

d) 应在软件集成和验证阶段对软件分区的有效性进行验证（按照第 10 条的规定）。

7.4.10 应按照 ISO 26262-9:2018 第 8 条在软件架构层面对安全进行分析，以便：

验证提供符合目标 ASIL 的与安全相关的功能和属性的软件的适用性

注意 1：与安全相关的属性包括独立性和抗干扰性。

识别或确认软件与安全相关的部分

符合规范并验证安全措施的有效性

注意 2：安全措施包括源自安全分析的安全机制，并可以涵盖与随机硬件故障以及软件故障相关的问题。

注意 3：有关在软件架构层面应用安全分析的方式以及如何选择适当的安全措施的更多信息，请参阅附件 E。

7.4.11 如果软件安全需求的实施依赖于软件组件的抗干扰性或独立性，则应按照 ISO 26262-9:2018 第 7 条分析相关故障及其影响。

注意：

有关在软件架构层面应用相关故障分析的更多信息，请参阅 ISO 26262-9:2018，附件 C 和附件 E。

7.4.12 应根据符合第 7.4.10 条或第 7.4.11 条的软件架构层面的安全分析的结果，应用有关错误检测和处理的安全机制。

注意 1：

附件 E 提供了关于在故障模式下是否需要安全机制的指导。

注意 2：

有关错误检测的安全机制可以包括：

对于输入和输出数据的范围的检查

对合理性的检查（例如，使用预期行为的参考模型、断言检查或比较来自不同源的信号）

对数据错误的检查（例如，错误检测代码和数据备份）

通过外部元素（例如，ASIC 或执行看门狗功能的其他软件架构元素）对程序的执行情况的监控。监控方式可以是逻辑监控、时间监控，或两者同时进行

对程序的执行时间的监控

在设计中的多样性的冗余

在软硬件中被实现的非法访问控制机制，被用于授予或拒绝对与安全相关的共享资源的访问

注意 3：

有关错误处理的安全机制可以包括：

停用某些功能以达到或维持某个安全状态

静态恢复机制（例如恢复块、向后恢复、向前恢复和通过重复恢复）

（功能）降级应优先为功能考虑，以最大限度地减少潜在故障对功能安全的不利影响

设计中的同质冗余（对同种类型的对象进行冗余处理），其主要目的为对在执行类似处理的硬件中的瞬态故障或随机故障的影响进行控制（例如，软件的“时间冗余”（即对同一函数进行多次执行或对同一数据进行多次传输）执行）

设计中的各种冗余设计意味着，对于单一流程，将存在与其对应的并行流程（其中包含不同的软件），其主要目的为对软件中的系统故障进行预防或控制

对数据进行校正的执行代码

在软硬件中被实现的对访问权限的管理，被用于授予或拒绝对与安全相关的共享资源的访问

注意 4：

可以在系统层面对软件安全机制（包括通用鲁棒性机制）进行审核，以分析其对系统行为的潜在影响以及与技术安全需求的一致性。

7.4.13 应对嵌入式软件所需的资源的上限进行估算，包括：

a) 执行时间

b) 存储空间

示例：被用于堆栈的 RAM，被用于程序和非易失性数据的 ROM。

c) 通信源

7.4.14 应按照 ISO 26262-8:2018 第 9 条的规定，使用在表 4 中被列出的软件架构设计验证方法对软件架构设计进行验证，以验证以下目标是否已被实现：

a) 软件架构设计符合具有目标 ASIL 的软件需求

b) 对软件架构设计的审核提供了证明“软件架构设计符合具有目标 ASIL 的软件需求”的材料

c) 对目标环境（平台）的兼容性

示例：目标环境（平台）是软件的执行环境。除了第 7.4.13 条规定的目标硬件（平台）及其（外设）资源外，还包括操作系统（OS）和基础软件（BSW）。

d) 符合设计指南。

7.5 产物

7.5.1 由第 7.4.1 条至第 7.4.13 条产生的软件架构设计规范。

7.5.2 根据第 7.4.10 条得出的安全分析报告。

7.5.3 根据第 7.4.11 条得出的对相关故障的分析报告。

7.5.4 根据第 7.4.14 条得出的软件验证报告。

8 软件单元的设计与实现

8.1 目标

本阶段的目标是：

a) 根据软件架构设计、设计规范和被分配的软件需求（支持软件单元的实现与验证）对软件单元进行设计

b) 实现软件单元

8.2 概况

在软件架构设计的基础上，对软件单元进行详细设计。

可以以模型的形式表示详细设计。根据软件开发环境，源代码级别的实现可以（根据设计）以手动或自动的方式被生成。

为了设计单个软件单元，需要同时实现软件安全需求和与安全非相关的需求。因此，在此阶段中，与安全相关或非相关的软件需求将在同一个开发流程中被处理。

8.3 本条款中的输入项

8.3.1 先决条件

应提供以下信息：

按照第 5.5.1 条对软件开发环境的文档进行归档后的资料

由第 6.5.2 条得出的软硬件接口（HSI）规范（已细化）

由第 7.5.1 条得出的软件架构设计规范

由第 6.5.1 条得出的软件安全需求规范

由第 C.5.3 条得出的配置数据（如适用）

由第 C.5.4 条得出的标定数据（如适用）

8.3.2 进一步的支持信息

应考虑以下信息：

符合 ISO 26262-4:2018，第 6.5.2 条规定的技术安全概念

符合 ISO 26262-4:2018，第 6.5.3 条规定的系统架构设计规范

软件的与安全非相关的功能和属性的规范（来自外部源）

由第 7.5.2 条得出的安全分析报告

由第 7.5.3 条得出的对相关故障的分析报告

8.4 需求和建议

8.4.1 如果软件单元是与安全相关的（软件架构）元素，则应遵守本子条款的要求。

注意：

“与安全相关”是指该软件单元实现与安全相关的需求，或者未满足（软件架构）元素共存标准（参见 ISO 26262-9:2018，第 6 条）。

8.4.2 软件单元的设计与实施应：

a) 符合被分配给该软件单元的具有目标 ASIL 的软件需求

b) 符合软件架构设计规范

c) 符合软硬件接口（HSI）规范（如适用）

示例：

提供给其他软件单元的接口的一致性和完整性。输入/输出数据的正确性、准确性和及时性。

8.4.3 为了避免系统性故障，并确保软件单元的设计达到以下属性，应使用表 5 所列的符号来描述软件单元的设计。

a) 一致性

b) 可理解性

c) 可维护性

d) 可验证性

注意：

在基于模型的自动生成代码的开发中，软件单元的设计的表示方式应被应用于（作为自动生成代码的基础）模型。

8.4.4 软件单元规范应对功能的行为和内部设计进行（符合实现所需的详细级别）描述。

示例：

内部设计可以包括对寄存器使用和数据存储的限制。

8.4.5 应采用表 6 所列出的软件单元的设计与实现（源代码级别）的设计原则来达到以下属性：

a) 根据软件架构设计，确定软件单元内的子程序和功能的正确执行顺序

b) 软件单元之间的接口的一致性

c) 软件单元之间及软件单元内部的数据流和控制流的正确性；

d) 简易性

e) 可读性和可理解性

f) 鲁棒性

示例：防止不合理值、执行错误、除零错误以及数据流和控制流中的错误的方法。

g) 对软件修改的兼容性

h) 可验证性

注意：

对于 C 语言，MISRA C（参见参考文献 [3]）涵盖了表 6 所列出的许多原则。

8.5 产物

8.5.1 根据第 8.4.2 至 8.4.5 条得出的软件单元设计规范。

注意：

对于基于模型的开发，实现模型和支持描述文档应使用表 5 和表 6 所列出的方法描述软件单元。

8.5.2 根据第 8.4.5 条得出的软件单元的实现。

9 软件单元的验证

9.1 目标

本阶段的目标是：

a) 验证软件单元的设计符合被分配的软件需求并与实现兼容；

b) 验证安全措施（由符合第 7.4.10 和 7.4.11 条的安全分析所定义）是否被合理地实现

c) 验证软件单元的实现符合软件单元的设计并符合被分配给该软件单元的具有目标 ASIL 的软件需求

d) 验证软件单元不包含非目标的与功能安全相关的功能或属性。

9.2 概况

软件单元的设计与实现将通过对验证措施的适当组合进行验证，例如审核、分析和测试。

为了验证单个软件单元的设计，需要同时考虑软件安全需求和与安全非相关的需求。因此，在此阶段中，与安全相关或非相关的软件需求将在同一个开发流程中被处理。

9.3 本条款中的输入项

9.3.1 先决条件

应提供以下信息：

由第 6.5.2 条得出的软硬件接口（HSI）规范（已细化）

由第 7.5.1 条得出的软件架构设计规范

由第 8.5.1 条得出的软件单元设计规范

由第 8.5.2 条得出的软件单元的实现

由第 C.5.3 条得出的配置数据（如适用）

由第 C.5.4 条得出的标定数据（如适用）

由第 7.5.2 条得出的安全分析报告

按照第 5.5.1 条对软件开发环境的文档进行归档后的资料

9.3.2 进一步的支持信息

应考虑以下信息：

9.4 需求和建议

9.4.1 如果软件单元是与安全相关的（软件架构）元素，则应遵守本子条款的要求。

注意 1：

“与安全相关”是指该软件单元实现与安全相关的需求，或者未满足（软件架构）元素共存标准（参见 ISO 26262-9:2018，第 6 条）。

注意 2：

本条款的要求针对与安全相关的软件单元。其他软件标准（参见 ISO 26262-2:2018，第 5.4.5.1 条）可被用于对其他软件单元的验证。

注意 3：

对于基于模型的软件开发，实现模型的相应部分同时也是验证过程中的验证对象。根据所选的软件开发流程，验证对象可以是派生自该模型的代码、模型自身，或者两者之和。

9.4.2 应根据 ISO 26262-8:2018，第 9 条，使用表 7 所列出的方法的适当组合对软件单元的设计与实现进行验证，以验证：

a) 符合第 8 条及关于软件单元的设计与实现的需求

注意 1：软件安全需求包括软件的功能和属性。

注意 2：在模型级别的验证可以替代在源代码级别的验证，前提是在代码生成中保留了属性（例如对所使用的代码生成工具有足够的信心）。

示例：对错误的检测和处理机制（实现软件单元对于错误输入的鲁棒性）的实现的有效性。

b) 源代码符合其设计规范

注意 3：对于基于模型的开发，需求 b) 仍然适用。

c) 符合软硬件接口（HSI）规范（符合第 6.4.4 条）（如适用）

d) 不包含非目标的功能或属性

e) 支持软件单元的功能和属性的足够的资源

f) 符合第 7.4.10 和 7.4.11 条的由安全分析得出的对安全措施的实现

9.4.3 为了满足符合第 9.4.2 条的为软件单元测试准备的适当的测试用例的规范，应使用表 8 所列出的方法编写测试用例。

9.4.4 为了评估验证的完整性并验证单元测试的目标已被充分地实现，应确定其对于软件单元级别的需求的覆盖率，并按照表 9 所列出的指标确定其对于源代码（语句，分支及条件）的覆盖率。如果对于源代码（语句，分支及条件）的覆盖率未满足目标，则应指定额外的测试用例，或提供基于其他方法的理由。

注意 1：

对于源代码（语句，分支及条件）的覆盖率，无目标值或低于目标值（没有合理的说明）将被视为未满足目标。

示例 1：

对于源代码（语句，分支及条件）的覆盖率可以显示基于需求的测试用例中的缺陷、需求的缺陷、非必要的代码、不会被执行的代码或非目标的功能。

示例 2：

对于源代码（语句，分支及条件）的覆盖率，可以基于“可被接受的非必要的代码（例如，被用于调试的代码）”或者“根据不同的软件配置而被启用的代码段”或者“可通过补充方法被验证的代码”进行说明。

示例 3：

应基于（软件单元的）最新的版本进行说明。

注意 2：

可以使用适当的软件工具来确定对于源代码（语句，分支及条件）的覆盖率。

注意 3：

对于基于模型的开发，可以在模型级别通过对模型使用类似的结构覆盖率指标来执行对结构覆盖率的分析。

示例 4：

如果存在说明两者对于源代码（语句，分支及条件）的覆盖率为等效的理由，则可使用在模型级别执行的对结构覆盖率的分析代替对于源代码（语句，分支及条件）的覆盖率的指标。

注意 4：

如果测试代码（打桩）被用于确定对于源代码（语句，分支及条件）的覆盖率，则需要验证测试代码（打桩）不会影响对覆盖率的测试结果。这可以通过重复执行不带有测试代码（打桩）且具有代表性的测试用例的方式来实现。

9.4.5 在考虑目标测试环境（硬件平台）的前提下，软件单元测试的测试环境（硬件平台）应符合单元测试的目标。如果在非目标测试环境（硬件平台）下对软件单元进行测试，则应分析“在目标测试环境（硬件平台）下被用于测试的源代码与在非目标测试环境（硬件平台）下被用于测试的源代码”之间及“目标测试环境（硬件平台）与非目标测试环境（硬件平台）”之间的差异，以便指定需要在后续测试阶段的目标测试环境（硬件平台）中进行的补充测试。

注意 1：

实际测试环境（硬件平台）和目标测试环境（硬件平台）之间的差异（例如，由于处理器的数据字（Data word）和地址字（Address word）的位宽度不同）可能出现在源代码或目标（平台）代码中。

注意 2：

应根据测试范围选择合适的测试环境（例如目标处理器、处理器模拟器或开发系统）。

注意 3：

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

模型在环（MIL）测试

软件在环（SIL）测试

处理器在环（PIL）测试

硬件在环（HIL）测试

注意 4：

对于基于模型的开发，可以在模型级别进行软件单元测试，然后在模型和（生成的）目标代码之间进行背靠背比较测试。背靠背比较测试用于确保模型的与测试目标相关的行为与自动生成的代码等效。

9.5 产物

9.5.1 根据第 9.4.2 至 9.4.5 条得出的软件验证规范。

9.5.2 根据第 9.4.2 条得出的软件验证报告（已细化）。

10 软件的集成与验证

10.1 目标

本阶段的目标是：

a) 定义集成的步骤并对（软件架构）元素进行集成，直到嵌入式软件被完全地集成

b) 验证由软件架构层面的安全分析得出的安全措施是否被正确地实现

c) 验证被集成的软件单元和软件组件符合软件架构设计的需求

d) 验证被集成的软件不包含非目标的与功能安全相关的功能或属性。

10.2 概况

在此子阶段，根据软件架构设计对特定的集成级别以及（软件架构）元素之间的接口进行验证。对（软件架构）元素的集成与验证的步骤与软件的层次架构有关。

嵌入式软件可以包含与安全相关或非相关的（软件架构）元素。

10.3 本条款中的输入项

10.3.1 先决条件

应提供以下信息：

由第 6.5.2 条得出的软硬件接口（HSI）规范（已细化）

由第 7.5.1 条得出的软件架构设计规范

由第 7.5.2 条得出的安全分析报告

由第 7.5.3 条得出的对相关故障的分析报告（如适用）

由第 8.5.2 条得出的软件单元的实现

由第 C.5.3 条得出的配置数据（如适用）

由第 C.5.4 条得出的标定数据（如适用）

按照第 5.5.1 条对软件开发环境的文档进行归档后的资料

由第 9.5.1 条得出的软件验证规范

10.3.2 进一步的支持信息

应考虑以下信息：

符合 ISO 26262-8:2018，第 12 条规定的被认证的软件组件的可用性

10.4 需求和建议

10.4.1 应定义软件的集成的方法，并描述将单个软件单元以分层的形式集成到软件组件中直至嵌入式软件被完全地集成的步骤，并应考虑：

a) 由第 10.4.2 条得出的验证目标之间的依赖关系

b) 与软件的集成相关的在功能层面的依赖关系

c) 软件的集成与软硬件的集成之间的依赖关系

注意：

对于基于模型的开发，可以使用在模型级别的集成以及随后的根据被集成的模型进行的自动代码生成代替软件的集成（参见附件 B）。

10.4.2 根据 ISO 26262-8:2018，第 9 条，应通过对表 10 所列的方法的适当组合对软件的集成进行验证，以验证以分层的形式被集成的软件单元、软件组件以及嵌入式软件：

a) 满足符合第 7 条的软件架构设计

b) 符合由第 6.5.2 条得出的软硬件接口（HSI）规范

c) 指定的功能

d) 指定的属性

示例：可信度来源于排除非法访问的软件以及对于错误的输入的鲁棒性，可靠性来源于有效的对于错误的检测与处理。

e) 对功能进行支持的足够的资源

f) 符合第 7.4.10 和 7.4.11 条的由安全分析得出的安全措施的有效性（如适用）

注意 1：安全措施包括对软件进行分区。

注意 2：

对于基于模型的开发，验证对象可以是与软件组件相关的模型。

10.4.3 对于给定的对于软件的集成的测试方法，为了提供符合第 10.4.2 条的合适的测试用例，应使用表 11 所列出的方法设计测试用例。

10.4.4 为了评估验证的完整性并验证集成测试的测试目标均已被完整地实现，应确定在软件架构级别测试用例对于需求的覆盖率。如有必要，应指定额外的测试用例，或提供基于其他方法的理由。

10.4.5 本子条款适用于 ASIL（A）、（B）、C 和 D，并符合第 4.4 条：为评估测试用例的完整性并验证集成测试的测试目标均已被完整地实现，应按照表 12 所列出的方法评估在结构层面的覆盖率。如果已被实现的在结构层面的覆盖率被评估为不足，则应指定额外的测试用例，或提供基于其他方法的理由。

示例：

在结构层面的覆盖率可以显示基于需求的测试用例中的缺陷、需求的缺陷、非必要的代码、不会被执行的代码或非目标的功能。

注意 1：

可以使用适当的软件工具来确定在结构层面的覆盖率。

注意 2：

对于基于模型的开发，可以在模型级别使用对于模型而言的类似的在结构层面的覆盖率的指标进行对于软件的集成的测试。

10.4.6 应验证作为符合 ISO 26262-2:2018，第 6.4.13 条的生产版本的一部分的嵌入式软件是否包含所有被指定的功能和属性，以及其他未被指定的功能（仅当这些功能不违背软件安全需求）。

示例：

在此上下文中，未被指定的功能包括被用于调试或评估的代码。

注意：

如果确定可以停用这些未被指定的功能，则停用这些功能为符合（可被接受）此需求的行为。否则，停用这些功能将被视为变更（参见 ISO 26262-8:2018，第 8 条）。

10.4.7 在考虑目标测试环境（硬件平台）的前提下，对于软件的集成的测试的测试环境（硬件平台）应符合集成测试的目标。如果在非目标测试环境（硬件平台）下进行对于软件的集成的测试，则应分析“在目标测试环境（硬件平台）下被用于测试的源代码与在非目标测试环境（硬件平台）下被用于测试的源代码”之间及“目标测试环境（硬件平台）与非目标测试环境（硬件平台）”之间的差异，以便指定需要在后续测试阶段的目标测试环境（硬件平台）中进行的补充测试。

注意 1：

注意 2：

应根据测试范围以及集成的层级选择合适的测试环境（例如目标处理器、处理器模拟器或开发系统）。

注意 3：

对于软件的集成的测试可以在不同的测试环境中被执行，例如：

模型在环（MIL）测试

软件在环（SIL）测试

处理器在环（PIL）测试

硬件在环（HIL）测试

10.5 产物

10.5.1 根据第 10.4.2 至 10.4.7 条得出的软件验证规范（已细化）。

10.5.2 根据第 10.4.1 条得出的嵌入式软件。

10.5.3 根据第 10.4.2 条得出的软件验证报告（已细化）。

11 嵌入式软件的测试

11.1 目标

本阶段的目标是：

a) 当嵌入式软件在目标环境（平台）中被执行时符合与安全相关的需求

b) 不包含与功能安全相关的非目标功能或属性

11.2 概况

测试的目的是验证当嵌入式软件在目标环境（平台）中被执行时满足其需求。不同阶段的验证的结果可以作为此验证的输入信息。

注意：

让非软件的实现人员的人员来执行测试是一种很好的做法。

11.3 本条款中的输入项

11.3.1 先决条件

应提供以下信息：

由第 7.5.1 条得出的软件架构设计规范

由第 6.5.1 条得出的软件安全需求规范

由第 10.5.2 条得出的嵌入式软件

由第 C.5.4 条得出的标定数据（如适用）

按照第 5.5.1 条对软件开发环境的文档进行归档后的资料

由第 10.5.1 条得出的软件验证规范（已细化）

11.3.2 进一步的支持信息

应考虑以下信息：

符合 ISO 26262-4:2018，第 6.5.2 条规定的技术安全概念

符合 ISO 26262-4:2018，第 6.5.3 条规定的系统架构设计规范

符合 ISO 26262-4:2018，第 7.5.1 条规定的集成和测试策略

符合 ISO 26262-4:2018，第 7.5.2 条规定的集成和测试报告

11.4 需求和建议

11.4.1 为了验证当嵌入式软件在目标环境（平台）中被执行时符合软件安全需求，应在表 13 所列出的合适的测试环境中进行测试，并符合 ISO 26262-8:2018，第 9 条。

注意：

已经存在的测试用例（例如对于软件的集成的测试）可以被重复地使用。

11.4.2 应采用表 14 所列出的方法对嵌入式软件进行测试，以验证嵌入式软件符合具有目标 ASIL 的软件需求。

11.4.3 对于软件测试，为了提供符合第 11.4.2 条的合适的测试用例，应使用表 15 所列出的方法设计测试用例。

11.4.4 应根据以下方面对嵌入式软件的测试结果进行评估：

a) 符合预期结果

b) 对软件安全需求的覆盖率

注意：对软件安全需求的覆盖率包括对配置信息和标定范围的覆盖率。参见附件 C。

11.5 产物

11.5.1 根据第 11.4.1 至 11.4.3 条得出的软件验证规范（已细化）。

11.5.2 根据第 11.4.1 至 11.4.4 条得出的软件验证报告（已细化）。

附件 A（资料性）

软件级别的产品开发的管理的概述和工作流

表 A.1 概述了软件级别的产品开发的各个阶段的目标、先决条件和产物。

附件 B（资料性）

基于模型的开发方法

B.1 目标

本附件解释了基于模型的开发方法（MBD）在软件级别的开发过程中可能带来的在使用上的优势和潜在的问题。

注意：

本附件并不意味着所提及的基于模型的开发方法仅局限于软件开发。

B.2 概况

本子条款提供了 MBD 的各种用例（例如需求、设计、验证/测试）的通用信息。子条款 B.3 提供了基于示例用例的特定考虑。

B.2.1 介绍

模型可被用于表示开发阶段所需的信息或信息视图，也可被用于对一个或多个软件（架构）元素或软件环境的抽象设计与实现。模型本身可能包含各种以层级的方式被表示的细化级别，或对处于较低层级的已被细化的模型的引用（例如，每个模型元素都包含带有黑盒视图和白盒视图的层次结构）。模型的开发使用建模符号。

建模符号可以是图形和/或文本形式的。它们可以是正式的（例如，具有底层数学定义的符号），也可以是半正式的（例如，语义定义不完整的结构化符号）。建模符号可以遵循国际标准（例如，UML®），也可以遵循公司特定的标准。它们通常基于类、框图、控制图或状态图（表达状态以及状态之间的转换）等概念。在本附件中，仅考虑包含已被定义的符合其预期用途的语法和语义的模型和建模符号（即，不具备此类定义的示意图将不被视为模型）。除了基于特定的原因（例如，模拟或代码生成）使用 MBD 外，为了实现模型所描述的信息或产物的可理解性、无歧义性、正确性、一致性和可验证性等标准，被充分定义的语法和语义是基础，尤其是在不同方需要进行协作的情况下。

除了建模符号本身外，建模指南和/或合适的工具也是实现被充分定义的语法、语义以及对于建模指南的合规性的条件。

示例：

作为指南的一部分，命名约定或（编码）风格指南有助于实现“可理解性”等标准，而选择排除歧义结构的语言子集则有助于实现“可理解性”以及对模型的正确转换和执行。在对模型的模拟或转换的情况下，合适的模拟引擎或代码生成器可以作为对所需语义的补充，例如被确定的执行或转换顺序，以及对所提供的模拟引擎或代码生成器的详细行为的充分解释。

本附件进一步考虑了以下基于模型的开发方法的用例：

软件安全需求规范（第 6 条和 ISO 26262-8:2018，第 6 条）

软件架构设计的开发（第 7 条）

软件单元的设计与实现（无论是否带有自动地代码生成（第 8 条））

软件组件的设计、实现与集成（包括由软件组件模型自动地生成代码（第 8、9 和 10 条））

验证（静态和/或动态）（第 9、10 和 11 条）

B.2.2 一般适用性层面

可以根据以下方面来评估所选的基于模型的开发方法（包括建模技术、符号、语言或工具）是否适合预期的应用：

通过所选的方法实现为相应开发阶段提供的 ISO 26262 系列标准的规范（例如可理解性、一致性、可验证性、明确性、准确性）

对于所选的方法的知识与经验

对语法和语义的定义的充分性

对于应用领域（例如，实时行为、数据结构、对于定点与浮点微控制器的软件的生成）的适用性

模型在软件生命周期中的作用（例如，安全需求的开发、表达架构设计中的静态或动态层面）

通过强制执行抽象、封装、层次结构和模块化的原则来支持对复杂性的管理

内部/外部开发伙伴之间的合作模式（例如在数据交换期间的数据一致性）

软件工具的可信度（参见 ISO 26262-8:2018，第 11 条）

对于作为所选的 MBD 方法的一部分或被包含在 MBD 环境中的软件组件（例如，软件库）的认证（参见 ISO 26262-8:2018，第 12 条）

B.2.3 MBD 对软件生命周期的潜在影响

一个模型可能代表该文档的多个产物（例如，需求、架构设计、详细设计以及基于模型的对软件的集成（带有代码生成））。相比于与生命周期的数据分离的传统形式的开发流程，可能会出现对“软件安全需求”、“软件架构设计”、“软件单元的设计与实现”等阶段的更强的融合。这种方法的潜在优势（例如，可持续性、跨软件生命周期的信息共享、一致性）颇具吸引力，但这种方法也可能会引入导致系统性故障的问题（参见 B.3）。

B.3 对示例软件开发的用例的特定考虑

本节根据示例用例提供与优势以及潜在问题相关的考虑因素。

B.3.1 软件安全需求规范（第 6 条和 ISO 26262-8:2018，第 6 条）

模型可被用于捕获在安全需求层面被实现的软件的功能、行为、设计及属性（例如，开/闭环控制，受控的系统、状态及转换，对功能或独立性进行监控的属性），并通过模拟或标准化方法实现对需求的验证及激活。

模型可以成为实现安全需求的特性的合适方式，同时也是实现 ISO 26262-8:2018，第 6 条规定的对半正式或正式符号进行使用的需求的方式。

示例：

当通过基于模型的方法来指定状态机时，相应的模型会以直观、清晰且易于理解的方式表示所需的状态和（状态间的）转换。对于同一状态机，模型可以比文本规范表示更多的原子需求。其原因为，无重复信息的模型可以更好地实现和维护规范的完整性、可验证性和内部一致性。

然而，需要注意的是，使用模型可能会导致所选的基于模型的开发方法所无法表达的安全需求被遗漏。因此，ISO 26262-8:2018，第 6 条强调了文本需求与其他符号的适当组合。

示例：

与软件功能的鲁棒性相关的需求（防止输入的丢失或错误）。

B.3.2 软件架构设计的开发（第 7 条）

通过模型来表示软件架构时，可以从几个层面出发，特别是：

a) 静态层面（例如，组件，组件的接口及数据流，组件的属性）

b) 动态层面（例如，事件的功能链，调度，消息的传递）

模型与建模指南一起可以成为实现与安全相关的架构设计的属性和原则的合适方式，同时也是实现第 7 条规定的对于半正式或正式符号的需求的方式。

然而，请注意，一种建模方法可能无法涵盖所有的层面（例如，针对软件功能的实现的模型通常不会描述包括基础软件（BSW）或操作系统（OS）的元素在内的整体架构设计），并且，如果没有进一步的（例如，由不同的合作方提供的）文本说明，模型可能无法被完全地理解。

B.3.3 软件单元的设计与实现（第 8 和 9 条）

模型，建模指南以及编码指南一起可被用于在更高的抽象层面上对详细设计和软件单元的开发。当使用 MBD 时，可以直接通过代码生成由模型生成可执行的代码。

通过标准化方法、仿真、静态分析或对于软件单元的模型在环/软件在环测试，MBD 支持自动地进行的一致性（例如，数据类型、（在使用前）对数据的定义的正确性）检查及验证。依据代码生成器的可信度（参见 ISO 26262-8:2018，第 11 条），与手动编码相比，基于模型的自动地代码生成可以降低出现编码错误的风险。

但是请注意，例如：

如果没有以其他合适的形式被记录，则设计层面中无法被建模符号表达的部分可能会被遗漏。如果所有的测试都源于这样一个“不完整”的模型，则即使是单元测试（例如，使用背靠背测试）也可能无法揭示这一点。

如果仅对目标功能进行建模，则可能无法实现与安全相关的代码的属性（例如，鲁棒性）。代码的属性通常通过对模型的属性以及代码生成的属性的适当组合来实现（例如，如果除法由代码生成器“按原样”生成，则对除零的检查将在模型级别被进行。如果代码生成器使用面向鲁棒性设计的编码模式处理除零，则可以减轻在模型级别被进行的对除零的分析的负担）。

错误地寻址或数值精度问题（例如，模型继承自控制工程）可能会引入故障。例如，控制工程的编码环境与目标编码环境在与精度相关的属性上的差异就会导致问题。

由连续的模型创建对于软件行为的离散形模型可能会引入故障（例如，值和/或时间的离散化效应、计算的执行时间、对并发任务的处理）。

模拟或验证的结果（例如，对一致性的检查的结果）可能依赖于工具，因为不同的模拟引擎或模型检查器可能在被实现的语义方面有所不同（例如，在算法层面未被建模语言的语义定义）。

自动编码对资源的使用情况（执行时间和内存消耗）可能与手动编码的不同。此外，对于资源使用的优化手段可能会更加有限。

对于自动编码的情况，被生成的与手动编码等价的源代码的可验证性可能更难被实现。

B.3.4 软件组件的设计、实现与集成，包括由软件组件模型自动地生成代码（第 8、9 和 10 条）

模型，建模指南以及编码指南一起可被用于以高度抽象的方式对软件进行设计、实现以及集成。因此，由被集成的模型生成的代码可被用于实现软件组件或甚至嵌入式软件。

这种方法意味着不同的软件开发阶段需要相互紧密地结合，因此，需要仔细地评估这种方法的优势及潜在的问题（参见上面提供的提示），其中包括对适当的安全措施的实现（例如，使用单独的测试模型来设计额外的测试用例）。

B.3.5 验证（静态和/或动态）（第 9、10 和 11 条）

模型可以作为对产物（例如设计模型、代码）进行验证的一种手段。这样的模型被称为“验证模型”。例如，验证模型可被用作背靠背测试以及测试用例的生成的基础，或者被用于表示与安全相关的属性（作为对标准验证（这要求待验证的模型也是标准的）的引用）。

模型还可以作为对验证活动进行实现或支持的一种手段（例如，通过模拟被测设备所处的环境，为闭环控制中的硬件在环测试提供所需的模型）。

以验证为目的的对模型的使用可以，尽早且有效地对产物（包括软件）中的故障/失败进行检测，使测试用例被更高效地生成，实现高度自动化地测试或甚至标准的验证技术。

但是请注意，例如：

如果没有验证被用于验证的模型的适用性，与结果相关的有效性可能会受到质疑（例如，不完备的验证模型可能会导致不正确的测试结果）。

对于有效的结果，验证模型的成熟度应与验证对象的目标成熟度相匹配。

由同一模型生成的测试用例（也被用于代码生成）不能作为验证模型自身以及由模型生成的代码的唯一来源。

附件 C（规范性）

软件配置

C.1 目标

软件配置的目标是：

a) 实现对不同的应用程序的软件的行为进行控制

b) 验证配置数据及标定数据符合目标 ASIL 的需求

c) 验证特定于应用的嵌入式软件及其标定数据符合产品的发布

C.2 概况

软件配置实现了对嵌入式软件（使用配置及标定数据（见图 C.1））的特定变体的开发。

C.3 本条款中的输入项

C.3.1 先决条件

（本条款的）先决条件与软件配置适用的相关阶段的先决条件一致。

C.3.2 进一步的支持信息

（本条款的）进一步的支持信息与软件配置适用的相关阶段的进一步的支持信息一致。

C.4 需求和建议

C.4.1 应指定配置数据，以确保在安全生命周期内对可配置的软件的正确地使用。配置数据应包括：

a) 配置数据的有效值

b) 配置数据的目标及用法

c) 范围、比例、单位

d) 配置数据的不同元素之间的相互依赖性

C.4.2 应按照 ISO 26262-8:2018，第 9 章对配置数据及其规范进行验证，以验证：

a) 配置数据符合第 7.5.1 条规定的软件架构设计规范以及第 8.5.1 条规定的软件单元设计规范

b) 对值的使用在其指定的范围内

c) 对其他配置数据的兼容性

注意：

应在软件生命周期的测试阶段对可配置的软件进行测试（参见第 9 条、第 10 条、第 11 条和 ISO 26262-4:2018，第 7 条）。

C.4.3 配置数据的 ASIL 应等于对其进行应用的可配置的软件的最高 ASIL。

C.4.4 对于被用于已被识别的项目的开发的配置数据的集合，应根据 ISO 26262-8:2018，第 9 条对可配置的软件进行验证。

注意：

在嵌入式软件中，只有其行为会受到配置数据的影响的部分才会被（对于配置数据的集合）验证。

C.4.5 For configurable software, a simplified software safety lifecycle in accordance with Figures C.2 or C.3 may be applied.

注意：

A combination of the following verification activities can achieve the complete verification of the configured software:

a) “verification of the configurable software”;

b) “verification of the configuration data”; and

c) “verification of the configured software”.

This is achieved by either:

verifying a range of admissible configuration data in a) and showing compliance to this range in b); or

by showing compliance to the range of admissible configuration data in b) and performing c).

C.4.6 The calibration data associated with software components shall be specified to ensure the correct operation and expected performance of the configured software. This shall include:

a) the valid values of the calibration data;

b) the intent and usage of the calibration data;

c) the range, scaling and units, if applicable, with their dependence on the operating state;

d) the known interdependencies between different calibration data; and

NOTE 1: Interdependencies can exist between calibration data within one calibration data set or between calibration data in different calibration data sets such as those applied to related functions implemented in the software of separate ECUs.

e) the known interdependencies between configuration data and calibration data.

NOTE 2: Configuration data can have an impact on the configured software that uses the calibration data.

C.4.7 The ASIL of the calibration data shall equal the highest ASIL of the software safety requirements it can violate.

C.4.8 The specification of the calibration data shall be verified in accordance with ISO 26262-8:2018, Clause 9 to provide evidence that:

a) the specified calibration data are suitable and comply with the software safety requirements in accordance with 6.5.1;

b) the specified calibration data are compliant with the software architectural design specification in accordance with 7.5.1 and with the software unit design specification in accordance with 8.5.1; and

c) the specified calibration data are consistent and compatible with the specification of other calibration data to prevent unintended impact.

C.4.9 The calibration data which are released for production shall be verified in accordance with ISO 26262-8:2018, Clause 9 to provide evidence that:

a) the released calibration data comply with their specification (see C.4.6); and

b) the calibrated, application-specific variant of the embedded software provides the specified safetyrelated functionalities and properties.

注意：

Verification of calibration data can also be performed at the system level.

C.4.10 To detect unintended changes of safety-related calibration data, mechanisms for the detection of unintended changes of data as listed in Table C.1 shall be applied.

C.4.11 The generation and application of calibration data shall be specified regarding:

a) the procedures that shall be followed;

b) the tools for generating calibration data; and

c) the procedures for verifying calibration data.

注意：

Verification of calibration data can include checking the value ranges of calibration data or the interdependencies between different calibration data.

C.5 产物

C.5.1 Configuration data specification resulting from requirements C.4.1 to C.4.4.

C.5.2 Calibration data specification resulting from requirement C.4.6 to C.4.8.

C.5.3 Configuration data resulting from requirement C.4.2 to C.4.4.

C.5.4 Calibration data resulting from requirement C.4.7 to C.4.10.

C.5.5 Verification specification (refined) resulting from requirements C.4.2, C.4.4, C.4.5, C.4.7, C.4.8, C.4.10 and C.4.11.

C.5.6 Verification report (refined) resulting from requirements C.4.2, C.4.4, C.4.5, C.4.7, C.4.8, C.4.10 and C.4.11.

C.5.7 Software architectural design specification (refined) resulting from requirement C.4.10.

C.5.8 Documentation of the software development environment (refined) resulting from requirements C.4.1 to C.4.11.

Annex D (informative)

Freedom from interference between software elements

D.1 Objectives

The objective is to provide examples of faults that can cause interference between software elements (e.g. software elements of different software partitions). Additionally, this Annex provides examples of possible mechanisms that can be considered for the prevention, or detection and mitigation, of the listed faults.

NOTE

The capability and effectiveness of the mechanisms used to prevent, or to detect and mitigate, relevant faults is assessed during development.

D.2 General

D.2.1 Achievement of freedom from interference

To develop or evaluate the achievement of freedom from interference between software elements, the effects of the exemplary faults, and the propagation of the possible resulting failures can be considered.

D.2.2 Timing and execution

With respect to timing constraints, the effects of faults such as those listed below can be considered for the software elements executed in each software partition:

blocking of execution;

deadlocks;

livelocks;

incorrect allocation of execution time; or

incorrect synchronization between software elements.

EXAMPLE

Mechanisms such as cyclic execution scheduling, fixed priority based scheduling, time triggered scheduling, monitoring of processor execution time, program sequence monitoring and arrival rate monitoring can be considered.

D.2.3 Memory

With respect to memory, the effects of faults such as those listed below can be considered for software elements executed in each software partition:

corruption of content;

inconsistent data (e.g. due to update during data fetch);

stack overflow or underflow; or

read or write access to memory allocated to another software element.

EXAMPLE 1

Safety measures such as memory protection, parity bits, error-correcting code (ECC), cyclic redundancy check (CRC), redundant storage, restricted access to memory, static analysis of memory accessing software and static allocation can be used.

EXAMPLE 2

Appropriate verification methods can be considered as detailed safety analysis to identify critical memories that protection mechanisms are used for. Results of static and semantic code analysis, control flow and data flow analysis can provide evidence for demonstrating freedom from interference.

D.2.4 Exchange of information

With respect to the exchange of information, the causes for faults or effects of faults such as those listed below can be considered for each sender or each receiver:

repetition of information;

loss of information;

delay of information;

insertion of information;

masquerade or incorrect addressing of information;

incorrect sequence of information;

corruption of information;

asymmetric information sent from a sender to multiple receivers;

information from a sender received by only a subset of the receivers; or

blocking access to a communication channel.

NOTE

The exchange of information between elements executed in different software partitions or different ECUs includes signals, data, messages, etc.

EXAMPLE 1

Information can be exchanged using I/O-devices, data buses, etc.

EXAMPLE 2

Mechanisms such as communication protocols, information repetition, loop back of information, acknowledgement of information, appropriate configuration of I/O pins, separated point-to-point unidirectional communication objects, unambiguous bidirectional communication objects, asynchronous data communication, synchronous data communication, event-triggered data buses, event-triggered data buses with time-triggered access, time-triggered data buses, mini-slotting and bus arbitration by priority can be used.

EXAMPLE 3

Communication protocols can contain information such as identifiers for communication objects, keep alive messages, alive counters, sequence numbers, error detection codes and error-correcting codes.

EXAMPLE 4

Appropriate verification methods can be considered as detailed safety analysis to identify critical data exchange that protection mechanisms are used for. Results of static and semantic code analysis, control flow and data flow analysis can provide evidence for demonstrating freedom from interference.

Annex E (informative)

Application of safety analyses and analyses of dependent failures at the software architectural level

E.1 Objectives

This Annex explains the possible application of safety analyses and dependent failure analyses at the software architectural level. The examples provided in this Annex are intended to support the understanding of these analyses and provide guidance on their application.

E.2 General

E.2.1 Scope and purpose of the analyses

The ability of the embedded software to provide the specified functions, behaviour and properties with the integrity as required by the assigned ASIL is examined or confirmed by applying safety analyses or dependent failure analyses at the software architectural level.

The suitability of embedded software to provide the specified functions and properties with the integrity required by the assigned ASIL is examined by:

identifying possible design weaknesses, conditions, faults or failures that could induce causal chains leading to the violation of safety requirements (e.g. using an inductive or deductive method); and

analysing the consequences of possible faults, failures or causal chains on the functions and properties required for the software architectural elements.

The achieved level of independence or freedom from interference between the relevant software architectural elements is examined by analysing the software architectural design with respect to dependent failures, i.e.:

possible single events, faults or failures that may cause a malfunctioning behaviour of more than one of the software elements which require independence from each other (e.g. cascading and/or common cause failures including common mode failures); and

possible single events, faults or failures that may propagate from one software element to another inducing causal chains leading to the violation of safety requirements (e.g. cascading failures).

Achievement of independence or freedom from interference between the software architectural elements can be required because of:

the application of an ASIL decomposition at the software level (see 6.4.3);

the implementation of software safety requirements (see 7.4.11), for example, to provide evidence for effectiveness of the software safety mechanisms such as independence between the monitored element and the monitor; or

required coexistence of the software architectural elements (see 7.4.6, 7.4.8 and 7.4.9 and ISO 26262-9:2018, Clause 6).

The role of safety analyses and analyses of dependent failures at software architectural level supports both design specification and design verification activities.

Such analysis may also reveal incompleteness or inconsistencies with respect to given safety requirements.

The results of safety analyses and analyses of dependent failures at software architectural level is also a basis for

the specification and implementation of effective safety mechanisms in the product; or

the determination of appropriate development-time safety measures, which are suitable either to prevent or to detect and control the relevant faults or failures identified during these analyses.

Figure E.1 illustrates the role of the safety-oriented analyses at software architectural level during software development and the basic relationships or interactions between software safety requirements, software architectural design and the safety plan.

EXAMPLE

Figure E.2 illustrates interference caused by a conflicting use of a shared resource (e.g. a shared processing element). As shown in Figure E.2, a QM software element interferes and prevents the timely execution of the ASIL software element. Such interference could also occur between software components with different ASIL values. The figure illustrates the effects on the software execution without and with implementation of freedom from interference mechanisms. By introducing "check points" into software and implementing a timeout monitoring for the check points, the timing interference can be detected and a suitable reaction initiated.

Safety analyses and dependent failure analyses are intended to be applied at the software architecture level. Code level safety analyses (e.g. with respect to runtime errors such as divide by zero, access beyond array index boundary) are neither required nor considered necessary for the following reasons:

The residual risk regarding these types of faults can be considered as sufficiently low provided that the software development approach as described in this document including the selection and application of suitable methods, approaches and development principles such as modelling and programming guidelines, design and implementation rules, model and/or code reviews, semantic or static analysis, unit and integration tests is applied carefully; and

These types of faults in the implementation of the respective architectural elements usually induce the same malfunctioning behaviour of the element at its interfaces as analysed at architectural level. Therefore the analyses at the higher level already provide the evidence that the selected technical safety mechanisms are effective or that the development-time safety measures are sufficient to ensure an adequate argument.

E.2.2 Relationship between safety analyses and dependent failure analyses at the system, hardware and software level

Safety analyses and dependent failure analyses are applied during the multiple phases of the development lifecycle. These analyses can be related to each other.

In a separation of concern approach initiated at the system level, it is usually the responsibility of hardware development to ensure that the processing unit has a sufficiently low residual risk regarding hardware faults. Therefore, the software safety analysis and software dependent failure analysis at software architectural level can be performed without considering hardware faults.

However, under some hardware conditions (e.g. insufficient diagnostic coverage regarding random hardware faults of the processing element including transient faults), it may be appropriate to consider the negative influence of hardware faults. In such cases, specific analyses regarding the specific hardware/software interaction are performed considering for example:

— the specific software mapping to the different processing units of multi-core systems;

— the detailed design of the processing element on which the software is executed regarding the static or dynamic aspects of the software architectural design; or

— the achievable diagnostic coverage of the selected software safety mechanisms regarding softwarerelevant hardware faults.

NOTE

Analysis of a specific hardware/software interaction can be supported by fault injection techniques (see also ISO 26262-11:2018, 4.8).

E.2.3 Safety analyses in a distributed software development (including SEooC development of software elements)

Embedded software and its software elements are often developed as a distributed development by more than one organization (including OEM, Tier 1, Tier 2, silicon vendor or software vendor) and even out of context (e.g. basic software, hardware-related software, COTS software or operating systems developed as an SEooC).

Important aspects for meaningful safety-oriented analyses in distributed software developments are:

definition and agreement about the scope of the analyses and the procedures or methods used for performing the analyses either separately or jointly (including exchange of information/ documentation or confirmation of assumptions);

definition and agreement regarding the overall responsibility for the software safety analyses process and common rules for the participating organizations (e.g. high level components, access rules between them);

definition and agreement about the interfaces when using a modular approach for the analyses (e.g. agreed software fault models at the interfaces between the different scopes, the approach used or the exchanged information/documents); and

definition and agreement about the verification of the analyses.

E.3 Topics for performing analyses

The software architectural design provides high level rules and decisions (e.g. functional safety classification of components, access rules between components) that supports the implementation and to argue the achievement of functional safety.

Common topics to achieve meaningful analyses are the determination of:

the goals for the analyses – see E.3.1;

the scope and boundaries – see E.3.2;

the method applied to conduct the analyses – see E.3.3; and

the means or criteria to support the meaningfulness, objectivity and rigour of the analyses – see E.3.4.

E.3.1 Determination of the goals for the analyses

The goals are provided by Clause 7 and ISO 26262-9:2018 Clauses 7 and 8.

EXAMPLE

Violation of the safety-related functionalities or properties assigned to the software within the scope of the analyses such as robustness or deterministic execution.

E.3.2 Determination of the scope and boundaries regarding the specific architectural design to be analysed

Depending on the goals of the analyses, the scope is determined setting the focus on the relevant parts of the architectural design.

The scope of the analyses can be influenced by:

the relevant scope of delivery and the respective responsibilities as defined in the DIA;

the specific goals of the analyses;

architectural strategies supported by “good” design principles (see 7.4.3); or

properties required from the architectural design resulting from higher level safety concepts in respect of the achievement of freedom from interference or sufficient independence.

EXAMPLE 1

Appropriate end-to-end data protection mechanisms can be used as an argument that the basic software can be treated as a “black box” when considering the exchange of safety-related data with external senders or receivers during a safety analyses.

EXAMPLE 2

Dependencies of software functions with operating modes such as a safety-related function which is only “active” in a mode where the other “critical” function is safely deactivated by a safe mode switching function.

EXAMPLE 3

Figure E.3 shows software to be analysed where according to the safety concept the safetyrelated functionalities are implemented only in SWC U and controlled by a monitoring function implemented in SWC V. Determination of the scope of the analyses on the architecture clarifies the required safety arguments and supports the further steps shown in the following sections. In this example, SWC Y can be exempted from a further detailed analysis only if the analyses of SWC X, SWC V and SWC U are able to confirm the assumed freedom from interference (e.g. no weaknesses in the Guard M regarding cascading failures with respect to erroneous signals A1 to An).

E.3.3 Determination of the method applied to conduct the analyses

Due to the specific nature of software (e.g. no random faults due to wear out or ageing and lack of a mature probabilistic method), methods established for such analyses at the system or hardware level often cannot be transferred to software without modifications, or will not deliver results that are as meaningful.

Common factors of safety analyses methods are that they usually consist of a means to enforce a structured approach, to store the gained knowledge, and to draw conclusions.

EXAMPLE

Syntax and semantics to describe faults and their dependencies in a fault tree or the function net or list of elements or Risk Priority Number used in an FMEA.

The basis for the safety analyses and dependent failure analyses is the software architectural design describing the static aspects (e.g. expressed by a block diagram showing the functional elements and their interfaces/relationships) as well as the dynamic aspects (e.g. expressed by sequence, timing or scheduling diagrams or state charts) of the related software.

The safety analyses and dependent failure analyses according to the software architectural design can follow functional and/or processing chains considering both static and dynamic aspects. During such analyses, software fault models or questions such as “which specific fault or failure originating from or impacting this software component can lead to the violation of an assigned safety requirement” can be used to identify safety-related weaknesses in the design.

Refinements of software architectural design can support the safety analyses and dependent failure analyses for the adequate level of details in order to identify lower levels of faults or failures.

The level of detail required during such an analyses is related to:

adequate selection of the scope during refinements of the architecture design;

properties that support achievement of the specific goals of the analyses;

an argument based on the architectural strategy supported by “good” design principles (see 7.4.3); or

an argument resulting from sufficient independence including achieved freedom from interference.

E.3.4 Aspects to support the meaningfulness, objectivity and rigour of the analyses

E.3.4.1 Coupling factor classes for DFA in accordance with ISO 26262-9:2018

In ISO 26262–9:2018, Annex C, coupling factor classes with corresponding software-level examples are defined that can be used to improve the results of a dependent failure analysis performed on functional or processing chains of the software that are required to be independent.

E.3.4.2 Use content of Annex D

Annex D provides software fault models for consideration when analysing interference between software elements, for example with respect to:

timing and execution;

memory; or

exchange of information.

E.3.4.3 Analyses supported by using guide words

Guide words can be used to systematically examine the possible deviations from a specific design intent and to determine their possible consequences. Guide words are used to generate questions for the examination of a specific functionality or property of the architectural element during the safetyoriented analyses. When using guide words, the safety-oriented analyses of the specific functions or properties for each design element are repeated with each guide word, until the predetermined guide words have all been examined. Thus, guide words are a means to conduct such analyses systematically and to support the argument for completeness.

Data flow or similar diagrams are often used to describe the functional aspects of the software architectural design (e.g. functional or processing chains). Figure E.4 shows interaction of the software components Y, U and V and the related functional or processing chain (e.g. based on data flow).

Guide words can be used to identify weaknesses, faults, and failures. The selection of suitable guide words depends on the characteristics of the examined functions, behaviour, properties, interfaces or exchanged data.

Using the design intent as a basis, the guide words are derived by combining design attributes, the related guide words and their interpretation, in order to achieve a common understanding for the analyses. Table E.1 shows examples for the selection of guide words applied to the design in Figure E.4.

During the analysis, guide words can be applied using a deductive or inductive approach. During the analyses, a further refinement of the guide words is possible if required (e.g. to better match specific design aspects).

During the analyses, the guide words are used according to the selected method (e.g. following function or processing chains) to generate the questions that will examine the design and reveal possible weaknesses and their consequences. An example for a guide word supported analysis of the signals A1 to An is shown in Table E.2.

E.4 Mitigation strategy for weaknesses identified during safety and dependent failure analyses

The results of safety analyses and dependent failure analyses at the software architectural level allow the selection of adequate safety measures to prevent or to detect and control faults and failures with the potential to violate safety requirements or safety goals.

A safety measures determination strategy can be based on the following considerations:

the criticality of each identified fault, based on whether it can violate a safety goal or safety requirement allocated to architectural elements, and their assigned ASIL;

whether the architectural design can be improved to eliminate identified weaknesses or to reduce the criticality of the identified fault;

the effectiveness of determined development-time safety measures and whether they can sufficiently mitigate the identified fault based on its criticality with corresponding rationale (e.g. rationale for the effectiveness of defined verification activities considering the software fault model used during the analyses);

the effectiveness of determined safety mechanisms to mitigate the identified critical fault(s) for which development-time measures are considered insufficient; and

the complexity of the software architectural design (e.g. number of interfaces and software components) or the software components (e.g. number of assigned requirements or size of the component).

EXAMPLE: For more complex software, an argument based solely on development-time measures is less suitable.

According to the strategy above, it is not always necessary to implement safety mechanisms which are able to prevent or detect and control such faults or failures at runtime

Bibliography

[1] ISO/IEC 12207:2008, Systems and software engineering

Software life cycle processes

[2] IEC 61508:2010, (all parts), Functional safety of electrical/electronic/programmable electronic safety-related systems

[3] MISRA C:2012, Guidelines for the use of the C language in critical systems, ISBN 978-1-906400- 10-1, MIRA, March 2013

[4] MISRA AC GMG. Generic modelling design and style guidelines, ISBN 978-906400-06-4, MIRA, May 2009

[5] ISO/IEC/IEEE 29119:2013, (all parts), Software and systems engineering

Software testing

[6] Bieman J.M., Dreilinger D., Lin L. “Using fault injection to increase software test coverage,” in Software Reliability Engineering, 1996. Proceedings., Seventh International Symposium on, vol., no., pp.166-174, 30 Oct-2 Nov 1996 doi: 10.1109/ISSRE.1996.558776

[7] Jia Y., Merayo M., Harman M. 2015) Introduction to the special issue on Mutation Testing. Softw. Test. Verif. Reliab., 25: 461–463

[8] ISO 26262-12:2018, Road Vehicles — Functional safety

Part 12: Adaptation of ISO 26262 for Motorcycles