1 前言

1.1 目的

确定软件安全设计的要求，包括降低潜在风险、提高系统的安全性、确保安全需求得到满足等，以指导后续的开发和测试工作

1.2 规范内容

本规范规定了智能驾驶软件开发的安全标准、功能要求等内容。

1.3 版本和变更

本规范的版本变更说明 如表 1 所示。

表 1 更改历史

版本	更改描述	更改日期	更改人
1 .0
1 .1
1 .2

 

2 规范性引用文件

下列文档中的条款通过本标准的引用成为本标准的条款。凡是注日期的引用文档，其随后的修改单（不包含勘误的内容）或修订版均不适用于本标准。凡是不注日期的引用文档，其最新版本适用于本标准。

2.1 国际标准和技术规范

本规范参考的国际标准和技术规范如表2所示。

表 2 规范性引用文件

2.2 国内标准和技术规范

本规范参考的国内标准和技术规范如表 3 所示。

表 3 规范性引用文件

编号	文档
Ref [1]	GB/T 34590.1: 道路车辆 功能安全 第 1 部分：术语
Ref [2]	GB/T 34590.2: 道路车辆 功能安全 第 2 部分：功能安全管理
Ref [3]	GB/T 34590.3: 道路车辆 功能安全 第 3 部分：概念阶段
Ref [4]	GB/T 34590.4: 道路车辆 功能安全 第 4 部分：产品开发：系统层面
Ref [5]	GB/T 34590.6: 道路车辆 功能安全 第 6 部分：产品开发：软件层面
Ref [6]	GB/T 43267: 道路车辆 预期功能安全

3 术语缩写与定义

3.1 缩写

表4列出了本规范中专有名词的英文全称及相应的中文。

表 4 缩写

缩写	含义
ASIC	Application -Specific Integrated Circuit( 专用集成电路 )
ASIL	Automotive Safety Integrity Level （汽车安全完整性等级）
COTS	Commercial Off The Shelf( 商业现成产品 )
CPU	Central Processing Unit( 中央处理单元 )
CRC	Cyclic Redundancy Check( 循环冗余校验 )
DC	Diagnostic Coverage( 诊断覆盖率 )
ECC	Error Correction Code( 检错码 )
ECU	Electronic Control Unit( 电控单元 )
HSI	Hardware-Software Interface( 软硬件接口 )
I/O	Input-Output( 输入 / 输出 )
MC/DC	Modified Condition/Decision Coverage ( 修改条件 / 判定覆盖 )
RAM	Random Access Memory( 随机存储器 )
ROM	Read Only Memory( 只读存储器 )
UML	Unified Modeling Language( 统一建模语言 )

3.2 术语和定义

工作成果

由本规范相关要求得出的文档。

架构

相关项或要素的结构的表征，用于识别结构模块及其边界和接口，并包括将要求分配给结构模块。

A SIL 等级分解

为有助于实现同一安全目标，将冗余的安全要求分配给具有充分独立性的要素，以降低分配给相关要素的冗余的安全要求的A SIL 等级。

评估

对相关项或要素的特性是否实现目标的检查。

审核

针对过程目标对已实施过程的检查。

可接受

足以实现安全案例中确定的总体项目风险。

争论

构造满足特定要求的安全案例（包括主张，论据和证据）。由此产生的论据表明，证据支持了这些主张。

自治

提供自主操作的功能。

证据

用于支持参数的数据或其他信息。

事件

在某一时刻所发生的事情。

项目

评估符合本规范的产品、元素、系统或其他与产品相关的范围。

减轻

降低到可接受的风险水平。

风险

损失事件发生的可能性和该损失事件的严重性组合。

安全

具有安全案例所定义的可接受的缓解后项目级风险。

安全案例

有证据支持的结构化论点，提供了令人信服、可理解和有效的证据，表明系统对于给定环境中的给定应用程序是安全的。

安全相关

直接或间接影响安全性的系统功能，元素，属性或其他方面。

可用性

在定义的生命周期内，产品在给定条件下按照要求提供规定功能的能力。

分支覆盖率

在测试中，已执行计算机程序的控制流分支所占的比率。

组件

由一个以上硬件元器件或一个到多个软件单元组成的逻辑上或技术上可分的非系统层面的要素。

降级

相关项或要素的功能缩减、性能降低或两者均有的状态，或向该状态的过渡。

相关失效

不具有统计独立性的失效，即失效组合发生的概率不等于所有考虑的独立失效发生概率的乘积。

诊断覆盖率

由实施的安全机制探测或控制的失效率占硬件要素失效率或硬件要素某一失效模式失效率的百分比。

要素

系统、组件、硬件元器件或软件单元。

嵌入式软件

在一个处理要素上运行的充分集成的软件。

错误

计算的、观测的、测量的值或条件与真实的、规定的、理论上正确的值或条件之间的差异。

失效

由于故障出现导致要素或相关项预期行为的终止。

失效模式

要素或相关项未能提供预期行为的方式。

失效率

硬件要素的失效概率密度除以幸存概率。

故障

能够引起要素或相关项失效的异常情况。

故障注入

评估要素内故障影响的方法，该方法通过注入故障、错误、或失效从而通过观测点对注入后的响应进行观测。

形式记法

语法和语义上完整定义的描述方法。

形式验证

基于形式记法针对相关项或要素的功能或属性的定义，验证其正确性的方法。

免于干扰

两个或两个以上的要素之间，不存在可能导致违背安全要求的级联失效。

功能安全

不存在由电气/电子系统的功能异常表现引起的危害而导致不合理的风险。

硬件元器件

硬件组件在第一层级分解时的一部分。

危害

由相关项的功能异常表现而导致的伤害的潜在来源。

独立性

两个或者多个要素间不存在会导致违背安全要求的相关失效，或从组织上分隔执行某一活动的各方。

非形式记法

非完整语法定义的描述方法。

检查

为发现安全异常而依据一个正式的流程对工作成果进行考查。

预期功能

已定义的功能。

相关项

实现整车层面功能或部分功能的系统或系统组合。

生命周期

相关项从概念到报废的全部阶段。

管理体系

一个组织用来实现其目的的政策、程序及流程。

功能异常表现

失效或与设计意图相悖的相关项非预期表现。

基于模型的开发

一种使用模型来描述待开发要素行为或属性的开发。

修改

以现有相关项为基础创建新相关项。

修改条件 / 判定覆盖率

在控制流中已执行的、可以独立影响判定结果的全部单一条件结果的百分比。

多核

包括两个或多个能彼此独立运行的硬件处理要素的硬件组件。

观测点

用来观察故障潜在影响的要素的输出信号。

运行模式

源自相关项或要素的使用和应用中功能状态的一些条件。

分区

为实现某种设计，而对功能或要素的分隔。

阶段

规范中定义的安全生命周期的阶段。

处理要素

提供一系列数据处理功能的硬件元器件，通常包括一个寄存器集、一个执行单元和一个控制单元。

质量管理

用来指导和控制组织针对质量的协调活动。

随机硬件失效

在硬件要素的生命周期中，发生的服从概率分布的不可预测的失效。

冗余

除了足以实施所需功能或足以表达信息的方法外，还存在其他方法。

评审

按照评审目的，为实现预期的工作成果目标而对工作成果进行的检查。

风险

伤害发生的概率及其严重度的组合。

安全状态

相关项在失效的情况下，没有不合理风险的运行模式。

安全

没有不合理的风险。

安全活动

在安全生命周期的一个或多个阶段或子阶段进行的活动。

安全异常

偏离预期并可能导致伤害的情况。

安全文化

组织中持久的价值观、态度、动机和认知，即：在决策和行为中，安全优先于与之冲突的目标。

安全目标

作为整车层面危害分析和风险评估结果的最高层面的安全要求。

安全措施

用来避免或控制系统性失效，探测或控制随机硬件失效，或减轻他们有害影响的活动或技术方案。

安全机制

为了保持预期功能或者达到/保持某种安全状态，由电气/电子系统的功能/要素或者其他技术来实施的 技术解决方案，以探测并减轻/容许故障、或者控制/避免失效。

安全相关要素

有潜在可能导致违背安全目标或有助于实现安全目标的要素。

安全相关功能

有潜在可能导致违背安全目标或有助于实现安全目标的功能。

安全相关的特殊特性

相关项、要素自身或其生产过程的特性，这些特性的可合理预见偏差可能影响、促使或造成功能安全的潜在降低。

半形式记法

语法定义是完整的，但语义定义可以是不完整的描述方法。

半形式验证

基于半形式记法的验证。

严重度

对潜在危害事件中可能发生的一个或多个人员的伤害程度的预估。

软件组件

一个或多个软件单元。

软件工具

在开发相关项或要素中所用到的计算机程序。

软件单元

软件架构中最低层级且可被独立测试的软件组件。

语句覆盖率

软件中已执行语句所占的百分比。

子阶段

本规范定义的。安全生命周期中阶段的细分。

系统

至少与一个传感器、一个控制器和一个执行器相关联的一组组件或一组子系统。

系统性失效

以确定的方式与某个原因相关的失效，只有对设计或生产流程、操作规程、文档或其他相关因素进行变更后才可能排除这种失效。

系统性故障

以确定的方式显现失效的故障，只有通过流程或设计措施的应用才能防止其发生。

目标环境

用于执行特定软件的环境。

技术安全概念

技术安全要求的定义，技术安全要求在系统要素间的分配，以及为系统层面功能安全提供依据的相关信息。

技术安全要求

为实现相关的功能安全要求而得出的要求。

测试

为验证相关项或要素满足定义的要求、探测其安全异常、确认要求适用于给定的环境和对其行为建立信心，而进行计划、准备、运行或演练的过程。

瞬态故障

发生一次且随后消失的故障。

不合理的风险

