道路车辆功能安全 ISO 26262标准（9-1）—面向汽车安全完整性等级 (ASIL) 和安全的分析
写在前面
本系列文章主要讲解道路车辆功能安全ISO26262标准的相关知识，希望能帮助更多的同学认识和了解功能安全标准。
若有相关问题，欢迎评论沟通，共同进步。(*^▽^*)
1. 道路车辆功能安全ISO 26262标准
9. ISO 26262-9 面向汽车安全完整性等级 (ASIL) 和安全的分析
一、考虑 ASIL 裁剪等级分解要求
1. 目标
提供安全要求分解的规则和指南，得到 ASIL 下一等级的细节剪裁。
2. 通则
正在开发过程中的以安全为目标的要素的传播贯穿与要素开发的全过程。
从安全目标开始，安全要求在开发过程中会被分解和提炼。ASIL 作为安全目标的一个属性，会被每一个后续的安全要求所继承。功能和技术安全需求被分配到每个组成要素中，从开始的基本结构假设到最后的软硬件要素。
在设计过程中的 ASIL 裁剪方法被称作“ASIL 分解”。在分配阶段，优势来自架构决定，包括存在足够独立的架构要素。这些好处在于：
——应用冗余的安全要求通过独立的架构要素；
——分配一个可能更低的 ASIL 给这些分解后的安全要求；
如果这些架构要素不是足够独立的，那么冗余的要求和架构要素继承初始化的 ASIL。
注1： ASIL 分解是一种 ASIL 裁剪方法，这种方法可以应用在一个条款或要素的功能、技术、硬件、软件安全要求。
注2： 作为一个基本规则，ASIL 分解需要分配给充分独立的架构模块的安全要求是冗余的。
注3： 在一致性冗余的应用中（比如：备份设备和软件）和考虑到软硬件的系统性失效，ASIL 不能降低除非失效分析充分表明足够的独立性存在或者潜在的一般原因不会导致危险。因此，一致性冗余一般来说不是充分条件对于降低 ASIL 等级，这是由于在组件之间缺少足够的独立性。
注4： 一般情况下，ASIL 分解不适用于那些在多通道架构设计中的通道选择和开关。 一般情况下，ASIL 分解允许在多个组件中以一个安全要求为目标的 ASIL 分摊 以确保相同安全要求的兼容。在一个预期功能和他对应的安全机制之间的 ASIL 分解在特定条件下是允许的（见 5.4.7）。
对于由于随机硬件失效造成的包括硬件架构矩阵评估和违反安全目标评估（见ISO26262-5）保持不变。
3. 本节输入
1. 前提条件
下列信息必须遵守：
——在 ASIL 分解的层级的安全要求：系统、硬件、软件根据ISO 26262-3:2011, 8.5.1, or ISO26262-4:2011, 6.5.1, or ISO26262-5:2011,6.5.1 or ISO26262-6:2011, 6.5.1; and
——ISO26262-4:2011, 7.5.2, 或 ISO26262-5:2011, 7.5.1, 或ISO26262-6:2011, 7.5.1.
2. 进一步的支持信息
下列信息应当被考虑：
——条款定义（见 ISO 26262-3：2011，5.5）
——安全目标（见 ISO26262-3：2011，7.5.2）
4. 要求和推荐
1. 如果应用 ASIL 分解，在这一条款中所有的要求应当被遵守。
2. ASIL 分解在执行过程中应当单独考虑每一个初始安全要求。
注：一些安全要求能被分配给相同的独立要素，这会造成不同的初始安全要求的ASIL 分解。
3. 初始安全要求应当被分解给足够独立的要素的冗余安全要求。
4. 每一个分解的安全要求应当遵守它自己的初始安全要求。
注：这些要求由定义提供了冗余。
5. 在由于随机硬件失效评价硬件结构矩阵和违反安全目标的要求在 ASIL 分解过程中保持不变，这是根据 ISO26262-5 的要求。
6. 如果 ASIL 分解应用在软件层级，在要素之间应用的要求分解的充分独立性应当在系统级进行检查，在软件级、硬件级、系统级要采用适当的措施以实现充分的独立性。
7. 如果一个初始的安全要求的 ASIL 等级分解导致了计划的功能和相关的安全机制的要求分配，那么：
ａ）相关的安全机制应当被分配到更高一级的 ASIL 分解中；
注： 一般，这个安全机制有更低的复杂性和更小体积与计划的功能来比的话。
ｂ）一个安全要求应当被分配到一个计划的功能，通过应用对应的 ASIL 分级进行应用。
注： 如果选择 ASILx(x)+QM(x)的分解机制，那么 QM(x)意味着质量管理系统是充分的。
对于开发组件，这些组件实现了分配给这些计划功能的安全要求。QM(x)同时意味着质量管理系统能支持在计划功能和系统机制之间独立的基本原理。
8. 如果一个违反初始的安全规范不能通过关掉这个组件来阻止的话，那么必须有足够的独立组件应用分解的安全规范应当体现出来。
9. 当应用 ASIL 分解到一个安全规范时，那么：
ａ）ASIL 分解应当符合 5.4.10；
ｂ）ASIL 分解可以应用多次；
ｃ）每一个分解的 ASIL 应当被标记出来，通过括号出来安全目标的 ASIL；
例如： 如果一个 ASIL D 规范被分解到一个 ASIL C 规范和一个 ASIL A，那么应当标记如下：“ASIL C(D)” and “ASIL A(D)”．如果 ASIL C(D)规范被进一步分解为一个 ASIL B 和一个 ASIL A，那么安全目标应当标记如下：“ASIL B(D)” and “ASIL A(D)”
10. 根据之前的 ASIL 分解（下图所示）以下的分解策略之一应当被选择，或者更高一级的 ASILs 的策略被应用。
注：从一个选择的分解策略到下一级的步骤定义了一个 ASIL 分解。
a）一个 ASIL D 要求应当被分解为以下的一种：
1）一个 ASIL C(D)要求和一个 ASIL A(D)要求；
2）一个 ASIL B(D)要求和一个 ASIL B(D)要求；
3）一个 ASIL D(D)要求和一个 QM (D)要求。
b） 一个 ASIL C 要求应当被分解为以下的一种：
1）一个 ASILB(C)要求和一个 ASILA(C)要求；
2）一个 ASIL C(C)要求和一个 QM (C)要求。
c） 一个 ASIL B 要求应当被分解为以下的一种：
1）一个 ASIL A(B)要求和一个 ASIL A(B)要求；
2）一个 ASIL B(B)要求和一个 QM (B)要求。
ｄ）ASIL A 不能被进一步分解，除非必须的话，一个 ASIL A（A）要求和一个 QM（A）要求。
11. 当应用在第10条中给定的分解机制，那么：
ａ）根据ISO 26262-2:2011 6.4.7中确定的测量应当被应用以符合安全目标的ASIL。
ｂ）分解之后的每个组件的足够的的独立性证据应当是可行的。
注：如果在分解之前经过相关故障分析没有找到相关故障原因能导致安全要求被违反，部件是充分独立的（参见本部分条款 7），或者每一个相关故障的确定原因根据安全目标的ASIL 被足够的安全措施所控制。
12. 当对在第10条中给定的 ASIL D 应用分解方案时，那么：
a）被分解的安全要求应与 ISO 26262-8:2011，条款 6 要求的 ASIL C 一致； 注意：
对 ASIL C 要求的更形式化的公式与 ASIL B 比较，减少了系统故障和与 ASILB(D)应用的依赖性。
B） 根据 ISO 26262-8 中的软件工具使用方法，如果同样的软件工具被用来分解组件的开发，那么这些软件工具应当被视为开发 ASIL D 要素或组件的软件工具。
13. 根据 ISO26262-4 和 ISO 26262-6 的 ASIL 要求（分解后），作为最小单元，在系统级和软件级的分解组件开发应当被进行。根据 ISO26262-5 的 ASIL 要求（分解后），作为最小单元，在硬件级的分解组件开发应当被进行，除了硬件架构矩阵评价和由于随机硬件故障违反安全目标的评价。
14. 在每一级的分解设计过程中，根据在分解之前的 ASIL 要求，相应的分解组件的集成和后续活动应当被开展。
5. 工作成果
1. 由第4条得到的架构信息更新。
2. 由第4条得到的作为安全要求和要素的 ASIL 更新。
本文章是博主花费大量的时间精力进行梳理和总结而成，希望能帮助更多的小伙伴~ 🙏🙏🙏
后续内容将持续更新，敬请期待(*^▽^*)
欢迎大家评论，点赞，收藏→→→