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 对于可配置的软件，可以对其应用符合图 C.2 或 C.3 的被简化的软件安全生命周期。

注意：

对以下验证活动的组合可以实现对被配置的软件的完整地验证：

a) 对可配置的软件的验证

b) 对配置数据的验证

c) 对被配置的软件的验证

可通过以下方式实现：

验证在 a) 中的有效的配置数据的取值范围，并验证在 b) 中的取值与 a) 中的取值范围相符

验证在 b) 中的取值与有效的配置数据的取值范围相符并执行 c)

C.4.6 应指定与软件组件相关的标定数据，以确保被配置的软件的正确运行和预期性能。这应包括：

a) 标定数据的有效值

b) 标定数据的使用目的和使用方式

c) 取值范围、换算比例和取值单位（如果适用）及其对运行状态的依赖性

d) 已知的不同标定数据之间的相互依赖性

注意 1：相互依赖性可以存在于同一个标定数据集内的标定数据之间，也可以存在于不同标定数据集内的标定数据之间。例如，在若干个特定 ECU 软件中被实现的相关功能的标定数据。

e) 已知的配置数据和标定数据之间的相互依赖性

注意 2：配置数据可能会对使用标定数据的被配置的软件产生影响。

C.4.7 标定数据的 ASIL 应等于与其相关的软件安全需求的最高 ASIL。

C.4.8 应按照 ISO 26262-8:2018，第 9 条验证标定数据的规范，以验证：

a) 指定的标定数据的适用性，并符合第 6.5.1 条规定的软件安全需求

b) 指定的标定数据符合第 7.5.1 条规定的软件架构设计规范和第 8.5.1 条规定的软件单元设计规范

c) 为防止意外的影响，指定的标定数据（的规范）与其他标定数据的规范一致且兼容

C.4.9 应按照 ISO 26262-8:2018，第 9 条，对发布的产品的标定数据进行验证，以验证：

a) 发布的标定数据符合其规范（参见第 C.4.6 条）

b) 被标定的、特定于应用的嵌入式软件变体提供了指定的与安全相关的功能和属性

注意：

对标定数据的验证也可以在系统级别进行。

C.4.10 为了检测对与安全相关的标定数据的意外更改，应采用表 C.1 所列出的检测对数据的意外更改的机制。

C.4.11 对于标定数据的生成和应用，应根据以下内容来指定：

a) 应遵循的步骤

b) 生成标定数据的工具

c) 对标定数据进行验证的步骤

注意：

对标定数据的验证可以包括对标定数据的取值范围或不同标定数据之间的相互依赖性的检查。

C.5 产物

C.5.1 根据第 C.4.1 至 C.4.4 条得出的配置数据规范。

C.5.2 根据第 C.4.6 至 C.4.8 条得出的标定数据规范。

C.5.3 根据第 C.4.2 至 C.4.4 条得出的配置数据。

C.5.4 根据第 C.4.7 至 C.4.10 条得出的标定数据。

C.5.5 根据第 C.4.2、C.4.4、C.4.5、C.4.7、C.4.8、C.4.10 和 C.4.11 条得出的验证规范（已细化）。

C.5.6 根据第 C.4.2、C.4.4、C.4.5、C.4.7、C.4.8、C.4.10 和 C.4.11 条得出的验证报告（已细化）。

C.5.7 根据第 C.4.10 条得出的软件架构设计规范（已细化）。

C.5.8 根据第 C.4.1 至 C.4.11 条得出的与软件开发环境相关的文档（已细化）。

附件 D（资料性）

消除软件（架构）元素之间的相互干扰

D.1 目标

本附件旨在提供可能会造成软件（架构）元素（例如，在不同软件分区中的软件（架构）元素）之间的相互干扰的故障的示例。此外，本附件还提供了可被用于预防、检测和缓解所列出的故障的可能的机制的示例。

注意：

在开发过程中，将对被用于预防、检测和缓解相关故障的机制的能力和有效性进行评估。

D.2 概况