按照现行的安全观念，被判断为在某种环境下不可接受的风险。

验证

确定检查对象是否满足其特定要求。

走查

为了发现安全异常，对工作成果的系统性检查。

3.3 约定术语

本文档中使用了下列术语：

   “强制性”：表示不允许出现安全案例偏差

   “需要”：表示仅当通过提示证明提示元素与项目和/或其安全案例本质上不兼容时，才允许发生安全案例偏离。

   “强烈推荐”：表示是应该遵循的最佳实践，但可以省略，尤其是对于低风险项目。安全案例中明确指出了遗漏，并提供了合理的支持理由，以提供一个根源，以便将根本原因分析追溯到这些遗漏。只要以合理的理由记录了这些遗漏，就可以认为该安全案例是可以接受的。

   “推荐”：表示这些是可选的提示元素，记录了良好做法和/或有用技术的建议。

4 软件开发融合安全概述和组织

4.1 概述

本规范的目的是：

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

b)   定义并验证由技术安全概念和系统架构设计规范导出的软件安全要求和软硬件接口要求；

c)   开发并验证满足软件安全要求的软件架构设计；

d)   按照软件架构设计、设计准则和所分配的支持软件单元实施和验证的软件要求，开发并实现软件单元设计；

e)   验证软件单元设计满足分配的软件要求且适合于实施，证明实现的软件单元符合单元设计并满足分配的软件要求；

f)   定义集成步骤并集成软件要素，验证集成的软件单元和集成的软件组件符合软件架构设计要求；

g)   验证嵌入式软件满足安全相关要求；

h)   定 义系统修改软件更新相关要求。

4.2 总则

如图4 .1 所示，本规范为自动驾驶系统软件安全设计列出的要求和建议，规范内容包括软件层面开发总体要求、软件安全要求的定义、软件架构设计、软件单元设计和实现、软件单元验证、软件集成验证、嵌入式软件测试，软件更新要求定义等。

图 4.1 本规范整体架构

4.3 软件开发融合安全原理

如图4 .2 所示，为软件开发阶段参考模型。软件开发阶段根据技术安全概念导出软件安全要求，其次进行软件架构设计和软件单元设计和实现，最后进行相关测试验证及软件更新。

图 4.2 软件开发融合安全开发流程

5 软件层面开发总体要求

5.1 软件层面开发总体要求概述

本章对软件开发提出整体要求，确保合适的软件开发流程和软件开发环境，并提出质量要求。在本章主要内容包括开发过程和环境要求、软件语言要求、开发流程要求、软件质量要求、缺陷数据要求和开发过程质量要求。

5.2 开发过程和环境

5.2.1 在开发相关项的软件时，使用的软件开发过程和软件开发环境应：

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

b)   支持软件开发生命周期中的各跨子阶段和各自工作成果的一致性；

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

注1： 相关项软件开发的阶段、任务和活动的排序，包括迭代步骤，目的是确保相应的工作成果与硬件层面的产品开发和系统层面的产品开发保持一致。

注2： 软件工具准则评估报告或软件工具的鉴定报告可以为工具的使用提供输入。

5.3 软件语言

5.3.1 当选择一种设计语言、建模语言或编程语言时，应考虑准则：

a)   明确易理解的定义；

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

b)   如果建模用于需求工程和管理，定义和管理安全要求的适用性；

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

d)   支持结构化构造的使用。

e)   支持使用安全设计和实施技术

f)   用于网络安全规范或其实施时，具有整合其他组件的能力

示例： 用另一种语言编写的库、框架、软件组件。

g)   语言的复原力，防止因使用不当而出现漏洞

示例： 对缓冲区溢出的复原力。

注： 汇编语言能用于那些不适合高级编程语言的软件部分，如与硬件接口的底层软件、中断处理程序、或对时间敏感的算法。然而，使用汇编语言可能需要对所有软件开发阶段进行适当的应用或剪裁。

5.3.2 考虑到表 5 中列出的主题，相应的指南或者开发环境应涵盖适合于软件安全建模、设计或编程语言（见 5.3.1 ）的准则，并且这些准则并不完全由语言自身决定。

示例1： MISRA C 是C语言编程的编码指南，并包括自动生成代码的指南。

示例2： 在具有自动代码生成功能的基于模型的开发中，可以在模型层面以及代码层面中应用该指南。可以考虑适当的建模风格指南，包括 MISRA AC 系列。商业工具的风格指南也可作为可能的指南。

注： 可以为特定的相关项开发修改现有的编码指南和建模指南。

表 5 建模和编码指南涵盖的主题

5.4 开发流程严谨

5.4.1 论据应证明物品的设计质量和开发过程的质量符合生产可接受的安全物品的相关最佳实践。

a)   定义并可接受的过程模型（请参阅第 5.3.2-5.3.5 节）

b)   系统质量（请参阅第 5.4 节）

c)   缺陷数据（请参阅第 5.5 节）

d)   开发过程质量（请参阅第 5.6 节 ）

5.4.2 项目开发过程应定义并映射到可信且可接受的高关键性开发过程模型上。

a)   定义的过程活动包含已确定的具有适当高关键性的参考过程模型中的所有实质性步骤和工件步骤和工件。

示例： 提供证据表明， IEC 61508 所定义的 V 模型的所有元素都包含在所定义的过程中，包括所有相关的活动和所有已定义的设计工件。 ( 或者，与 ISO 26262 相同。 )

注意： 可接受的参考过程模型包括为可接受的领域安全标准定义的模型，不需要符合 IEC 61508 ，仅作为示例。

b)   开发过程活动都被标识为已定义的任务 具有不同的入口点、出口点和活动之间的转换标准。

注意： 这并不意味着活动必须按顺序进行，也不禁止活动的分阶段性转换、迭代和其他结构化。然而，这个提示元素确实意味着可以审计是否确实有一个任务定义，以及该活动是否按照任务定义执行。

c)   每个定义的开发过程活动都会产生定义的，可审核的工作产品工件

d)   所有与安全相关的活动和工作产品均已指定，并提供给评估人员。

注意： 这包括开发过程和项目质量的各个方面，甚至部分包括本项目的安全相关方面。

e)   工作产品包括技术工件

f)   流程活动至少包括

1)   物品等级

注意： 这包括适用于车辆范围之外但在本项目范围内的数据源、服务馈源和其他软件和系统的质量度量。

2)   系统级

3)   软件

4)   电气和电子硬件

5)   安全

注意： 安全活动是纳入其他过程还是一个单独的过程是灵活的。

6)   网络安全

5.4.3 整个项目系统和软件开发过程应纳入并遵守与领域相关的最佳实践。

a)   确定已整合到每个流程活动和工作产品工件中的最佳实践

注： 本条款并不限于本产品的安全相关方面。它适用于整个产品，包括项目和任何影响非安全相关的方面。

5.4.4 定义的系统和软件开发过程应包含有关安全相关元素的最少必需的最佳实践集

a)   明确的物品等级安全要求

b)   对定义的安全要求，模型，设计，实施和测试计划进行有效的同行评审

注： “ 有效 ” 意味着有证据支持同行评审实际上发现了在 V &V 过程中发现的所有缺陷的很大一部分

c)   定义和评估有效性的配置管理和版本控制流程和实践

d)   定义质量保证过程和实践并评估有效性

e)   项目级别测试，以验证是否满足可测试的安全相关要求。

注意： 对任何无法测试的需求的满足都必须以其他方式进行验证

f)   由进行缺陷校正的人员以外的其他人检查缺陷清除情况。这包括推迟缺陷校正或在下一个项目发布之前不校正缺陷的决定。

g)   解决开发环境和部署环境之间的差异。

示例： 开发系统和部署系统之间的不同级别的数字精度水平， 由 于 移除 测 试设备而导致的时间差异，在测试室中运行的系统的模拟环境和真实环境之间的差异。

h)   记录并证明与已确定的最佳做法的偏差

1)   与确定的最佳实践的所有偏差均由至少两个不同的人通过协议批准，涉及不重要的审查和决策过程

2)   对于与安全相关的要素和功能，不允许与确定的最佳做法进行全面，重复和其他系统的偏离。

注意： 预期与已确定的最佳做法的偏离是由于独特的，真正的一次性情况造成的，而不是简单地用作绕过不便但已确定的最佳做法或无限期推迟问题纠正的方法。

i)   最佳实践的偏离被确定为事件或不幸事故的成因，导致对该实践的所有现有偏离的偏离批准被撤销，除非并且直到这些偏离被单独重新审查和重新批准为止。

5.4.5  对于安全相关要素，应确保可接受的项目质量和项目开发过程质量。

a)   可客观评估的证据表明，对于所需的严格程度或所采用的其他风险缓解方法，项目质量是可以接受的。

b)   同行评审的证据和同行评审的有效性

c)   可接受的项目级别和软件级别测试结果的证据

d)   可接受的符合开发过程的证据

示例 ： SQA 审核记录显示符合开发流程

e)   符合已定义的编码样式标准的证据

f)   具有定义的分析配置文件的可接受源代码分析结果的证据

示例： 符合 MISRAC 。

5.5 软件质量

5.5.1  应为安全相关软件定义软件质量接受标准。

a)   确定工件质量验收标准

示例： 指定级别的 MCDC 单元测试覆盖范围，从测试计划到要求的可追溯性，发布时每 1000 行源代码中没有超过 X 个已发现缺陷的软件 ( 这意味着具有高缺陷密度的模块已经过重新设计和重写 ) 。

注意： 所提供示例的有效性将取决于相关性客观证据的可用性。论据可能基于开发团队的历史预测能力或对特定领域标准要求的遵守。

b)   可接受质量的专用软件

1)   软件质量活动中包含的自治功能的基础代码

例： 用于执行带有其学习的体重数据集的神经网络的运行时引擎软件的质量可以经过常规软件质量处理

