安全需求规范和管理指南

1. 安全需求规范 1. 安全需求的标记法

对应于2.2章节中的安全需求特性，通过如下组合来定义安全需求：

1. 自然语言（适应于较高层面的安全需求，如功能和技术安全需求）；
2. 表1中所列举方法（适应于较低层面的安全需求，如软件和硬件安全需求）；

表1 定义安全需求

方法

ASIL

A

B

C

D

1a

用于需求定义的非正式标记法

++

++

1b

用于需求定义的半正式标记法

++

++

1c

用于需求定义的正式标记法

• 注1：安全要求定义方法的恰当选择考虑：针对特定问题待定义的安全要求，方法是否足够准确以具备相关规定的安全要求的特性；方法的复杂性；定义或管理安全要求的人员的背景知识。示例包括使用状态图或关系图来定义软件或硬件的复杂行为，包括许多状态或/和复杂转换。
• 注2：对于高等级的安全需求（安全目标、功能技术安全需求和技术安全需求）自然语言和其他类型非正式语言较为适合，有些要求可能用半形式记法更好处理。
• 注3：半形式记法使用数学或图形要素【如方程、图形、图表、流程图、时序图和许多其他形式的表示(例如 UML®和 SysML™)】补充的自然语言来表达需求。示例包括基于模型的技术，以及在自然语言中为要求描述语句应用模板和受控词汇表。
• 注4：对于低等级的安全需求，如详细的软件及硬件的行为、能力等，可明确定义，以半形式符号描述更加清晰；但不应该要求所有需求进行半形式化描述； 1. 安全需求的特性和特点

1. 安全需求应能被明确识别出。

• 注：安全需求应被列在单独的文档中，如果安全需求与其他需求在同一个文档中，安全需求应被明确标识出；

1. 安全需求应继承原安全需求的ASIL等级，安全目标已被分解的除外；

• 注：安全目标是顶层的安全需求，对于ASIL等级的继承始于安全目标水平；

1. 安全需求应被分配给实现这些要求的相关项或元素；

2. 安全需求需具备如下特性：

3. 明确的，无歧义的；

4. 可理解；

5. 不可分割，即不可再被细化为一个以上的需求；

• 注：在此特性与其他重要的安全要求特性相反时，不可分割性的重要性可被降低；

1. 内部一致：即每个单独的安全需求不包含自相矛盾的内容（不同于外部一致性，外部一致性指多个安全需求不含有相互抵触的内容）；
2. 可实现的；

• 注：如果某个要求在相关项的开发限制（资源、当前技术水平等）内可被实现，则其是可行的。
• 注：一项要求在技术上可以实现，它不需要重大的技术进步，并且在可接受范围内符合相关项限制（如成本、进度、技术、法律、法规等）；

1. 可验证的；

• 注：如果在定义要求的层面上有方法检查这些要求是否得到了满足，则要求是可验证的。
• 注：收集到有关相关项的证据表明相应的要求已得到满足。如果要求是可测量的，可验证性会更强。

1. 必要的；

• 注：某项需求定义了一项重要的能力、特性、约束或质量要素，如果该需求被移除或删除，会导致产品的其他能力或流程无法满足要求；
• 注：需求当前适用，没有被废弃；需求应明确标识截止日期或使用时间；

1. 实施自由的

• 注：仅描述需求应陈述要求是什么，而不是如何满足要求；不要对架构的设计做太多不必要的限制；

1. 完整的；

• 注：对需求的表述要清晰，不进行进一步扩充。

1. 合规的：

• 注：符合政府法规、汽车行业和产品标准、规范及接口要求。 1. 安全需求属性

安全需求应具有如下属性，

1. XXX安全需求在安全生命周期内，具有唯一识别并保持不变。
2. ASIL等级；
3. 安全需求的状态

示例：安全需求的状态可以是Draft（未通过评审和批准）及Released（通过评审和批准的）；

1. 其他类型的

安全目标：安全状态、FTTI等

功能安全需求可能有：运行模式，故障容错时间区间（间隔）或故障容错时间，安全状态，紧急操作时间区间，功能冗余几种属性。

对技术安全需求、软件安全需求、硬件安全需求的要求参见公司功能安全流程的相关文件（在下面表格中，ID，ASIL等级，Status使用了加粗字体代表必选，其他的属性用正常字体代表可选属性的举例）