D.2.1 实现对（软件（架构）元素之间的）相互干涉的消除

为了开发或评估实现对软件（架构）元素之间的相互干扰的消除，可以考虑示例性故障的影响以及其可能导致的故障的传播（范围）。

D.2.2 时间与执行

对于时间的约束，应考虑（例如下面所列出的）故障对在不同软件分区中被执行的软件（架构）元素的影响：

对执行的阻塞

死锁

活锁

对执行时间的不正确的分配

软件（架构）元素之间的不正确的同步

示例：

可以考虑以下机制：周期性执行的调度方式、基于固定优先级的调度方式、时间触发式的调度方式、对处理器的执行时间的监控、对程序（执行）顺序的监控以及对到达率的监控。

D.2.3 内存

对于内存，应考虑（例如下面所列出的）故障对在不同软件分区中被执行的软件（架构）元素的影响：

内容损坏

不一致的数据（例如，在数据被读取期间对数据进行更新）

堆栈向上溢出或向下溢出

对不属于自己的内存进行读/写访问

示例 1：

可以使用以下安全措施：内存保护、奇偶校验位、纠错码（ECC）、循环冗余校验（CRC）、冗余存储、对内存访问的限制、对内存访问软件的静态分析以及（对内存的）静态分配。

示例 2：

适当的验证方法可被视为关于对采用保护机制的关键内存的认证的详细的安全分析。由对代码的静态及语义分析的结果、对控制流和数据流的分析的结果，验证对相互干扰的消除。

D.2.4 信息的交换

对于信息的交换，每个发送方或接收方应考虑下面所列出的故障的原因或影响：

信息的重复

信息的丢失

信息的延迟

信息的插入（原子性的丢失）

伪装或错误的信息地址

信息顺序的错误

信息（内容）的错误

由一个发送者向多个接收者发送的非对称信息

来自发送者的信息仅被一部分接收者接收

阻塞对通信通道的访问

注意：

在不同软件分区或不同 ECU 中被执行的软件（架构）元素之间的信息的交换包含信号、数据、消息等。

示例 1：

可以通过 I/O 设备、数据总线等方式进行信息的交换。

示例 2：

可以使用以下机制：通信协议、信息冗余、信息回环、信息确认、对 I/O 引脚的适当配置、分离式点对点单向通信对象、明确的双向通信对象、异步数据通信、同步数据通信、事件触发式数据总线、具有时间触发式访问的事件触发式数据总线、时间触发式数据总线、迷你时间间隔以及根据优先级进行的总线仲裁。

示例 3：

通信协议可以包含诸如通信对象的标识符、心跳包消息、活动计数器、序号、错误检测码和纠错码等信息。

示例 4：

适当的验证方法可被视为关于对采用保护机制的关键信息的交互的认证的详细的安全分析。由对代码的静态及语义分析的结果、对控制流和数据流的分析的结果，验证对相互干扰的消除。

附件 E（资料性）

软件架构层面的对安全分析和相关的故障分析的应用

E.1 目标

本附件解释了在软件架构层面的对安全分析和相关的故障分析的可能的应用。本附件中被提供的示例旨在帮助理解这些分析，并为其应用提供指导。

E.2 概况

E.2.1 分析的范围和目的

通过在软件架构层面的对安全分析或相关的故障分析的应用来检查或确认提供目标 ASIL 所要求的指定功能、行为和属性的嵌入式软件的能力。

通过以下方式检查提供目标 ASIL 所要求的指定功能和属性的嵌入式软件的适用性：

识别会间接地违反安全需求的可能的设计缺陷、条件、故障或失效（例如，通过总结或推理）

分析可能的故障、失效或间接影响对软件架构元素所需的功能和属性的影响

通过分析软件架构设计中的相关故障，可以检查相关的软件架构元素之间的独立性或抗干扰性，即：

可能会导致需要相互间独立的多个软件架构元素出现故障性行为的可能的单一事件、故障或失效（例如，级联和/或由相同原因导致的故障（包括共模故障））