c)   确定基于流程的软件质量验收标准

示例： 同行评审的有效率 ( 例如，通过同行评审发现的发布前缺陷的 50% 以上 ), 同行评审的覆盖率 ( 例如同行评审的新代码的 100%), 过程完成率 ( 例如，对所需工件进行抽查的百分比通过 SQA)

d)   可接受的重复使用和第三方软件质量

示例： 用于支持机器学习应用程序的开源框 架和库。

5.5.2  必须为安全相关元素，子系统和整个物品定义物品质量验收标准。

a)   可接受的软件质量

1)   软件质量活动中包含的自治功能的基础代码

示例： 用于执行机器学习开发活动结果的运行时引擎

2)   其他软体

b)   可接受的计算硬件质量

c)   传感器，执行器和其他物品的可接受质量

d)   可接受的第三方组件质量，至少包括：

1)   操作系统 ( 如果使用 )

2)   最终项目中包含的库 ( 如果使用 )

3)   其他 COTS/SOUP 和旧版组件

4)   远程软件功能 ( 如果使用 )

示例： 基础设施数据源，其他项目数据源，远程操作系统

5)   在线服务 ( 如果使用 )

示例： 基于云的地图数据，天气报告供稿

e)   通过以下至少一项支持的安全相关元素的质量：

1) 经独立评估符合本标准

2) 独立评估是否符合另一领域相关安全标准

例子： ISO 26262, MIL-STD-882E

注意： 仍然必须按照此或其他相关安全标准来进行基于“经验证的使用”或其他方法的争论，这些争论最初不是为安全相关功能而创建的。

5.6 缺陷数据

5.6.1 应当收集，分析缺陷数据，并将其用于改进产品和过程。

a)   定义的过程步骤或其他事件，用于开始记录每种工件的故障数据。

b)   为开发阶段和部署阶段的缺陷定义了根本原因分析程序。

c)   根本原因分析程序明确包括缺陷指示安全案例，过程和 / 或安全文化中潜在缺陷的可能性，并支持对此类潜在缺陷的纠正。

d)   记录缺陷和故障数据，分析根本原因，并跟踪直至 关闭。

5.7 开发过程质量

5.7.1 开发过程质量应可接受。

a)   定义和评估软件质量保证活动的组织和过程的有效性。

b)   定义和评估安全保证活动的组织和过程的有效性。

c)   定义的软件质量保证 (SQA) 流程和实践，至少包括以下软件开发和安全领域的内容：

1)   定义的开发，部署和现场工程反馈流程

2)   培训规定的过程

3)   流程一致性审核

4)   记录(和/或验证)分配任务的技术技能能力

6 软件安全要求的定义

6.1 软件安全要求的定义概述

本章的目的是：定义或细化由技术安全概念和系统架构设计规范导出的软件安全要求；定义软件实现所需的安全相关功能和特性；细化软硬件接口要求；验证软件安全要求和软硬件接口要求是否适用于软件开发，及验证它们与技术安全概念和系统架构设计规范的一致性。如图 6.1 所示，本章根据系统层面技术安全要求、技术安全概念、系统架构设计的输出进行软件安全要求定义，软件安全要求分解、软硬件接口规范要求定义和嵌入式软件安全要求定义。

图 6.1 软件安全要求定义流程

6.2 软件安全要求导出

6.2.1 软件安全要求得出时，应考虑所需的安全相关的软件功能和特性，其失效可能违背给分配给软件的技术安全要求。

注1： 软件安全要求或者直接来源于分配给软件的技术安全要求，或者是对软件功能和特性的要求（这些要求如果不满足可能违背分配给软件的技术安全要求）。

示例1： 软件安全相关功能可以是：

——使标称功能可以安全执行的功能；

——使系统达到或维持安全状态或降级状态的功能；

——与安全相关硬件要素故障探测、指示和减轻相关的功能；

——与操作系统、基础软件或应用软件本身失效探测、指示和减轻有关的自检或监控功能；

——在生产、运行、服务和报废过程中与车载测试和非车载测试相关的功能；

——允许在生产和服务过程中对软件进行修改的功能；或

——与性能或对时间敏感的操作相关的功能。

示例2： 安全相关的特殊特性包括对错误输入的鲁棒性、不同功能之间的独立性或免于干扰、或软件的容错能力。

注2： 安全导向分析可用于识别额外的软件安全要求或为其实现提供证据。

6.3 软件安全要求定义

6.3.1 软件安全要求的定义应按照系统设计中的技术安全要求、技术安全概念和系统架构设计得出，并应考虑如下内容：

a)   安全要求的定义和管理；

b)   已定义的系统和硬件的配置；

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

c)   软硬件接口规范；

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

e)   时间约束；

示例 2 ： 由系统层面要求的响应时间得出执行或反应时间。

f)   外部接口；

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

g)   对软件有影响的车辆、系统或者硬件的每一个运行模式以及运行模式之间的转换。

示例4： 运行模式包括下电或休眠、初始化、正常运行、降级和用于测试或刷新的其他高级模式。

6.4 软件安全要求分解

6.4.1 如果对软件安全要求进行了 ASIL 等级分解，应满足 GB/T 34590.9-2022 第 5 章的要求。

6.5 软硬件接口规范要求

6.5.1 在系统设计阶段初步定义的软硬件接口规范，应细化到可以通过软件正确控制和使用硬件的程度，并应描述硬件和软件间每个与安全相关的依赖性。

6.5.2 应由负责系统开发、硬件开发和软件开发的人员共同验证细化后的软硬件接口规范。

6.5.3 应照 GB/T 34590.8-2022 第 6 章和第 9 章的要求，对软件安全要求和细化后的软硬件接口规范进行验证，以提供证据证明：

a)   软件开发的适用性；

b)   与技术安全要求的符合性和一致性；

c)   与系统设计的符合性；

d)   与软硬件接口的一致性。

6.6 嵌入式软件要求

6.6.1 如果嵌入式软件除了执行 6.1 定义的安全要求的功能外，还执行了其他功能，则应按照所应用的质量管理体系的要求提供这些功能及其特性的规范。

7 软件架构设计

7.1 软件架构设计要求概念

本章的目的是开发满足软件安全要求和其他软件要求的软件架构设计；验证软件架构设计适合满足所要求的A SIL 等级的软件安全要求；支持软件的实现与验证。如图7 .1 所示本章主要内容包括软件架构设计要求、软件安全要求分配、软件分区要求、安全导向分析、嵌入式软件要求和软件架构设计验证。

图 7.1 嵌入式软件测试流程

7.2 软件架构设计要求

7.2.1 为避免软件架构设计和后续开发活动中的系统性故障，软件架构设计的描述应满足表 6 中列出的软件结构设计标记法所支持的特征：

a)   可理解性；

b)   一致性；

c)   简单性；

d)   可验证性；

e)   模块化；

f)   抽象性；

注： 抽象性可以通过使用层次化结构、分组方案或视图来支持，以涵盖架构设计的静态、动态或部署方面。

g)   封装性；

h)   可维护性。

表 6 软件架构设计标记法

7.2.2 在软件架构设计开发中，应考虑下述方面：

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

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

b)   可配置软件的适用性；

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

d)   软件集成测试中软件架构的可测试性；

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

7.2.3 为避免系统性故障，应使用表 7 列出的原则，使软件架构设计具有以下特征：

a)   可理解性；

b)   一致性；

c)   简单性；

d)   可验证性；

e)   模块化；

f)   封装性；

g)   可维护性。

表 7 软件架构设计原则

注1： 基于表3所列原则的适当折中是必要的，因为这些原则不互相排斥。

注2： 高复杂度的指标可以是：

——高度分支化的控制流或数据流；

——分配给单个设计要素的要求过多；

——某个设计要素的接口过多或设计要素之间的交互性过多；

——参数类型复杂或过多；

——全局变量过多；

——难以为错误探测和处理的合适性和完整性提供证据；

——难以达到要求的测试覆盖率；或

——只有少数专家或项目参与者能够理解。

注3： 这些特性和原则也适用于软件例行程序（例如中断处理的服务例行程序）。

7.2.4 软件架构设计应开发到能够识别出软件单元的程度

7.2.5 软件架构设计应描述：

a)   软件架构要素的静态设计方面；

注 1 ： 静态设计方法涉及：

—— 包括分级层次的软件结构；

—— 数据类型和它们的特征参数；

—— 软件组件的外部接口；

—— 嵌入式软件的外部接口；

—— 全局变量；

—— 包括架构的范围和外部依赖的约束。

注 2 ： 在基于模型的开发的情况下，结构建模可能是整个建模活动的固有部分。建模的结构可能取决于所选的建模语言。

b)   软件架构要素的动态设计方面。

注 3: 动态设计方面涉及：

—— 事件和行为的功能链；

—— 数据处理的逻辑顺序；

—— 控制流和并发过程；

—— 通过接口和全局变量传递的数据流；

—— 时间的限制。

注 4 ： 为确定动态行为（例如，任务 、时间片和中断），需要考虑不同的运行状态（例如，开机、关机、正常运行、标定和诊断）。

注5： 为描述动态行为（例如，任务、时间片和中断），需要定义通讯关系及其在系统硬件（例如， CPU 和通信通道）上的分配。

7.3 软件安全要求分配

7.3.1 软件安全要求应按层次分配给软件组件，直至软件单元。因此每个软件组件应按照分配给它的任何需求的最高的 A SIL 等级来进行开发。

注： 在设计开发和要求分配过程中，可能需要按照第 6 章对软件安全要求进行拆分或进一步细化。

7.3.2 如果复用一个没有按照本规范进行开发的得未修改得现有软件架构要素，为满足分配的安全要求，则应按照 GB/T 34590.8-2022 第 1 2 章的要求进行鉴定。