1. 1. 1. 安全目标

表2 安全目标属性描述

属性

属性描述

ID

ASIL****等级

Status

安全状态

FTTI

1. 1. 1. 功能安全需求

表3 功能安全需求属性描述

属性

属性描述

ID

ASIL****等级

Status

运行模式

故障容错时间

安全状态

紧急操作时间区间

功能冗余

紧急操作

报警、降级

1. 1. 1. 技术安全需求

表4 技术安全需求属性描述

属性

属性描述

ID

ASIL****等级

Status

外部接口

限制条件

系统配置要求

1. 1. 1. 软件安全需求

表5 软件安全需求属性描述

属性

属性描述

ID

ASIL****等级

Status

维持安全状态

硬件故障监控处理

软件故障监控处理

是否车载测试

生产维护过程中是否可修改

与性能或时间敏感

1. 1. 1. 硬件安全需求

表6 硬件安全需求属性描述

属性

属性描述

ID

ASIL****等级

Status

控制要素内部失效

对外部失效容错

符合其他要素的安全需求

故障探测

未定义安全机制的硬件

1. 安全需求管理 1. 安全需求的管理方式

2. 通过《System Safety Requirements Traceability Matrix 》表格对安全需求进行管理

每一层子需求都需要满足上一层的母需求，使用《System Safety Requirements Traceability Matrix 》表格的Source Traceability部分标注追溯关系。参阅表格的相关标注。

1. 安全需求的管理需要满足：

2. 分层结构

注：如图1所示，分层结构是指安全需求分布在几个连续层面上的。这些层面与产品开发阶段一致。

1. 合理的架构

注：与架构相对应，安全需求在每个层面都应进行合理地分组；

1. 完整性

注：一个层面的安全需求完整地落实了前一层面的全部安全需求。

1. 外部一致性

注：不同于内部一致性（每个单独的安全需求不包含自相矛盾的内容），外部一致性表示多个安全需求不互相抵触。

1. 分层结构中任意一层的信息不重复

注：信息不重复表示安全需求的内容不重复出现在分层结构同一层面的其它安全需求中；

1. 可维护性

注：可维护性表示需求集可被修改或扩展，例如引入需求的新版本或增加/去掉需求集内的需求。

注：当安全需求符合 * 2.2*安全需求的特性和特点 与 3.1安全需求的管理方式 时，安全需求的可维护性更好。

                                       图1 安全要求的结构

1. 安全需求应置于配置管理之下

   当较低层面的安全需求与较高层面的安全需求相符合时，配置管理可定义一个基线作为安全生命周期后续阶段的基础。
   

2. 1. 安全需求的追溯性要求

使用《System Safety Requirements Traceability Matrix 》表格的Source Traceability部分标注追溯关系。参阅表格的相关标注。

安全需求应当是可追溯的，

1. 安全需求源自于更高层级的安全需求；
2. 安全需求导出到更低层级，或导出至设计中来实现。
3. 按照《验证过程管理规定》中有关“验证规范”的章节中，验证规范所描述的测试案例，均可以追溯每个安全需求是被充分验证的。

注1:可使用各种追溯记录类型，如需求管理系统、电子材料等；

注2：可追溯性另外还支持了：

• 实现安全需求、实现、验证之间的一致性；
• 对特定安全需求进行更改时的影响分析；
• 认可措施（如功能安全评估，以评估功能安全实现与否）的执行。 1. 安全需求的追溯内容

安全需求的追溯应包括：

1. 安全目标与功能安全需求之间的双向追溯性
2. 安全目标与安全确认测试用例之间的双向追溯性
3. 功能安全需求与技术安全需求之间的双向追溯性
4. 功能安全需求与整车集成测试用例之间双向追溯性
5. 技术安全需求与硬件安全需求
6. 技术安全需求与软件安全需求
7. 硬件安全需求与硬件设计
8. 硬件安全需求与硬件集成测试用例
9. 软件安全需求与软件架构设计
10. 软件安全需求与嵌入式软件测试用例
11. 软件架构设计与软件详细设计
12. 软件架构设计与软件集成测试用例
13. 软件详细设计与软件单元测试用例 1. 验证方法