可能会导致在软件架构元素之间被传播的违反安全需求的连锁反应的可能的单一事件、故障或失效（例如，级联故障）

由于以下原因，可能需要实现软件架构元素之间的独立性或抗干扰：

应用在软件级别的对 ASIL 的分解（参见第 6.4.3 条）

对软件安全需求的实现（参见第 7.4.11 条）（例如，验证软件安全机制（例如，被监控的软件架构元素和监控器之间的独立性）的有效性）

对与软件架构元素共存的需求（参见第 7.4.6、7.4.8 条和第 7.4.9 条以及 ISO 26262-9:2018，第 6 条）

软件架构层面的安全分析和相关的故障分析将作用对规范设计和验证活动设计的支持。

分析还可以揭示对于给定的安全需求而言的不完整性或不一致性。

软件架构层面的安全分析和相关的故障分析的结果同时也是以下内容的依据：

在产品中的有效的安全机制的规范以及对安全机制的实施

确定合适的开发时长的安全措施，被用于防止、检测及控制在这些分析中被发现的相关的故障或失效

图 E.1 说明了在软件开发过程中的软件架构层面的安全分析的作用，以及软件安全需求、软件架构设计和安全计划之间的基本关系或相互作用。

示例：

图 E.2 展示了对共享资源（例如，共享处理单元）的使用的冲突造成的干扰。如图 E.2 所示，QM 软件架构元素会干扰并阻止 ASIL 软件架构元素的及时执行。此类干扰也可能发生在不同 ASIL 的软件组件之间。该图展示了实施和未实施排除干扰的机制对软件的执行造成的影响。通过在软件中引入“检查点”并对检查点进行超时监控，可以对时序干扰进行检测，并（在检测到干扰时）启动适当的响应措施。

安全分析和相关的故障分析旨在被应用于软件架构层面。代码级别的安全分析（例如，针对除零、越界访问等运行时错误）既不是必需的，也不被认为是必要的，原因如下：

只要在本文档中被描述的软件开发方法（包括对合适的方法、方式和开发原则（例如，建模和编程指南、设计和实施规则、模型和/或代码审查、语义或静态分析、单元和集成测试）的选择和应用）被认真地采用，则可以认为这些类型的故障的剩余风险（被控制在）足够低（的水平）

在对软件架构元素的实现过程中，此类故障通常会导致该元素在其接口中出现与架构层面的分析中的故障行为相同的故障行为。因此，更上层的分析已经验证了所选的技术层面的安全机制是有效的，或者开发阶段的安全措施对于需求而言是足够的

E.2.2 在系统、硬件和软件层面的安全分析与相关的故障分析之间的关系

安全分析和相关的故障分析被应用于开发生命周期中的多个阶段。这些分析可以相互关联。

在对系统层面的关注点进行分解的过程中，在硬件开发阶段通常应确保在处理单元中的关于硬件故障的剩余风险被控制在足够低的水平。因此，软件架构层面的关于软件的安全分析和相关的故障分析可以在不考虑硬件故障的情况下被进行。

然而，在某些硬件条件下（例如，对处理单元的随机硬件故障（包括瞬态故障）的诊断覆盖率不够高），对硬件故障的负面影响的考虑可能是恰当的。在这种情况下，需要对特定的硬件/软件交互（行为）进行具体的分析，例如：

目的地为多核系统中的不同处理单元的特定的软件映射

在其中进行执行软件的处理单元的详细设计，涉及软件架构设计的静态或动态层面

所选的软件安全机制对软件相关的硬件故障的可被实现的诊断覆盖率

注意：

故障注入技术支持对特定的硬件/软件交互（行为）的分析（参见 ISO 26262-11:2018，第 4.8 条）。

E.2.3 分布式软件开发中的安全分析（包括软件架构元素的 SEooC 开发）

嵌入式软件及其软件架构元素通常由多个组织（包括 OEM、Tier 1、Tier 2、芯片供应商或软件供应商）以分布式开发的形式进行开发，甚至以脱离上下文的形式进行开发（例如，SEooC 开发的基础软件、与硬件相关的软件、COTS 软件或 OS）。