注： 按照本规范开发的复用软件要素的适用性可在软件架构设计验证阶段来实现。

7.3.3 如果嵌入式软件不得不实现不同 A SIL 等级的软件组件，或实现相关及非安全相关的软件组件，除非软件组件符合 G B/T 34590.9-2022 第 6 章定义的共存准则，否则全部嵌入式软件应按照最高 ASIL 等级来处理。

7.4 软件分区要求

7.4.1 如果软件分区（见附录 B ）实现软件组件间免于干扰，那么应确保：

a)   共享资源的使用方式应确保软件分区免于干扰；

注 1 ： 一个软件分区内的任务彼此之间不能免于干扰。

注 2 ： 一个软件分区不能改变其他软件分区的代码或数据，也不能控制其他软件分期的非共享资源。

注 3 ： 一个软件分区从共享资源获取的服务不能被另一个软件分区影响。这包括相关资源的性能，以及对资源调度访问的使用率、延迟、抖动和持续时间。

b)   由专用的硬件特性或等效方法来支持软件分区（该要求适用于 ASIL D 等级）

示例： 存储器保护单元等硬件特性。

c)   实现软件分区的软件要素是根据分配给分区软件任何要求的最高 ASIL 等级开发的；

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

d)   软件分区有效性的证据会在软 件集成和验证期间生成。

7.5 安全导向分析

7.5.1 应按照 GB/T 34590.9-2022 第 8 章在软件层级执行安全导向分析，目的是：

——提供软件的适用性证据证明具备了相应的A SIL 等级要求所需的特定的安全相关功能和特性；

注1： 安全相关的特殊特性包括独立性和免于干扰。

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

——支持安全措施的定义并验证其有效性。

注2： 安全措施包括从安全导向分析中得出的安全机制，并可涵盖与随机硬件失效和软件故障有关的问题。

注3： 关于在软件架构层级运用安全导向分析和选择适当安全措施的更多信息，见附录 D 。

7.5.2 如果软件安全要求的实现依赖于软件组件间免于干扰或足够的独立性，则应按照 GB/T 34590.9-2022 第 7 章进行相关失效及其影响分析。

注： 在软件架构层级应用相关失效分析的更多信息，见附录 D 和 GB/T 34590.9-2022 附录C。

7.5.3 应根据软件架构层级安全导向的分析结果，采用错误探测和错误处理的安全机制。

注1： 附录 D 提供了判断失效模式是否需要安全机制的指导。

注2： 用于错误探测的安全机制包括：

——输入输出数据的范围检查；

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

——数据错误探测（例如，检错码和多重数据存储）；

——外部要素监控程序执行，例如，通过专用集成电路（A SIC ）或者其他软件要素来执行看门狗功能。监控可以是逻辑监控或时间监控，或者两者的结合；

——程序执行的时间监控；

——设计中的异构冗余；或

——在软件或硬件中实施的访问冲突控制机制，与授权访问或拒绝访问安全相关共享资源有关。

注3： 用于错误处理的安全机制可能包括：

——为了达到和维持安全状态的功能关闭；

——静态恢复机制（例如，恢复快、后向恢复、前向恢复以及通过重试来恢复）；

——通过划分功能的优先级进行平稳降级，从而最小化潜在失效对功能安全的不利影响；

——设计中的同构冗余，主要侧重于控制运行相似软件的硬件中瞬态故障或随机故障的影响（例如，软件在时间上的冗余执行）；

——设计中的异构冗余，意味着在每个并行路径中使用不同软件，主要侧重于预防或控制软件中的系统性故障；

——数据纠错码；或

——在软件或硬件中实施的访问许可管理，与授权访问或拒绝访问安全相关共享资源有关。

注4： 可在系统层面对软件安全机制（包括一般的鲁棒性机制）进行评审，以分析其对系统行为的潜在影响与技术安全要求的一致性。

7.6 嵌入式软件要求

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

a)   执行时间；

b)   存储时间；

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

c)   通信资源。

7.7 软件架构设计验证

7.7.1 软件架构设计应按照 GB/T 34590.8-2022 第 9 章进行验证，并使用表 8 中所列出的软件架构设计验证方法，为实现下列目标提供证据：

a)   软件架构设计满足对应 ASIL 等级的软件安全要求；

b)   软件架构设计的评审或研究能够为设计满足对应 ASIL 等级的软件安全要求提供证据；

c)   与目标环境的兼容性；

注： 目标环境是指软件运行的环境，包括了操作系统、基础软件以及硬件目标及其资源。

d)   与设计指南保持一致。

表 8 软件架构设计验证方法

8 软件单元设计和实现

8.1 软件单元和实现要求概述

本章的目的是按照软件架构设计、设计准则和所分配的支持软件单元实施的验证的软件要求，开发软件单元设计；实现所定义的软件单元。本章主要内容包括适用范围定义、软件单元定义要求、软件单元验证要求和源代码层面设计原则。

8.2 适用范围

8.2.1 如果软件单元是安全相关要素，应符合本子阶段中的要求。

注： “安全相关”指该单元要实现安全要求，或该单元不满足于其他单元的共存准则（见G B/T 34590.9-2022 第6章）。

8.3 软件单元定义要求

8.3.1 软件单元的定义应将功能表现和内部设计描述到必要的详细层级以支持其实现。

示例： 内部设计可包含对寄存器使用和数据存储的限制。

8.4 软件单元设计要求

8.4.1 软件单元设计和实现应：

a)   适用于满足分配给具有 ASIL 等级的软件单元的软件要求；

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

c)   符合软硬件接口规范，如果适用。

示例： 与其他软件单元接口的一致性和完整性；输入或输出数据的正确性、准确性 和及时性。

8.4.2 为避免系统性故障并确保软件单元设计具有以下特性，软件单元设计应使用表 9 中列出的标记法进行描述。

a)   一致性；

b)   可理解性；

c)   可维护性；

d)   可验证性。

表 9 软件架构设计标记法

注： 在应用自动代码生成的基于模型的开发的情况下，将软件单元设计的表示方法，用于作为代码生成基础的模型中。

8.5 源代码层面设计原则

8.5.1 应用表 1 0 列出的源代码层面软件单元设计和现实的设计原则，以具有如下特征：

a)   基于软件架构设计，软件单元内的子程序和函数执行的正确次序；

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

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

d)   简单性；

e)   可读性和可理解性；

f)   鲁棒性；

示例： 避免不合理值、执行错误、以零做除数、数据流及控制流错误的方法。

g)   软件修改的适宜性；

h)   可验证性。

表 10 软件单元设计和实现的设计原则

注： 对于 C 语言来说， MISRA C 涵盖了表 10 列出的很多原则

9 软件单元验证

9.1 软件单元验证概述

本章的目的是：提供证据证明软件单元设计满足分配的软件要求且适合于实施；验证安全分析得出的安全措施得到适当实施；提供证据证明所实现的软件单元符合单元设计，并满足根据所需的A SIL 等级分配的软件要求；提供充分证据，证明软件单元不包含与功能安全相关的非预期功能和特性。如图9 .1 所示，本章的主要内容包括：软件单元验证范围、软件单元验证方法、软件单元测试用例要求、软件单元测试覆盖率和软件单元测试环境。

图 9.1 软件单元测试流程

9.2 软件单元验证范围

9.2.1 如果软件单元是安全相关要素，则应符合本条的要求。

注1： 按照 GB/T 34590.1 的定义，“安全相关要素”是指该单元实现安全要求，或此单元与其他单元的共存准则（见G B/T 34590.9-2022 第6章）。

注 2 ： 本章的要求针对安全相关的软件单元；其他软件标准（见G B/T 34590.2-2022 中5 .4.5.1 ）可用于其他软件单元的验证。

注3： 对于基于模型的软件开发，模型实现的相应部分也是验证计划的对象。根据所选的软件开发流程，验证对象可以是从该模型生成的代码、模型本身或两者都包含。

9.3 软件单元验证方法

9.3.1 应按照 GB/T 34590.8-2022 第 9 章的规定，通过表 11 所示方法的适当组合，对软件单元设计和已实现的软件单元进行验证，以提供证据证明：

a)   符合第 9 章中有关单元设计和实现的要求；

注 1 ： 软件安全要求包括软件的功能和特性。

注 2 ： 在模型层面执行验证可以替代在源代码层面执行验证，如果代码生成保留模型的特性（例如，所使用的代码生成器有足够的置信度）。

示例： 有效实施错误检测和错误处理机制的证据，以实现软件单元对错误输入的鲁棒性。

b)   源代码与其设计规范的符合性；

注 3 ： 在基于模型的开发的情况下，要求 d ）仍然适用；

c)   符合软硬件接口规范，如果适用；

d)   确信没有非预期功能和特性；

e)   足够的资源支持其功能和特性；

f)   实施由安全导向分析得出的安全措施。

表 11 软件单元验证方法

9.4 软件单元测试用例

9.4.1 应使用表 1 2 列出的方法得到测试用例，以恰当定义符合 1 0.3.1 的软件单元测试的测试用例。

表 12 软件单元测试用例的得出方法

9.5 软件单元测试覆盖率

9.5.1 为了评估验证的完整性并提供证据证明已充分实现单元测试目标，应确定在软件单元层面的要求覆盖率，同时应按照表 1 3 列出的度量对结构覆盖率进行测定。如果认为已实现的结构覆盖率不充分，应定义额外的测试用例或提供基于其他方法的理由。

注1： 在没有理由情况下，结构覆盖率无目标值或低目标值被认为是不充分的。

示例1： 结构覆盖率分析可以显示基于要求的测试用例的不足、要求的缺陷、无作用码、无效代码或非预期功能。