应将表2中所列举的验证方法，用于验证安全需求是否符合本章节的要求，及是否符合得出安全需求的公司功能安全流程体系相关部分中关于验证安全需求的特定要求。

表7 验证安全要求的方法

方法

ASIL

A

B

C

D

1a

通过走查验证

++

º

º

1b

通过检查验证

++

++

++

1c

半形式验证

++

++

1d

形式验证

º

*可执行模型可以支持方法1c

1. 安全需求的分解 1. 安全需求分解的条件

2. 对功能安全需求进行ASIL分解需具备功能安全需求和功能安全概念；

3. 对技术安全需求进行ASIL分解需具备技术安全需求和技术安全概念；

4. 对软件安全需求进行ASIL分解需具备软件安全需求和软件安全架构；

5. 对硬件安全需求进行ASIL分解需具备硬件安全需求和硬件安全架构；

6. 分解后的安全需求必须互相冗余，且由相互独立的元素执行。 1. 安全需求分解的标识

分解后的安全需求的ASIL等级表示方法为 ASIL X (Y)，其中X为分解后的ASIL等级，Y为安全目标的ASIL等级。

示例：如果一个ASIL D的需求分解成一个ASIL C的需求和一个ASIL A的需求，则应标注成“ASIL C(D)”和“ASIL A(D)”. 如果ASIL C(D)的需求进一步分解成一个ASIL B 的需求和一个ASIL A的需求，则应使用安全目标的ASIL等级将其标注为”ASILB(D)”和“ASILA(D)”。

1. 1. 安全需求分解的模式

按照如下模式进行安全需求的分解，或可使用得出更高ASIL等级的方案。

1. 按照图2所示对ASIL D的安全需求进行分解：

图2：ASIL D分解方案

1. 一个ASIL C(D) 的需求和一个ASIL A(D)的需求；或
2. 一个ASIL B(D) 的需求和一个ASIL B(D)的需求；或
3. 一个ASIL D(D)的要求和一个QM(D)的要求。

当分解为两个ASIL B(D)的安全需求时，额外的要求如下：

1. 参照表1中ASIL C的要求来定义分解后的安全需求。

2. 如果用相同的软件工具开发分解后的元素，那么这些软件工具应考虑为开发ASIL D相关项或元素的软件工具，并符合《TK_P_SUP_06 工具评估流程》中软件工具使用的置信度。

3. 按照图3所示对ASIL C的安全需求进行分解：

图3：ASIL C分解方案

1. 一个ASIL B(C) 的需求和一个ASIL A(C)的需求；或

2. 一个ASIL C(C) 的需求和一个QM(C)的需求。

3. 按照图4所示对ASIL B的安全需求进行分解：

图4：ASIL B分解方案

1. 一个ASIL A(B) 的需求和一个ASIL A(B)的需求；或

2. 一个ASIL B(B) 的需求和一个QM(B)的需求。

3. 一个ASIL A 的需求不应进一步分解，除非需要分解成一个ASIL A(A) 的需求和一个QM(A) 的需求，如图5所示：

图5：ASIL A分解方案

1. 如果对初始安全需求的ASIL 分解是将分解后的需求分配给预期功能及相关安全机制，则相关安全机制宜被赋予分解后的最高ASIL等级。另一方面安全需求应被分配给预期功能，并按照相应分解后的ASIL等级执行。 1. 安全需求分解的相关要求

2. ASIL分解可以多次应用；

3. 初始安全需求应分解为独立安全要素执行的冗余安全需求；

4. 进行ASIL等级分解时，应分别考虑每一个初始的安全要求。应针对每一个初始安全需求单独进行ASIL分解；

5. 初始安全要求应分解为冗余安全要求，并由充分独立要素实现。如果相关失效分析没有找到导致违反初始安全要求的合理原因，或者根据初始安全要求的ASIL等级，所识别的相关失效的每个原因都被充分的安全措施控制，则这些要素具有充分的独立性；

注1：一条被分解的要求可能是几个初始安全要求分解的结果。