分布式软件开发中的有意义的安全分析的重要方面是：

关于分析的范围以及以单独或联合的形式进行的分析所采用的步骤或方法的定义和协定（包括对信息/文件的交换或对假设的确认）

关于软件安全分析过程的总体职责和参与组织的共同规则（例如，上层组件以及它们之间的访问规则）的定义和协定

在使用模块化的方法进行分析时的接口的定义和协定（例如，在不同范围之间的接口中被商定的软件故障模型、所使用的方法或交换的信息/文档）

关于对分析的验证的定义和协定

E.3 执行分析

软件架构设计提供了对实现进行支持以及对功能安全的实现进行论证的上层规则及决策（例如，对于组件的功能安全分类、组件之间的访问规则）

实现有意义的分析的常见主题是为了确定：

分析的目标（参见第 E.3.1 条）

范围和边界（参见第 E.3.2 条）

分析的方法（参见第 E.3.3 条）

对分析的意义、客观性和严谨性进行支持的方法或标准（参见第 E.3.4 条）

E.3.1 对分析的目标的确定

这些目标由第 7 条和 ISO 26262-9:2018，第 7 条和第 8 条提供。

示例：

违反分析范围内的被分配给软件的与安全相关的功能或属性，例如，鲁棒性或确定性执行。

E.3.2 对待分析的具体的架构设计的范围和边界的确定

根据分析的目标对范围（聚焦点为与架构设计相关的部分）进行确定。

分析的范围可能会受以下因素的影响：

在 DIA 中被定义的交付的相关范围和对应的职责

分析的具体目标；

由“良好”的设计原则支持的架构策略（参见第 7.4.3 条）

由上层的安全概念得出的架构设计所需的属性（以实现抗干扰性或独立性）

示例 1：

当在安全分析中对与外部的发送者或接收者进行的与安全相关的数据交换进行考虑时，适当的端到端数据保护机制可被用于验证基础软件可被视为“黑匣子”的论点。

示例 2：

带有运行模式的软件功能的依赖项。例如，对于与安全相关的功能，仅当其处于特定的模式（其他关键功能已被安全模式切换功能安全地检测到）时才会被激活。

示例 3：

图 E.3 显示了待分析的软件，其中，根据安全概念被实现的与安全相关的功能在软件组件 U 中被实现，且由在软件组件 V 中被实现的监控功能控制。对架构分析的范围的确定阐明了所需的安全论据，并对后续小节中的后续步骤进行支持。在此示例中，仅当对软件组件 X、软件组件 V 和软件组件 U 的分析能够验证假设的抗干扰性（例如，在保护机制 M 中，不存在对于与错误信号 A1 至 An 相关的级联故障的缺陷）时，才可以忽略对软件组件 Y 的后续的细节分析。

E.3.3 对分析的方法的确定

由于软件的特定性质（例如，没有由于磨损或老化而导致的随机故障以及缺乏成熟的概率方法），在不被修改的情况下，在系统或硬件层面被建立的对于此分析的方法通常不能在软件中被直接地应用，或者不能提供有价值的信息。

安全分析的方法的共同特征是，它们通常强制性地包含一种结构化方法、以存储获得的信息及结论。

示例：

在 FMEA 中被使用的被用于描述在故障树、功能网络、元素列表或风险等级中的故障及其依赖关系的语法和语义。

安全分析和相关故障的分析的基础是软件架构设计，其中描述了相关软件的静态层面（例如，通过框图来表示，且阐明了功能元素及其接口/关系）及动态层面（例如，通过序列、时间或调度图或状态图来表示）。

在考虑静态和动态层面的同时，根据软件架构设计的安全分析和相关故障的分析，可以根据功能链和/或处理链进行。在此类分析中，软件故障模型或诸如“源于软件组件或对软件组件产生影响的哪些特定的故障或失效将会违反被分配的安全需求”之类的问题可被用于识别在设计中的与安全相关的缺陷。