示例2： 对于可接受的死代码(例如，用于调试的代码 ) 或不同软件配置的代码区段，可以给出接受所达到的覆盖率水平的理由，或可以使用补充方法（例如，检查）验证未被覆盖的代码。

示例3： 理由可基于最新技术水平。

表 13 软件单元层面的结构覆盖率度量

注2： 通过使用适当的软件工具可以确定结构覆盖率。

注3： 在基于模型的开发的情况下，结构覆盖率分析可以利用相似的模型结构覆盖率度量在模型层面运行。

注4： 如果“检测代码”用于确定结构覆盖率水平，则有必要提供证据，证明检测对测试结果没有影响，这可能通过使用“非检测代码”重复测试具有代表性的测试用例实现。

9.6 软件单元测试环境

9.6.1 对于软件单元测试的测试环境，应考虑目标环境从而使其适合于达到单元测试的目的。如果软件单元测试不是在目标环境下执行，应分析源代码和目标代码的差异及测试环境和目标环境之间的差异，以便在后续测试阶段的目标环境中，定义额外的测试。

注1： 测试环境和目标环境之间的差异，可出现在源代码或目标代码中，例如，由于不同处理器的数据字和地址字的不同位宽引起的差异。

注2： 根据测试范围，使用适当的测试环境（例如，目标处理器、处理器仿真器或开发系统）执行软件单元测试。

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

——模型在环测试

——软件在环测试

——处理器在环测试；或

——硬件在环测试。

注4： 对基于模型的开发，在模型层面执行软件单元测试，随后，在模型和目标代码之间进行背靠背的比较测试。对于测试目标而言，背靠背比较测试用于确保模型与自动生成的代码的行为是一致的。

10 软件集成和验证

10.1 软件集成和验证概述

本章的目的是：定义集成步骤并集成软件要素，直至嵌入式软件完全集成；验证由软件架构层面的安全分析得出的已定义的安全措施得到适当实施；提供证据证明集成的软件单元和集成的软件组件符合软件架构设计的要求；提供充分证据，证明集成软件不包含与功能安全相关的非预期功能和特性。本章主要内容包括软件集成方法要求、软件集成验证要求、软件集成测试用例要求、嵌入式软件验证要求和软件集成测试环境要求。

10.2 软件集成方法要求

10.2.1 软件集成的方法应定义和描述将各个软件单元分层集成到软件组件中的步骤，直到整个嵌入式软件全部被集成，并应考虑：

a)   与 11.3.1 中规定的验证目标实现的相关性；

b)   与软件集成相关的功能相关性；

c)   软件集 成和软硬件集成之间的相关性。

注： 对基于模型的开发，软件集成可被模型层面的集成和后续由集成的模型生成自动代码来代替（见 GB/T 34590.6-2022 附录 A ）。

10.3 软件集成验证

10.3.1 应按照 G B/T 34590.8-2022 第 9 章的要求，通过表 1 4 提供方法的适当组合，验证软件集成，以证明分层集成的软件单元、软件组件和集成的嵌入式软件实现：

a)   与软件架构设计的符合性，按照第 8 章；

b)   与软硬件接口规范的符合性。

c)   已定义的功能；

d)   已定义的特性；

示例：由于不存在无法访问的软件而产生的可靠性、对错误输入的鲁棒性、由于有效的错误检测和处理而产生的可靠性。

e)   支持功能的足够资源；

f)   按照 7.5.1 和 7.5.2 的安全导向分析得出的安 全措施的有效性，如果适用。

注1： 安全措施可包括软件分区。

表 14 软件集成验证方法

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

10.4 软件集成测试用例要求

10.4.1 为了能够给按照 1 0.4.1 选择的软件集成测试方法定义恰当的测试用例，应使用表 1 5 所列的方法。

表 15 软件集成测试用例的得出方法

10.4.2 为了评估验证的完整性并提供证据证明已充分实现集成测试的测试目标，应确定测试用例在软件架构层级对要求的覆盖率。如有必要，应规定额外的测试用例，或提供基于其他方法的理由。

10.4.3 为了评估测试用例的完整性，并提供证据证明已充分实现集成测试的测试目标，应按照表 1 6 列出的方法来评估结构覆盖率。如果实现的结构覆盖率被认为是不充分的，应定义额外的测试用例或提供基于其他方法的理由。

示例： 结构覆盖率分析可以显示基于需求的测试用例的不足、要求的缺陷、无作用码、无效代码或非预期功能。

表 16 软件架构层级的结构覆盖率

注1： 通过适当的软件工具可确定结构覆盖率。

注2： 在基于模型的开发中，可以使用模型的类似结构覆盖率度量在模型层面执行软件集成测试。

10.5 嵌入式软件验证

10.5.1 应验证作为生产发布一部分的嵌入式软件包含了全部已定义的功能和特性，且仅包含不损害软件安全要求符合性的未定义功能。

示例： 在此上下文中，未定义的功能包括用于调试或检测的代码。

注： 如果可确保这些未定义的功能不被执行，这是一种符合本要求的可接受方法，否则就要做变更（见G B/T 34590.8-2022 第8章）将这些代码移除。

10.6 软件集成测试环境要求

10.6.1 软件集成测试的测试环境，应考虑目标环境从而使其适合于达到集成测试的目的。如果集成测试没有在目标环境中执行，应分析源代码和目标代码之间的差异以及测试环境和目标环境之间的差异，来定义后续测试阶段中在目标环境中的附加测试。

注1： 测试环境与目标环境之间的差异可出现在源代码或目标代码中，例如，由于不同处理器的数据字和地址字的不同位宽引起的差异。

注2： 根据测试范围和集成的层级，使用适当的测试环境进行软件要素测试。这些测试环境可以是用于最终集成的目标处理器，或者是用于之前集成步骤的处理器模拟器或开发系统。

注3： 软件集成测试可在不同环境中执行，例如：

——模型在环测试；

——软件再换测试；

——处理器在环测试；或

——硬件在环测试。

11 嵌入式软件测试

11.1 嵌入式软件测试概述

本章的目的是证明嵌入式软件在目标环境执行时满足安全相关要求。如图 11.1 所示本章对嵌入式软件测试环境、测试方法、测试用例和测试结构四方面提出要求。

图 11.1 嵌入式软件测试流程

11.2 嵌入式软件测试环境要求

11.2.1 为了验证嵌入式软件在目标环境中是否满足软件安全要求，应在表 1 7 所列的适当测试环境中进行测试，并按照 G B/T 34590.8-2022 第 9 章的要求。

注3： 可以复用已有的测试用例，如来自软件集成测试的测试用例。

表 17 用于执行软件测试的测试环境

11.3 嵌入式软件测试方法

1 1.3.1 嵌入式软件的测试应采用表 1 8 所列的方法进行，以提供证据证明嵌入式软件满足其各自 A SIL 等级要求的软件要求。

表 18 嵌入式软件的测试方法

11.4 嵌入式软件测试用例

11.4.1 为了能够按照 1 1.2.1 的要求执行软件测试而定义适当的测试用例，应使用表 1 9 中列出的方法得出测试用例。

表 19 嵌入式软件测试用例的得出方法

11.5 嵌入式软件测试结果

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

a)   与期望结果的一致性；

b)   软件安全要求的覆盖率。

这包括配置和标 定范围的覆盖率。应满足附录 B 的要求。

12 软件更新

12.1 软件更新概述

根据预期功能安全活动中软件相关系统修改要求，对软件进行更新。如图 12.1 所示，软件更新包括软件架构更新、软件单元更新、软件更新验证。本章介绍了软件更新所用方法。

图 12.1 软件更新流程

12.2 软件架构更新

1 2.2.1 可考虑使用以下方法对整体软件设计的优化，提升系统性能，确保系统的预期功能得以保持：

a)   模块化和分层架构；

注 1 ： 将软件系统划分为多个功能模块或层次，使得每个模块可以独立开发、测试和优化，不同算法可以在不同模块中并行工作。

示例 1 ： 将数据处理和业务逻辑分离，独立优化数据处理模块的性能。

b)   数据融合架构；

注 2 ： 设计一个数据融合架构来整合来自不同传感器的数据（如相机、雷达、 LiDAR ），提升系统对多种输入信息的处理能力和性能。

c)   引入微服务架构；

注 3 ： 将单体应用拆分为多个微服务，每个微服务负责不同的功能或服务。这样可根据需要独立扩展和优化特定服务，从而提高整体性能。

d)   采用分布式系统；

注 4 ： 使用分布式计算和存储技术（如分布式数据库、负载均衡器）来提高系统的处理能力和响应速度。

e)   集成现代架构模式。

示例 2 ： 使用事件驱动架构（ EDA ）来处理异步事件，减少系统的延迟和提高响应速度。

12.3 软件单元更新

12.3.1 可考虑使用以下方法对系统中具体模块或组件的改进，以提高单个功能的性能并保持预期功能。

a)   优化算法和数据结构；

注 1 ： 更新和优化关键算法和数据结构（如哈希表、树形结构）以减少计算复杂度和内存占用。

示例 1 ： 优化深度学习模型的计算图以更好地支持 GPU 或 TPU 加速。

b)   功能增强；

注 2 ： 对识别算法进行更新，以处理超出当前操作设计域（ ODD ）的情况。

示例 2 ： 通过增加新的识别特征或扩展现有模型来识别高速公路出口坡道。

c)   条件适配；

注 3 ： 更新识别算法，以适应已知的环境条件（如太阳眩光）。

示例 3 ： 新的图像处理技术或环境感知模块的改进。

d)   引入缓存机制 ；

注 4 ： 为频繁访问的数据引入缓存层（如内存缓存、分布式缓存），以加速数据读取和处理。

e)   改进并发处理；

注 5 ： 优化多线程和并发处理机制，使用异步编程和任务队列来提高系统的吞吐量和响应时间。