注2：使用同构冗余来实现分解的要求（例如，通过复制的设备或复制的软件）并不能解决硬件和软件系统性失效。 除非相关失效的分析（参见第7章）提供了充分的独立性证据或存在潜在共因可进入安全状态的证据，否则不允许ASIL等级的降低。因此，在没有针对特定系统应用背景的相关失效分析的支持下，单靠同构冗余通常不足以降低ASIL等级。

注3：ASIL等级分解通常不适用于在多通道架构设计中确保通道选择或通道切换的要素。 应用ASIL分解时，需提供分解后安全需求冗余且执行元素相互独立的证据。

1. 硬件架构指标(SPFM, LFM)和随机硬件失效导致违背安全目标的指标(PMHF)需参照安全目标的ASIL等级来要求。即便进行了ASIL分解，这些硬件相关的指标也维持不变
2. 每个分解后的安全需求应符合初始安全需求

注4：此要求通过定义提供了冗余。

注5：如果将分解后的安全要求分配给安全机制，则应在评估分解后的要求是否符合初始安全要求时，考虑该安全机制的有效性。

示例：分配给指定ECU的ASIL D要求，可能被轻易的分解为分配给ECU中简单看门狗的ASIL D要求和该ECU微处理器的QM安全要求。然而，这个简单的看门狗不足以覆盖ASIL D要求的微处理器的失效模式。在这种情况下，该看门狗不能有效地满足初始的安全要求。

1. 如果在软件层面应用ASIL 分解，应在系统层面检查执行分解后的元素间的充分独立性，如果有必要，应在软件层面、硬件层面或系统层面采取适当的措施来获得充分的独立性；
2. 如果不能通过关闭元素来阻止对初始安全需求的违背，则应展示执行分解后安全需求的充分独立的元素具备足够的可用性；
3. 应至少按照分解后的ASIL等级要求，在系统层面和软件层面开发分解后的要素；
4. 应至少按照分解后的ASIL等级要求，在硬件层面开发分解后的要素，但硬件架构指标(SPFM, LFM)和随机硬件失效导致违背安全目标的指标(PMHF)除外；
5. 按照分解前的ASIL等级要求开展对分解后的元素的相关集成活动及后续活动；
6. 同质冗余（复制设备或复制软件）因缺少要素间的独立性，通常不足以降低ASIL等级；
7. ASIL分解完成后需更新相应安全需求的ASIL等级和相应的架构设计；
8. ASIL分解不适用于在多通道架构设计中用来确保通道选择或开关的要素；
9. 如果架构要素不是充分独立的，则冗余需求和架构要素继承初始的ASIL等级；
10. 如果对初始安全要求的ASIL等级分解导致将分解后的要求分配给预期功能及相关安全机制，则： a) 相关安全机制宜被分配分解后的较高ASIL等级；及

注1：通常，与预期功能相比，安全机制具备较低的复杂度和更小的规模。安全要求应被分配给预期功能，并按照相应分解后的ASIL等级实现。

注2：如果选择了分解方案 ASILx(x) +QM(x)，则 QM(x)意味着质量管理体系足以实现预期功能要素安全要求的开发。

1. 子元素的ASIL等级确定准则1. 初始ASIL等级为QM的子元素的ASIL等级的确定

如果未分配ASIL等级的子元素和安全相关子元素共同存在于同一元素中，如果能证明未分配ASIL等级的子元素不能直接或间接地违背分配给该元素的任何安全需求，即：未分配ASIL等级的子元素不能干扰元素中安全相关的任何子元素，则应仅视其为QM的子元素。

注1：该子元素到安全相关元素的级联失效是不存在的。

注2：可通过设计措施获得，诸如考虑软件的数据流和控制流，或硬件的输入/输出信号及控制线。

否则，应将不具备免于干扰证据的共存安全相关子元素的最高ASIL等级分配给该子元素。

1. 1. 具备不同的初始ASIL等级的子元素的ASIL等级的确定

如果同一元素中存在不同ASIL等级（包括QM(x)）的安全相关子元素，若能证明对分配给元素的每个安全需求，某个子元素不会干扰任何分配了较高ASIL等级的其它子元素，则应仅视该子元素为较低ASIL等级的子元素。否则，由于不具备免于干扰的证据，应将共存安全相关子元素的最高ASIL等级分配给该子元素。

注： 对免于干扰的评估应与分配给共存的子要素的最高ASIL等级要求相匹配