对软件架构设计的细化可以以足够详细的程度对安全分析和相关故障的分析进行支持，以识别下层的故障或失效。

此类分析所需的详细程度与以下方面有关：

对软件架构设计的细化过程中的对范围的合理地选择

支持对特定的分析的目标的实现的属性

基于由“良好”的设计原则支持的架构策略的论点（参见第 7.4.3 条）

由包含已被实现的抗干扰性的充分的独立性得出的论点。

E.3.4 对分析的意义、客观性和严谨性的支持

E.3.4.1 符合 ISO 26262-9:2018 的 DFA 耦合因子的类别

在 ISO 26262-9:2018，附件 C 中，对带有对应的软件级别的示例的耦合因子的类别进行了定义，可被用于优化在被要求具有独立性的软件的功能链或处理链层面被执行的相关故障的分析的结果。

E.3.4.2 对附件 D 的内容的使用

附件 D 提供了软件故障模型，以支持对软件架构元素之间的干扰的分析，例如：

时间和执行

内存

信息的交换

E.3.4.3 引导词支持的分析

引导词可被用于系统性地检查对于特定的设计意图的可能的偏差，并确定其可能造成的影响。引导词可被用于在安全分析中生成问题，以检查软件架构元素的特定的功能或属性。对引导词进行使用时，所有被预定义的引导词都应被应用于对于每个设计元素的特定的功能或属性的安全分析。因此，引导词是系统性地进行此类分析并支持对完整性的论证的一种手段。

数据流图或类似的图表通常被用于描述软件架构设计的功能层面（例如，功能链或处理链）。图 E.4 展示了软件组件 Y、U 和 V 以及相关的功能链或处理链（例如，基于数据流）之间的交互。

引导词可被用于识别缺陷、故障和失效。对引导词的恰当地选择取决于被检查的功能、行为、属性、接口或数据交换的特性。

为了实现对于分析有共同的理解，将设计意图作为基础，并结合设计的属性、相关的引导词以及对其的解释，以得出引导词。表 E.1 给出了对被应用于图 E.4 中的设计的引导词的选择的示例。

在分析过程中，可以采用演绎或归纳的方式应用引导词。如有需要，可以对引导词进行进一步地细化（例如，为了更好地与特定的设计层面进行匹配）。

在分析过程中，根据所选的方法（例如，依据功能链或处理链）使用引导词来生成问题，这些问题将被用于对设计的检查并揭示可能存在的缺陷及其后果。表 E.2 显示了基于对信号 A1 至 An 的分析的引导词的示例。

E.4 对于在安全分析和相关故障的分析中被发现的缺陷的缓解策略

软件架构层面的安全分析和相关故障的分析的结果允许选择适当的安全措施来防止、检测和控制可能违反安全需求或安全目标的故障和失效。

可以基于以下几点来考虑对安全措施的确定的策略：

每个已被识别的故障的严重性，取决于它是否会违反被分配给软件架构元素的安全需求或安全目标以及目标 ASIL

是否可以通过改进架构设计的方式来消除已被发现的缺陷或降低已被发现的故障的严重性

被确定的关于开发时间的安全措施的有效性，以及它们是否能够基于故障的严重性来充分地缓解已被识别的故障，并提供与其对应的理由（例如，已对在分析过程中被使用的软件故障模型进行考虑的，关于被定义的验证活动的有效性的理由）

被确定的安全机制对于缓解已被识别的关键故障（关于开发时间的安全措施已被认定为不足以对这些故障进行缓解）的有效性

软件架构设计（例如，接口和软件组件的数量）或软件组件（例如，被分配的需求的数量或组件的大小）的复杂性。

示例：对于更复杂的软件，仅基于关于开发时间的安全措施的论点将缺乏适用性。

根据上述的策略，对能够在运行时防止、检测和控制此类故障和失效的安全机制的实现并不总是必需的。

参考书目

[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