f)   利用硬件加速 ；

注 6 ： 更新软件以支持新硬件（如 GPU 、 TPU ）进行加速，提升图像处理、深度学习等 计算密集型任务的效率。

12.4 软件更新验证

1 2.4.1 使用以下措施，确保软件更新能有效提升性能，同时保持预期功能，并且不会引入新的问题。

a)   性能基准测试 ；

注 1 ： 在更新前后进行性能基准测试，比较系统的准确度和速度等指标，确保更新带来了性能提升。

b)   回归测试；

注 2 ： 运行全面的回归测试用例，验证系统的各项功能在更新后依然正常工作。

c)   集成测试；

注 3 ： 验证整合新的输入信息后的模型性能，确保系统能够处理新增的信息而不会导致性能下降。

d)   场景测试；

注 4 ： 在各种实际场景中测试系 统的表现，以验证 更新后软件 的有效性。

附录 A 基于模型的开发方法

A.1 目的

本附录阐述了软件层面开发过程中基于模型的开发方法的可能收益和潜在问题。

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

A.2 总则

本条提供了 MBD 各种用例（例如，要求、设计、验证 / 测试）共有的基本信息。 A.3 提供了基于示例性用例的特殊考虑。

A.2.1 引言

模型可被用来表示开发阶段所需的信息或信息视图，以及用于表示一个或多个软件要素或软件环境的抽象设计及实现。模型本身可能包含多种细化的层级或在较低层级引用细化的模型（例如，每个模型要素具有黑盒和白盒视图的层次结构）。模型是使用建模标记法来开发的。

建模标记法可以是图形和 / 或文本，可以是形式化（例如，具有基本数学定义的标记法）或半形式化（例如，非完备定义语义的结构化标记法）。建模标记法可以是国际标准（如 UML® ）或公司特定的，一般基于如类、框图、控制图或状态表（表示状态和状态间的转换）等概念。在本附录中，只考虑了模型和建模标记法，包含了足够用于其预期用途的已定义的语法和语义（即：没有此类定义的示意图不被视为模型）。除了使用 MBD 的特定原因（例如，仿真和代码生成）外，特别是当不同成员协作时，充分定义的语法和语义是达成以下准则的基础，如可理解性、明确性、正确性、一致性和使用模型描述的信息或工作成果的可验证性。

除了建模标记法外，建模指南和 / 或合适的工具是达成充分定义的语法、语义和符合建模指南的手段。

示例： 作为指南的一部分，命名规则或风格指南支持了诸如 “ 可理解 ” 准则的实现，而排除模糊结构的语言子集选择同时支持了 “ 可理解 ” 和模型的正确转化和执行。当仿真或转化模型时，合适的仿真器或代码生成器能够补充诸如确定的执行顺序或确定的转化要求的语义，如对所提供的仿真器或代码生成器的详细行为有充分了解。

在本附录中，将进一步考虑以下基于模型的开发方法的用例：

—— 软件安全要求的定义（第 6 章）；

—— 软件架构设计开发（第 7 章）；

—— 软件单元设计与实验，有无自动代码生成（第 8 章）；

—— 软件组件的设计、实现和集成，包括从软件组件模型自动代码生成（第 8 章、第 9 章和第 10 章）；

—— 验证（静态和 / 或动态）（第 9 章、第 10 章和第 11 章）。

A.2.2 通用适用性方面

可以基于以下方面评估所选的基于模型的开发方法是否适用于预期的应用程序，包括建模技术、标记法、语言或工具：

—— 在相应的开发阶段实现规定的准则（例如，可理解性、完整性、可验证性、明确性、准确性）；

—— 所选方法的知识和经验；

—— 语法和语义定义的充分性；

—— 语法和语义定义的充分性；

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

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

—— 通过实施抽象、封装、层次和模块化原则，对管理复杂度的支持；

—— 内部 / 外部开发方之间的协作模型（例如，数据交换期间的数据一致性）；

—— 对软件工具所需和可用的置信度；或

—— 作为选定的 MBD 方法的一部分或包含在 MBD 环境中的软件组件（例如软件库）的鉴定

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

一个模型可以代表本文件的多个工作成果（例如，要求、架构设计、详细设计以及基于模型的包含代码生成的软件集成）。传统开发过程中生命周期数据是分离的，与之相比， “ 软件安全需求 ”“ 软件架构设计 ”“ 软件单元设计和实现 ” 等阶段可出现更紧密的结合。这些方法的潜在益处（例如，连续性、跨软件生命周期的信息共享、一致性）极具吸引力，但这种方法也可引入导致系统性故障的问题（见 A.3 ）

A.3 示例软件开发用例的特殊注意事项

本部分基于示例用例提供与益处和潜在问题相关的注意事项。

A.3.1 软件安全要求的定义（第 6 章）

模型可用于捕获能够实现安全需求等级的软件的功能、行为、设计或特性（例如，开 / 闭环控制、受控系统、状态和转换、监控功能或独立特性），并通过仿真或形式化的方法来进行要求的验证和确认。

模型可以是实现安全要求特性的合适方法，也是满足如 GB/T 34590.8-2022 第 6 章所述的使用半形式法或形式记法要求的方法。

示例 1 ： 当使用基于模型的方法定义状态机时，相应的模型以直观、明确和可理解的方式捕获所需的状态和（状态）转换。事实上，与相同的状态机的文本规范相比，这样的模型表示了一个以上的原子要求，这是可以接受的。一个适当的理由是：该模型能在不重复信息的情况下更好地实现和保持规范地完整性、可验证性和内部一致性。

但是，请注意，通过使用要求模型，有可能会遗漏所选地基于模型的开发方法不能表示的安全要求。因此， GB/T 34590.8-2022 第 6 章强调了文本要求和其他记法的适当组合。

示例 2 ： 与针对丢失或错误输入的软件功能的鲁棒性相关的要求。

A.3.2 软件架构设计的开发（第 7 章）

模型可用于按照多个视角来捕获软件架构，特别是：

a ）   静态方面（例如，组件、其接口和数据流、组件属性）；

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

模型和建模指南可以是实现安全相关架构设计的特性和原则的合适方法，也是满足第 7 章所述的半形式或形式记法的要求的方法。

但是，请注意，一种建模方法可能无法表示所需的所有方面（例如，针对实现软件功能的模型通常无法描述包括基础软件或操作系统要素在内的总体架构设计），并且如果没有进一步的文本解释（例如，由不同的合作方提供），模型可能无法被完全理解。

A.3.3 软件单元的设计和实现（第 8 章和第 9 章）

模型，连同建模和编码指南，可用于在更高抽象层次上的详细设计和软件单元本身开发，通过使用 MBD ，可以从模型中通过代码生成功能直接生成可执行代码。

MBD 通过形式化方法、模拟仿真、静态分析或模型在环 / 软件在环测试来实现自动化一致性检查（例如，数据类型、使用前数据的正确定义）和验证。与手动编码相比，模型自动生成代码可能降低编码错误的风险，这取决于代码生成器的置信度

但是，请注意，例如：

—— 如果没有以其他适当的形式记录，则可能会遗漏不能用建模标记法表示的设计方面，如果所有的测试都是从这样一个 “ 不完整 ” 的模型中派生出来的，即使是单元测试（例如，使用背靠背测试）也可能无法揭示出这一点；

—— 如果只对预期的功能建模，则可能无法实现安全相关的代码特性（如鲁棒性） , 代码特性通常是通过模型特性和代码生成特性的适当组合来实现的（例如，如果除法是由代码生成器 “ 按原样 ” 生成的，那么将在模型级别检查避免除数为零，如果代码生成器使用鲁棒设计编码模式处理除数为零，则可以减轻模型中除数为零的分析）；

—— 错误的寻址或数字精度方面的处理可能会导致故障（例如，如果模型只是从控制工程中继承的），例如，由控制工程师的计算机环境和目标环境的不同精度特性引起的问题；

—— 当从连续模型创建软件行为下的离散模型时（例如，值和 / 或时间离散化的影响、计算的执行时间、处理并发任务），可能会引入故障；

—— 仿真或验证结果（例如：一致性检查的结果）可能依赖于工具，因为不同的仿真引擎或模型检查器可能会偏离已实现的语义（例如，对于建模语言的语义未涉及的算法方面）；

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

—— 在自动编码的情况下，可能更难验证所生成的源代码等效于手动编码。

A.3.4 软件组件的设计、实现和集成，包括从软件组件模型自动生成代码（第 8 章、第 9 章和第 10 章）

模型，连同建模和编码指南，可用于在更高抽象层面上的软件设计、实现和集成。因此，软件组件甚至是整个嵌入式软件都可能通过集成的模型生成自动代码的方式实现。

这种方法意味着不同的软件开发阶段的紧密结合，因此，需要仔细评估这种方法的益处和潜在问题，包括实施适当的安全措施（例如，使用单独的测试模型来派生额外的测试用例）。

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

模型可以用来验证工作成果（例如，设计模型、代码）。这样的模型叫 “ 验证模型 ” 。例如，验证模型能用作背靠背测试、生成测试用例或表示安全性相关的特性的基础，也能作为形式验证的参考（这需要验证的模型也是形式化的）。

模型还可以用作启用或支持验证活动的手段（例如，通过模拟被测设备的环境来建立闭环控制的硬件在环测试所需的对象模型）。

使用模型进行验证可以实现工作成果（包括软件）中的故障 / 失效的早期和有效的检测、更有效地测试用例的生成、高度自动化测试甚至是形式验证的技术。

但是 请注意，例如：

—— 如果缺乏证据，证明模型适合于验证的目的，相关结果的有效性可能会受到质疑（例如，不适当的对象模型可能导致不正确的测试结果）；

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

—— 从相同的模型（也用于代码生成）产生的测试用例不能作为验证模型本身和从模型生成的代码的唯一来源。

附录 B 软件配置

B.1 目的

软件配置的目的是：

a)    使不同应用的软件行为变化可控；

b)    提供证据证明配置数据和标定数据满足所需的 ASIL 等级要求；

c)    提供 证据证明专用嵌入式软件及其标定数据适合生产发布。

B.2 总则

软件配置允许使用配置数据和标定数据开发特定应用的嵌入式软件的变体（见图 B.1） 。

图 B.1 生成特定应用软件

B.3 本章的输入

B.3.1 前提条件

前提条件按照应用软件配置的相关阶段。

B.3.2 支持信息

本文件应用软件配置的相关阶段中的适用的支持信息。

B.4 要求和建议

B.4.1 为确保在安全生命周期中可配置软件的正确使用，应对配置数据进行定义，应包含以下内容：

a)    配置数据的有效值；

b)   配置数据的目的和用法；

c)   范围、比例、单位；

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

B.4.2 配置数据及其规范按照 GB/T 34590.8-2022 第 9 章提供证据证明：

a)   配置数据符合软件架构设计规范和软件单元设计规范；

b)   使用的值在其规定的范围内；

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

注： 对配置软件的测试在软件生命周期的测试阶段内执行（见第9章、第1 0 章、第1 1 章）。

B.4.3 配置数据的 ASIL 等级应等于应用于该数据的可配置软件的最高 A SIL 等级。

B.4.4 应按照 GB/T 34590.8-2022 第 9 章，针对所考虑的相关项开发中将要使用的配置数据集对可配置软件进行验证。

注： 只有其行为依赖于配置数据的那部分嵌入式软件要针对配置数据集进行验证。

B.4.5 对于可配置软件，可按照图 C .2 或图 C .3 所示的简化的软件安全生命周期应用。

注： 下列验证活动的组合能实现对已配置软件的完整验证：

a)   可配置软件的验证；

b)   配置数据的验证；

c)   已配 置软件的验证。

可通过如下任意一种方式实现：

——在a ) 中验证允许的配置数据的范围，并说明它符合在b ) 中定义的范围；

——说明与b）中允许的配置数据范围的符合性，并执行c ) 。

图 B.2 可配置软件和不同配置数据及不同标定数据的软件开发参考阶段模型的变型

图 B. 3 可配置软件和相同配置数据及不同标定数据的软件开发参考阶段模型的变型

B.4.6 标定数据的生成和应用应定义如下：

a)    标定数据的有效值；

b)    标定数据的目的和用法；

c)    范围、比例和单位，以及它们对运行状态的依赖（如果适用）；

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

注 1 ： 相互依赖可存在于同一标定数据集内的标定数据之间，或者不同标定数据集的标定数据之间，如不同电子控制单元的软件中执行的应用于相关功能的标定数据。

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

注 2 ： 配置数据可对 使用标定数据的已配置软件有影响。

B.4.7 标定数据的 A SIL 等级应等于其可能违反的软件安全要求的最高 A SIL 等级。

B.4.8 应按照 G B/T 34590.8-2022 第 9 章验证标定数据的定义，以提供证据证明：

a)    定义的标定数据合适并符合软件安全要求；

b)    定义的标定数据符合软件架构设计规范和软件单元设计规范；

c)    定义的标定数据与其他定义的标定数据是一致且兼容的，以防止非预期影响 。

B.4.9 用于生产发布的标定数据应按照 G B/T 34590.8-2022 第 9 章进行验证，以提供证据证明：

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

b)    嵌 入式软件的已标定的、应用特定的变体提供了定义的安全相关功能和特性。

注： 标定数据的验证也可以在系统层面执行。

B.4.10 为探测安全相关的标定数据的非预期变化，应使用表 C .1 中所列的数据非预期变化的探测机制。

表 19 嵌入式软件测试用例的得出方法

B.4.11 标定数据的生成和应用应定义如下：

a)   应遵循的流程；

b)   生成标定数据的工具；及

c)   验证标定数据的流程。

注： 标定数 据的验证也可包含检查标定数据值得范围或者不同标定数据之间得相互依赖关系。

B.5 工作成果

B.5.1 配置数据规范，由 B .4.1~B.4.4 的要求得出。

B.5.2 标定数据规范，由 B .4.6~B.4.8 的要求得出。

B.5.3 配置数据，由 B .4.2~B.4.4 的要求得出。

B.5.4 标定数据，由 B .4.7~B.4.10 的要求得出。

B.5.5 验证规范（细化的），由 B .4.2 、 B.4.4 、 B.4.5 、 B.4.7 、 B.4.8 、 B.4.10 的要求得出。

B.5.6 验证报告（细化的），由 B .4.2 、 B.4.4 、 B.4.5 、 B.4.7 、 B.4.8 、 B.4.10 的要求得出。

B.5.7 软件架构设计规范（细化的），由 B .4.10 的要求得出。

B.5.8 软件开发环境文档（细化的），由 B .4.1~B.4.11 的要求得出。

附录 C 避免软件要素间的干扰

C.1 目的

本附录的目的是提供能引起软件要素（例如，不同软件分区中的软件要 素）间干扰的故障示例，此外，本附录也提供一些可用于防止或探测并减轻所列出的故障的处理机制的示例。

注： 在开发过程中评估用于防止或探测并减轻相关故障的处理机制的能力和有效性。

C.2 总则

C.2.1 免于干扰的实现

为了开发或评估软件要素间免于干扰的实现，可考虑典型故障的影响及其可能导致的失效的传播。

C.2.2 时序和执行

关于时序限制，对于每一个软件分区中执行的软件要素可考虑下列故障的影响，例如：

—— 执行受阻；

—— 死锁；

—— 活锁；

—— 执行时间的不正确分配；或

—— 软件要素间的不正确同步。

示例：可考虑的处理机制，例如，循环执行调度、固定优先级调度、时间触发调度、处理器执行时间监控、程序执行次序监控和到达率监控。

C.2.3 存储

关于存储，对于每个软件分区中执行的软件要素可考虑下列故障的影响，例如：

—— 内容损坏；

—— 数据不一致（例如，由于数据获取期间发生更新）；

—— 堆栈上溢或下溢；或

—— 对已分配给其他软件要素的内存进行读或写访问。

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

示例 2 ： 适当的验证方法可以被视为详细的安全分析，以识别需要采取保护机制的关键存储。静态和语义代码分析、控制流和数据流的分析结果可以提供证据证明免于干扰。

C.2.4 信息交换

关于信息交换，针对每个发送方或接收方，可考虑如下所列各故障的原因或故障的影响：

—— 信息重复；

—— 信息丢失；

—— 信息延迟；

—— 信息插入；

—— 信息伪装或信息的不正确寻址；

—— 信息次序不正确；

—— 信息损坏；

—— 从发送方传送到多个接收方的信息不对称；

—— 发送方发送的信息只能被部分接收方接收；或

—— 通信信道阻塞。

注： 在不同软件分区或不同 ECU 中执行的要素间的信息交换包括信号、数据、消息等。

示例 1 ： 可使用 I/O 设备、数据总线等方式进行信息交换。

示例 2 ： 可使用的处理机制如：通信协议、信息重复、信息回送、信息确认、 I/O 引脚的适当配置、分离的点到点的单向通信对象、明确的双向通信对象、异步数据通信、同步数据通信、事件触发数据总线、带有时间触发访问的事件触发数据总线、时间触发的数据总线、最小时间片和基于优先级的总线仲裁。

示例 3 ： 通信协议可包含的诸如通信对象的标识符、保持活动的消息、活动的计数器、系列号、错误检测码和纠错码的信息。

示例 4 ： 适当的验证方法可以被视为详细的安全分析，以识别需要采取保护机制的关键数据交换。静态和语义代码分析以及控制流和数据流分析的结果能提供证据证明免于干扰。

附录 D 软件架构层级安全分析及相关失效分析的应用

D.1 目的

本附录阐述了安全分析及相关失效分析在软件架构层级可能的应用。本附录中提供的示例旨在支持对这些分析的理解，并为应用提供指导。

D.2 总则

D.2.1 分析的范围和目的

通过在软件架构层级应用安全分析或相关失效分析，可以检查或确认嵌入式软件按照所分配 ASIL 等级的完整性要求提供指定功能、行为和特性的能力。

嵌入式软件按照所分配的 ASIL 等级的完整性要求提供指定的功能和特性的适用性，通过以下方式进行检查：

——识别可引发因果链而导致违反安全要求的设计缺陷、条件、故障或失效（例如，使用归纳或演绎的方法）；

——分析可能出现的故障、失效或因果链对软件架构要素所需的功能和特性的影响。

相关的软件架构要素之间所达到的独立性或免于干扰的程度，可通过分析如下软件架构设计的相关失效来检查，即：

——可能导致多个且相互独立的软件要素功能异常表现得单一事件、故障或失效（例如，级联失效和/或共因失效，包括共模失效）；

——可能从一个软件要素传播到另一个软件要素，引发因果链而导致违反安全要求的单一事故、故障或失效（例如，级联失效）。

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

—— ASIL 等级分解在软件层面的应用（见6 .3.1 ）；

——软件安全要求的实现（见7 .4.2 ），例如，提供软件安全机制有效性的证据，如被监控要素与监控器之间的独立性；或

——所需软件架构要素的共存（见7 .2.1 、7 .2.3 、7 .3.1 和G B/T 34590.9-2022 第6章）。

软件架构层级的安全分析及相关失效分析的作用是支持设计规范和设计验证活动。

此分析也可以揭示给定安全要求的不完整性或不一致性。

软件架构层级安全分析及相关失效分析的结果也是以下活动的基础：

——产品中有效安全机制的定义与实施；或

——开发期间适合的安全措施的确定，以适用于预防或探测并控制在这些分析过程中识别出的相关故障或失效。

图 E.1 说明了软件结构层级的安全导向分析在软件开发中的作用，以及软件安全要求、软件架构设计和安全计划间基本的交互关系。

图 D.1 安全导向软件分析过程在开发过程的作用图示

示例： 图 D.2 说明了共享资源（例如，共享的处理要素）使用时的冲突造成的干扰。如图 D.2 所示，一个Q M 软件要素干扰并阻止了A SIL 等级软件要素的及时执行。这样的干扰也可能发生在不同A SIL 等级的软件组件之间。此图说明了有无免于干扰机制对软件执行的影响。通过在软件中引入“监测点”并对监测点进行超时监控，可探测到时序干扰并触发合适的响应。

图 D.2 时序干扰导致级联失效的示例

安全分析及相关失效分析旨在应用于软件架构层级。而代码层面的安全分析（例如，针对运行时的错误，如被零除，超出数组索引边界的访问）既不需要也不认为必要的原因如下。

——当软件开发过程严格采用了本文件的要求，这类故障的残余风险可以认为足够低。包括选择和使用适当的方法、方式和开发原则，如建模和编码指南、设计和实施规则、模型和/或代码审核、语义或静态分析、单元和集成测试；

——在实现相应架构要素时，这类故障通常在要素接口上引起和架构层面分析时同样的功能异常表现。因此更高层面的分析已经提供了证据，证明所选择的技术安全机制是有效的，或者开发期间的安全措施是充分的。

D.2.2 安全分析及相关失效分析在系统、硬件和软件层面的关系

在开发生命周期的多个阶段，使用了安全分析及相关失效分析。这些分析可以是互相关联的。

在系统层面启动的关注点分离方法中，通常由硬件开发负责确保处理单元具有足够低的硬件故障残余风险。因此，在执行软件架构层级的安全分析及软件相关失效分析时可不考虑硬件故障。

然而，在某些硬件条件下（例如，处理单元的包括瞬态故障随机硬件故障的诊断覆盖率不足的情况），考虑硬件故障的负面影响可能更为合适。在这种情况下，针对特定硬件/软件交互的特定分析应参考以下示例：

——映射到多核系统的不同处理单元的特定软件；

——和静态/动态软件架构设计相关的处理元件的详细设计（软件在处理元件上执行）；或

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

注：可通过故障注入技术来支持特定硬件/软件交互分析（见 GB/T 34590.11-2022 中4 .8 ）。

D.2.3 分布式软件开发（包含 S EooC 软件要素的开发）的安全分析

嵌入式软件和其软件要素通常由多个组织（包括O EM 、1级供应商、2级供应商、半导体供应商和软件供应商）通过分布式开发完成，甚至作为独立于环境方式开发（例如，作为S EooC 开发的基础软件、硬件相关的软件、商业现成软件或操作系统）。

分布式软件开发中有意义的以安全为导向的分析应包括以下要点：

——分析范围、分别或联合进行分析的流程或方法和协议（包括信息/文档交换或假设确认）；

——关于软件安全分析过程的总体职责和参与组织的通用规则的定义和协议（例如，高层级组件及其之间的访问规则）；

——使用模块化方法进行分析时接口的定义和协议(例如，不同范围之间接口达成一致的软件故障模型、使用的方法、信息/文档的交换)；

——分析验证的定义和协议。

D.3 执行分析的通则

软件架构设计提供了支持实现功能安全和论证达成功能安全的高层次规则和决定，例如，组件的功能安全分类，组件间的访问规则。

达成有意义分析的通则需要确定：

——分析的目标，见 D.3.1;

——范围和边界，见 D.3.2;

——用于执行分析的方法，见 D.3.3 ；

——支持分析的意义性、客观性和严谨性的方法或准则，见 D.3.4 。

D.3.1 确定分析目标

目标由第7章和 GB/T 34590.9-2022 的第7章和第8章提供。

示例： 鲁棒性或确定性执行的分析中，违背分配给软件的安全相关功能或特性。

D.3.2 确定待分析的特定架构设计的范围和边界

根据分析的目标，确定范围并着重于架构设计的相关部分。

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

——在 DIA 中定义的与交付相关的范围和相应职责；

——分析的特定目标；

——基于“良好”设计原则的架构策略（见 7.1.3 ）；或

——架构设计所需特性，源于更高层面安全概念中免于干扰或充分独立性的要求。

示例1： 当在安全分析中考虑与外部发送方或接收方交换安全相关数据时，适当的端到端数据保护机制可能被用作论据，证明基础软件可以被视为“黑盒”。

示例2： 带运行模式软件功能间的依赖性，例如，某个安全相关功能仅在其他“关键”功能被安全模式切换功能关闭时才可以被“激活”。

图 D.3 关于安全论证的分析范围

示例3： 图 D.3 展示了要分析的软件，按照安全概念，安全相关功能仅在软件组件U中实现，并由软件组件V中实现的监控功能所控制。架构分析范围的确定阐明了所需的安全论证，并支持下述内容中的后续步骤。在这个示例中，仅当对软件组件X、软件组件V和软件组件U的分析能够确定免于干扰时（例如，在监视功能M中没有因错误的信号A 1 至 A n所导致的级联失效），软件组件Y才可以免除进一步的详细分析。

D.3.3 确定分析所采用的方法

由于软件的特殊性质（例如，没有因磨损或老化而导致的随机故障，也缺少成熟的概率方法），在系统或硬件层面建立的分析方法通常不能未经修改就应用于软件，否则无法得出有意义的结论。

安全分析方法的共同特性是，它们通常包括一些手段，用于实施结构化方法，储备所获知识和得出结论。

示例： 在故障树、功能网、要素列表或 FEMA 的风险优先级编号中用于描述故障及其相关性的语法和语义。

软件架构设计是安全分析和相关失效分析的基础，其描述相关软件的静态方面（例如，显示功能要素及其接口/关系的框架表示）以及动态方面（例如，顺序图、时序图、调度图或状态图表示）。

按照软件架构设计的安全分析和相关失效分析可以遵循功能和/或处理链，同时考虑静态和动态方面。在此类分析过程中，可以使用软件故障模型或问题，例如，“源自或影响此软件组件的何种特定故障或失效可能导致违背指定的安全要求”，来识别设计中与安全相关的薄弱点。

软件架构设计的细化可以支持充分详细的安全性分析和相关失效分析，以获取足够详细信息，从而识别较低级别的故障或失效。

这种分析的详细程度与以下方面有关：

——细化架构设计时范围的适当选择；

——支持实现分析的特定目标的特性；

——基于“良好”设计原则支持的架构策略的论据（见 7.1.3 ）；或

——由包含达到的免于干扰的充分独立性支撑的论据。

D.3.4 支持有意义、客观、严谨的分析需要考虑的方面

D.3.4.1 按照 GB/T 34590-2022 相关失效分析的耦合因素类别

在 GB/T 34590.9-2022 附录C中，定义了相应的软件层面的耦合因素类型示例，可用于改进要求独立性的软件在功能或处理链上执行相关失效分析的结果。

D.3.4.2 使用附录 C 中的内容

附录C提供了在分析软件要素间的干扰时需考虑的软件故障模型，例如关于：

——时序和执行

——内存；或

——信息交换。

D.3.4.3 使用引导词的分析

引导词可用于系统地检查与特定设计意图的可能偏差，并确定其可能的结果。在安全导向的分析过程中，使用引导词生成问题去检查架构要素的特定功能或特性。当使用引导词时，使用引导词重复执行每个设计要素的特定功能或特性的安全导向分析，直到预定的引导词都被检查过。因此，引导词是系统地进行这种分析并支持完整性论据地一种手段。

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

引导词可以用来识别薄弱点、故障和失效。选择合适的引导词取决于接受检查的功能、行为、特性、接口或交换数据的特征。

图 D.4 软件架构设计框图

以设计意图为基础，通过综合设计属性、相关引导词及其解释，获得引导词，以达到对分析的共识。表D .1 展示了应用于图D .4 设计中引导词选择的示例。

表 D.1 与软件执行、调度或通信相关的引导词选择的示例

在分析过程中，可以在使用演绎法或归纳法时应用引导词。在分析过程中，如果需要的话，可以进一步细化引导词（例如，为了更好地匹配特定的设计方面）。

在分析过程中，按照所选择的方法（例如，后续功能或处理链）使用引导词来生成问题，使用这些问题检查设计并揭示可能的薄弱点及其后果。表D .2 所示为信号A 1 到A n 的引导词支持的分析示例。

表 D.2 引导词支持的分析示例

D.4 安全及相关失效分析中识别的薄弱环节的减轻危害策略

软件架构层级的安全分析和相关失效分析结果允许选择适当的安全措施，以防止或探测和控制可能违背安全要求或安全目标的故障和失效。

安全措施确定策略可以基于以下考虑：

——每个已识别故障的关键性，基于其是否违背分配给架构要素的安全目标或安全要求以及其所分配的A SIL 等级；

——改进架构设计是否能够消除已识别的薄弱环节或降低已识别故障的关键性；

——已确定的开发期间安全措施的有效性，以及这些措施是否能够基于其关键性和相应的分减轻已识别故障的危害（例如，在分析中考虑使用软件故障模型的已定义验证活动的理由）；

——已确定的安全机制的有效性，用于减轻开发期间措施不够充分的已识别关键故障的影响；

——软件架构设计的复杂性（例如，接口和软件组件的数量），或软件组件的复杂性（例如，分配要求的数量或组件规模）。

示例： 对于比较复杂的软件，仅基于开发期间措施的论据是不太合适的。

按照上述策略，在运行期间并不总是需要执行能够预防或探测和控制此类故障或失效的安全机制。