功能安全标准ISO26262-2翻译_++表示强烈推荐该方法

ISO 26262-2 功能安全管理

 

图1 ISO26262概览

 

1 范围

ISO26262适用于包含有一个或多个电子电气系统的安全相关系统，且该系统安装于车辆最大总质量为3500kg的一系列乘用车车型上。ISO26262不适用于特殊用途车辆（比如残疾人专用车辆）中的特殊电子电气系统。

在ISO26262发布日期之前已发布生产的、或已在开发过程中的系统及其零部件，不受此标准约束。在对ISO26262发布前生产的系统及其零部件进行开发或更改时，只需要使得更改的部分符合ISO26262的要求即可。

ISO26262阐述了E/E安全相关系统故障或系统相互作用故障可能导致的危害。ISO26262不涉及电击、火灾、烟雾、热量、辐射、毒性、易燃性、反应性、腐蚀性、能量释放等相关危害，除非以上这些危害是由于E/E安全相关系统故障直接导致的。

 

ISO26262不涉及E/E系统的名义性能，尽管这些系统（例如主动和被动安全系统、制动系统、自适应巡航系统）有专门的性能标准。

ISO26262-2部分规定了汽车应用的功能安全管理要求，包括：

• 相关组织的项目独立要求（全面安全管理），以及

• 与安全生命周期的管理活动有关的具体项目要求（即概念阶段、产品开发期间以及生产发布后的管理）。

 

2 相关标准

略

3 术语、定义和缩略语

见ISO26262-1部分。

4 合规性要求

4.1 一般化要求

若声称符合ISO26262要求时，应当遵守每项要求，除非有以下其中一项：

1. 计划按照ISO26262-2对安全活动进行裁剪，发现该要求不适用，或者

2. 有缘由表明，不合规是可以接受的，且该缘由经评估符合ISO26262-2。

标记为“注释”或“示例”的信息仅用于指导理解或澄清相关要求，不应理解为要求本身或完整需求或详细需求。

安全活动的结果是以工作产品的形式输出的。“先决条件”是指作为前一阶段工作产品提供的信息。考虑到某条款的某些需求是ASIL依赖的或定制的，某些工作产品可能不需要作为先决条件。

“进一步的支持信息”是可以考虑的信息，但在某些情况下，ISO 26262不要求该信息作为前一阶段的工作产品，并且可以由非功能安全人员或组织外部人员提供。

4.2 表格释义

根据上下文信息，表格可能是规范性的或信息性的。表中列出的不同方法，有助于将置信度提升到符合相应要求的水平。表中每个方法都是：

1. 连续条目（用最左边列中的序列号标记，例如1、2、3），或

2. 一个可选条目（用数字和最左边一列中的字母标记，例如2a、2b、2c）。

对于连续条目，应按照ASIL的建议，考虑使用所有方法。如果要采用其他方法，应给出满足相应要求的理由。

对于替代条目，要根据ASIL的要求，采用适当的方法组合；至于表中是否有列出这些方法则无关紧要。若列出的这些方法的ASIL等级不相同，那么应当优先选择等级较高的方法。且要给出所选方法组合符合相应要求的理由。

注：选择将部分方法在表中列出来的根据是充分的。但是并不意味着对那些未被列出来的方法有偏见或抵制。

对每个方法，都要根据ASIL来判断使用对应方法的推荐程度，分类如下：

• “++”表示对于已标识ASIL，强烈推荐使用该方法；

• “+”表示该方法适用于已标识ASIL；

• “o”表示该方法不适用已标识ASIL。

4.2 ASIL相关要求和建议

各条款的需求和建议应符合ASIL A/B/C/D等级要求，除非另有规定。需求和建议会涉及到安全目标的ASIL。如果ASIL的分解是在开发早期阶段进行的，那么根据ISO26262-9:2011第5条的要求，那么分解活动需要遵守分解产生的ASIL。

如果ISO26262标准中的括号中给出了ASIL等级，那么相应的子条款应看作是建议而非ASIL要求。上述括号的含义于ASIL分解相关的括号符号没有联系。

5 全面安全管理

5.1 目的

本条目的目的是为负责安全生命周期或在安全生命周期中执行安全活动的组织定义需求。

本条目是ISO26262安全生命周期活动的前提。

5.2 概述

5.2.1 安全生命周期概述

ISO26262安全生命周期主要（见图2）包括概念、产品开发、生产、经营、服务和报废等安全活动阶段。关键管理任务就是规划、协调和记录安全生命周期各阶段的安全活动。

图2表示参考安全生命周期模型。允许对安全生命周期进行裁剪，包括子阶段的迭代。

注1：概念阶段、产品开发阶段，以及生产发布后的各项活动，会在后续各个标准中进行详细介绍：ISO26262-3（概念阶段）、ISO26262-4（系统产品开发）、ISO26262-5（硬件产品开发）、ISO26262-6（软件产品开发）和ISO26262-7（生产经营）。

注2：表A.1概述了功能安全管理各阶段的目标、先决条件和工作产品。

图2 安全生命周期

 

5.2.2 安全生命周期说明

ISO26262规定了安全生命周期某个阶段和子阶段的要求，但也会包括安全生命周期几个阶段或全部阶段的要求，例如功能安全管理要求。

关键的管理任务是规划、协调和跟踪那些鱼功能安全相关的活动。这些管理任务适用于安全生命周期的所有阶段。以下给出功能安全管理要求，用于区分：

• 全面安全管理（见本条）；

• 概念阶段和产品开发阶段的安全管理（见第6条）；

• 项目投产后的安全管理（见第7条）。

以下描述解释了安全生命周期不同阶段和子阶段的定义，以及其他关键概念：

1. 子阶段：相关项定义

安全生命周期的第一项任务是对相关项的功能、接口、环境条件、法规要求、已知危害等项目进行描述。假定其他相关项、元素、系统和组件的是确定的，来确定相关项的边界及接口。

1. 子阶段：安全生命周期启动阶段

根据相关项定义，启动分为新相关项启动和已有相关项更新启动。

如果是已有相关项的需要更新，那么影响分析结果可能会导致安全生命周期调整（见ISO26262-3:2011第6条）。

1. 子阶段：危害分析于风险评估

安全生命周期开始后，按照ISO26262-3:2011第7条进行危害分析与风险评估。首先，危害分析与风险评估对相关项的危害事件的暴露度、可控性和严重度进行评估。这些参数共同决定了危害事件的ASIL等级。

1. 子阶段：功能安全概念

考虑到初始架构设想，功能安全概念（见ISO26262-3:2011，第8条）是基于安全目标提出的，由分配给相关项的功能安全要求所规定。功能安全概念也包括其他技术或外部措施的接口，且该接口能够验证其预期行为（见ISO26262-4:2011第9条）。其他技术的实施不包括在ISO26262的范围内，外部措施的实施也不包括在相关项的开发范围内。

1. 阶段：产品系统开发

规定了功能安全概念后，就可以从系统层面进行相关项的开发工作了，如ISO26262-4所示。系统开发流程以V模型的概念为基础，详细列出了V模型左边分支的技术安全需求、系统架构、系统设计和系统实现，以及V模型右边分支的继承、验证、确认和功能安全评估等步骤。

软硬件接口规范在这个阶段开始编写。

图1提供了系统层的产品开发子阶段的概述。

系统层的产品开发包括其他安全生命周期阶段的确认任务，比如：

• 由其他技术实施的各种功能安全概念的确认任务；

• 外部措施有效性及执行情况等假设的确认；

• 人类反应（包括可控性和操作任务）等假设情况的确认。

生产发布是产品开发的最后一个子阶段，提供相关项的连续生产发布活动（见ISO26262-4:2011，第11条）。

1. 阶段：产品硬件开发

根据系统设计规范，进行相关项的硬件层开发（见ISO26262-5）。硬件开发流程也基于V模型开发，详细列出了V模型左边分支的硬件设计、硬件实现，以及V模型右侧分支的硬件集成、测试等步骤。

图1提供硬件层的产品开发子阶段的概念。

1. 阶段：产品软件开发

根据系统设计规范，进行相关项的软件层开发（见ISO26262-6）。软件开发流程也基于V模型开发，详细列出了V模型左边分支的软件需求、软件架构设计、软件实现，以及V模型右侧分支的软件需求验证等步骤。

图1提供软件层的产品开发子阶段的概念。

1. 生产计划和运营计划

在产品开发过程中（见ISO26262-4），需要进行生产和运营规划，并编写相关需求规范。生产和运营要求见ISO26262-7:2011的第5条和第6条。

1. 阶段：生产和运营，服务和报废

本阶段涉及与产品功能安全目标相关的生产过程，即与安全相关的特殊特性以及产品维护、维修和报废规范的制定和管理，以确保产品发布后的功能安全（见ISO26262-7:2011第5条和第6条）。

1. 可控性

在危害分析与风险评估（见ISO26262-3:2011，第7条）中，对驾驶员或其他风险人员控制危险情况的能力进行评估。在安全验证期间，验证了危害分析与风险评估中关于可控性的假设，也验证了功能和技术安全概念（见图2和ISO26262-4:2011第9条）。

注：暴露度和严重度这个因素与情景相关。通过人工干预的最终可控性受相关项设计的影响，因此要在验证期间进行评估（见ISO26262-4:2011,9.4.3.2）

1. 外部措施

外部措施是指相关项定义（参见图2和ISO26262-3:2011第5条）中规定的相关项外部措施，以减少或降低相关项产生的风险。

外部措施不仅包括附加的车内装置，如动态稳定控制器或防爆轮胎，还包括车外装置如防撞栏或隧道消防系统。

安全验证期间，需要对相关项定义/危害分析与风险评估中外部措施的假设、以及技术安全概念进行验证（见图2和ISO26262-4:2011第9条）。

在危害分析与风险评估中，可以考虑使用外部措施。但是如果信任并采纳HARA中的外部措施，那么该外部措施就不能被视为功能安全概念的风险降低措施。

ISO26262也适用于ISO26262范围内的外部措施。

1. 其他技术

其他技术，指例如机械液压技术、或ISO26262标准范围内的其他不同于电子电气相关的技术。这些技术在安全需求分配（见ISO26262-3和ISO26262-4）时，也会作为功能安全概念的规范（见图2和ISO26262-3:2011第8条），或作为一种外部措施存在。

注：如果另一项技术的实施被指定为一项外部措施，那么重做一次HARA是非常有必要的，因为相关风险降低有可能使得相应安全目标ASIL降低。

5.3 本条款的输入

5.3.1 前提条件

无。

5.3.2 更多支持信息

可以考虑以下信息：

• 质量管理体系符合质量管理标准（如ISO/TS 16949、ISO9001或其他同等标准）的现有证据。

5.4 需求和推荐

5.4.1 概述

参与安全生命周期执行的组织应符合5.4.2至5.4.5的规定。

5.4.2 安全文化

5.4.2.1 组织应创造、培育并支持和鼓励能有效实现功能安全的安全文化。

例：附件B中给出了评估安全文化的示例。

5.4.2.2 为了符合ISO26262的要求，组织应制定、执行并维护具体的组织规则和流程。

注：这些具体的组织规则和流程包括创建维护通用安全计划、流程描述等活动。

5.4.2.3 组织应制定、执行并维护流程，确保已识别的功能安全异常情况可以明确的传达给安全经理和其他相关负责人。

例：相关项有关联的客户安全经理、供应商安全经理、开发安全经理。

5.4.2.4 组织应制定、执行和维护安全异常解决流程，确保功能安全异常能够及时有效地分析、评估、解决和处置。

注：异常解决流程包括根本原因分析（root cause）。进行root cause分析是为了便于将来采用合适的纠正措施。

5.4.2.5 执行安全周期过程中，组织需实施所需功能安全活动，包括与ISO26262-8:2011第10条相关的生产和管理的文档工作。

5.4.2.6 组织需提供资源来保证功能安全的落地。

注：资源包括人力资源、工具、数据库和模板。

5.4.2.7 组织需建立、执行和维护持续改进流程，基于以下：

• 学习其他相关项执行过程中获得的经验教训，包括现场经验；、

• 用于后续相关项的迭代改进。

5.4.2.8 组织需建立组织需确保执行或支持安全活动的人员有足够的权利，去履行他们的职责。

5.4.3 能力管理

5.4.3.1 组织需确保执行安全生命周期的相关人员，具备责任相关的技能、能力和资质评级。

注1：实现开发技能能力等级评级的一种可能方法是，考虑一下知识领域的培训和资格认证计划：

• 常规的安全实践、概念和设计；

• ISO26262和其他适用的安全标准；

• 具体的功能安全组织规则；

• 组织内制定的功能安全流程。

注2：为了评估符合ISO26262的技能、能力和资格等级评定活动，以前的专业活动经验也可以考虑，例如

• 相关项的知识领域；

• 相关项的环境方面的专家意见；

• 管理经验。

5.4.4 安全生命周期中的质量管理

5.4.4.1 参与安全生命周期执行的相关组织，应具有符合质量管理标准（如ISO/TS 16949、ISO9001或同等标准）的质量管理体系。

5.4.5 安全生命周期的独立项目裁剪

5.4.5.1 组织可为跨相关项开发运用定制的安全生命周期，即应用独立于项目的裁剪，前提是此类裁剪仅限于以下情况：

1. 可合并或拆分的子阶段、活动或任务；

注：如果使用的方法难以清楚地区分各个子阶段，则可以合并各个子阶段，例如计算机辅助开发工具可以在一个步骤内支持多个子阶段的开发活动。

1. 不同阶段或子阶段实施的活动或任务；

2. 新增阶段或子阶段实施的活动或任务；

3. 可迭代的阶段或子阶段。

5.5 需求和推荐

5.5.1 功能安全的具体组织规则和流程，来自5.4.2和5.4.5；

5.5.2 能力证据，来自5.4.3.

5.5.3 质量管理证据，来自5.4.4.

6 概念阶段和产品开发阶段的安全管理

6.1 目的

本条目的第一个目的是定义安全管理角色和责任，设计概念阶段和安全生命周期的开发阶段（见图1和图2）。

本条目的第二个目的是定义概念阶段和开发阶段的功能安全需求，包括安全活动的规划和协调、安全生命周期的进展、安全案例的建立、确认措施的执行。

6.2 概述

安全管理包括实施确认措施的责任分配。根据ASIL，某些确认措施要求在资源、管理和发布权限等方面具有足够的独立性（见6.4.7）。

确认措施包括确认评审、功能安全审计和功能安全评估：

• 确认评审是为了检查工作产品是否符合ISO26262的要求；

• 功能安全审计是为了评估功能安全活动所需流程的实施情况；

• 功能安全评估是为了评估相关项的功能安全实现情况。

除了确认措施外，还实施了验证评审。这些评审时ISO26262其他部分要求的，旨在验证相关工作产品是否满足相关项要求，以及验证与用例和故障模式相关的技术要求。

表1列出所需确认措施。附件D参考了ISO26262相关部分，列出了与验证有关的评审。

安全管理包括对任何定制安全活动的描述和理由（见6.4.5）。

6.3 本条目的输入

6.3.1 前提条件：

以下信息必须有效：

• 第5.5.1条要求的具体组织功能安全规则和流程；

• 第5.5.2条要求的能力资质证据；

• 第5.5.3条要求的质量管理证据；

6.3.2 更多支持信息：

以下信息需要考虑（如果有效）：

• 项目计划（来自外部资源）；

• 与其他活动的相关性，包括其他安全活动。

6.4 需求和推荐

6.4.1 概述

除非另有说明，否则涉及安全生命周期执行的组织应遵循6.4.2到6.4.9的要求，相关性至少要有一个包含ASIL等级的安全目标。

6.4.2 安全管理角色和责任分工

6.4.2.1 项目开发初期要任命项目经理。

6.4.2.2 按照5.4.2.8中要求，给项目经理承担一定责任并授权，确保：

1. 实现功能安全的所需安全活动被有效实施；

2. 符合ISO26262的要求进行项目实施。

6.4.2.3 项目经理应根据5.4.2.6，验证组织是否为功能安全活动提供所需资源。

注：充足资源的评估、确定和分配，通常要在规划阶段进行。

6.4.2.4 项目经理应根据5.4.3，确保安全经理的到位（任命）。

注1：项目经理可以履行安全经理的职责。

注2：由于术语“安全经理”被定义为一个角色（见ISO26262-1），其任务可以在矩阵组织中的人员中进行分配。

6.4.3 安全活动的计划和协调

6.4.3.1 根据5.4.2.8，安全经理负责计划和协调安全生命周期开发阶段的功能安全活动。

注1：安全经理可以将任务委托给具备所需技能、能力和资格条件的人员（见5.4.3）。

注2：安全活动的规划包含在安全计划中（见6.4.3.5）。某些计划的安全活动在ISO26262的其他工作产品中有更详细的说明（见6.4.3.3）。

注3：相关项有新开发相关项和对现有相关项的修改（见ISO26262-3:2011）之分，安全活动范围可能会因上述因素有所不同，相应活动规划也会调整。

6.4.3.2 安全经理负责维护安全计划，并监督安全活动的开发按照安全计划进行。

6.4.3.3 按照5.4.2.8和5.4.3的规定，在组织内部分配和传达以下计划中有关详细说明和协调安全活动的职责：

• 符合ISO26262-4的相关项集成和测试计划；

• 符合ISO26262-4的确认计划；

• 符合ISO26262-6的软件验证计划；

• 符合6.4.9的功能安全评估计划。

6.4.3.4 安全计划应该：

1. 基于项目计划进行，或者

2. 包括在项目计划中，但是要注意区分安全活动。

注：安全计划可包含配置管理中其他信息的交叉引用（见ISO26262-8:2011第7条）。交叉引用通常比并行描述不同工作产品或配置管理下的其他文档中的活动更可取。

6.4.3.5 安全计划包括：

1. 实现功能安全的活动和流程的计划；

2. 按照第5条的规定，实施项目独立安全活动，纳入具体项目安全管理；

3. 根据6.4.5（如果适用）对定制安全活动的定义；

4. 根据ISO26262-3:2011第7条，计划危害分析与风险评估；

5. 开发活动计划，包括：根据ISO26262-3:2011第8条制定和实施功能安全概念:；根据ISO26262-4开发产品的系统层；根据ISO26262-5开发产品硬件层；根据ISO26262-6开发产品软件层；

6. 根据ISO26262-8:2011第5条（如果适用），计划开发接口协议；

7. 根据ISO26262-8，计划支持流程；

8. 根据ISO26262-3、ISO26262-4、ISO26262-5、ISO26262-6和ISO26262-8:2011第9条安排验证活动计划；并根据ISO26262-4:2011第9条安排安全验证活动计划；

注：验证活动在相关项集成和测试计划（见ISO26262-4）和软件验证计划（见ISO26262-6）中有详细说明。验证活动详见验证计划（见ISO26262-4）。另见6.4.3.3。

1. 根据6.4.7到6.4.9，计划确认评审、启动功能安全审计、启动功能安全评估等活动；

2. 根据ISO26262-9:2011第7条（若适用）计划关联失效分析，根据ISO26262-9:2011第8条进行安全分析；

3. 根据ISO26262-8:2011第14条（若适用），提供候选项的在用证明。

4. 根据ISO26262-8:2011第11条（若适用），提供所使用软件工具的置信度。

6.4.3.6 安全活动计划应包括以下描述：

1. 目的；

2. 与其他活动或信息的关联性；

3. 负责实施活动的资源（the resource responsible for performing the activity）；

4. 实施活动所需资源（the required resources for performing the activity）；

5. 时间和时间间隔的起点；

6. 对应工作产品的标识。

6.4.3.7 对于至少一个ASIL等级达到B/C/D的安全目标的相关项，要遵守以下要求：根据6.4.3.1至6.4.3.6，安全计划要由授权人批准，授权人应根据6.4.7对安全计划进行确认评审。

6.4.3.8 根据5.4.2.3，将发现的安全异常情况报告给安全经理和其他负责人。

注：因安全异常决议产生的变更，会进入变更管理流程（见ISO26262-8:2011第8条）。

6.4.4 安全生命周期进展

6.4.4.1 只有相关子阶段的信息足够时，才能开始安全生命周期后续子阶段的安全活动。

注：若信息缺失不会对相关项安全目标的实现造成不可接受的风险，则认为信息是充分的。

6.4.4.2 根据ISO26262-8:2011第7、8、10条，安全计划需要的工作产品，在进入系统层开发阶段之前，要分别进行配置管理、变更管理和文件归档等步骤。

6.4.5 安全活动的定制裁剪

6.4.5.1 一些相关项开发有关的安全活动可以定制，即省略或者以不同的方式实施。若安全活动经过定制裁剪，那么：

1. 定制裁剪需要在安全计划中定义（见6.4.3.5）；

2. 应提供一个合理的缘由，说明为什么定制裁剪成这样有助于功能安全的实现。

注1：缘由可以是相关需求的ASIL等级；

注2：裁剪的缘由要在安全计划中体现，且要在安全计划的确认评审（见6.4.7）阶段，或在功能安全评估阶段进行评审；

注3：该需求适用于针对特定相关项的定制应用。对于组织内跨相关项开发的安全生命周期的定制裁剪，只有5.4.5适用。

6.4.5.2 若因修改了现有相关项导致按照6.4.5.1对安全活动的定制裁剪，则应遵守ISO26262-3:2011第6条。

6.4.5.3 若安全活动是按6.4.5.1进行定制裁剪的，作为在用证明，则应遵守ISO26262-8:2011第14条。

6.4.5.4 如果由于ASIL分解而未按照6.4.5.1实施安全活动，则应遵守ISO26262-9:2011第5条。

6.4.5.5 根据6.4.5.1，基于软件工具置信度来裁剪安全活动，则应遵守ISO26262-8:2011第11条。

6.4.5.6 由于元件与相关项是分开开发的，如果安全活动根据6.4.5.1定制裁剪，那么：

1. 独立于某个相关项开发的元件开发，应基于需求规范进行；该需求规范来自对预期用途和上下文的假设；

2. 要确认元件的预期用途和背景的开发与相关项分开的有效性；

注：ISO26262作为一个整体方法，不能用于独立于相关项开发的元件，因为功能安全不是元件属性（但是，相关项的元件可以被识别为是安全相关的）。功能安全是一种相关项属性，可以通过功能安全评估进行估计。

例：独立于相关项开发的MCU（单片机）。

6.4.6 安全案例

6.4.6.1 对于具有至少一个ASIL（A）、B、C、D安全目标的相关项，应遵守以下要求：根据安全计划制定安全案例。

6.4.6.2 在安全生命周期中，安全案例应逐步地添加到（不断完成的）工作产品中。

6.4.7 确认措施：类型、独立性和权威性

6.4.7.1 应根据表2的6.4.3.5的i)项、6.4.8和6.4.9中要求的独立性等级，执行表1中规定的确认措施。

注1：对表1中规定的、安全计划要求的工作产品进行确认评审；

注2：确认评审包括检查与ISO26262要求有关的形式、内容、充分性和完整性是否正确无误；

注3：表1包括确认措施。验证评审概述见附录D；

注4：确认措施的结果报告，包括分析的工作产品或工艺文件的名称和版本号（见ISO 26262-8:2011，10.4.5）；

注5：若确认评审或功能安全评估完成以后，相关项需要变更，则应重新进行评审或补充评审（ISO26262-8:2011，8.4.5.2）；

注6：每个确认措施的目的见附录C；

注7：确认评审、功能安全审计等确认措施，可以合并到功能安全评估环节中，支持处理相关项的相对变体。

6.4.7.2 实施确认措施的人应能接触并得到在项目开发期间开展安全活动的人员组织和组织实体的支持。

6.4.7.3 实施确认措施的人应具备进入相关信息和工具的权限。

6.4.8 功能安全审计

6.4.8.1 若相关项安全目标的最高ASIL为B、C或D时，应根据6.4.7 、6.4.3.5 i) 和 6.4.8.2对相关项进行功能安全审计。

6.4.8.2 根据5.4.3，应指定一个或多个人员执行某个或多个功能安全审计工作。审计人员应提供一份报告，其中包含对功能安全的过程实施情况的评估。

注1：如果功能安全审计是由软件过程改进和能力测定（SPICE）评估员来实施的，那么功能安全审计和SPICE评估（见ISO/IEC 15504）可同步进行。ISO26262与SPICE的内容比较类似，因此可以进行同步规划。如果已同步，SPICE评估员需向功能安全审计员反馈情况。然而，SPICE评估只能与ISO26262-8中规定的某些支持流程的检查同步进行，不足以进行功能安全评估（PS：主要说明SPICE评估与功能安全评估的区别）。

注2：组织（比如公司）的流程定义可以同时兼顾多个标准的要求，例如ISO26262和SPICE的配置管理流程需求。流程的协调有助于避免工作的重复或流程的不一致。对于协调过的流程，可以提供具体组织流程对ISO26262和SPICE需求的交叉引用证据。

6.4.9 功能安全评估

6.4.9.1 根据6.4.7、6.4.9.2至6.4.9.8对安全目标等级达到B/C/D的相关项，进行功能安全评估。

6.4.9.2 根据6.4.3.3 和 6.4.3.5 i)进行功能安全评估的规划。

例：附录E给出了功能安全评估的议程表。

6.4.9.3 根据5.4.3，要安排一个或多个人员进行功能安全评估。评估人员要提供一份报告，包含实施功能安全的一些判断。

6.4.9.4 功能安全评审应包括：

• 安全计划要求的工作产品；

• 功能安全要求的流程；

注1：实施过程的评估可基于功能安全审计的结果进行；

• 相关项开发过程中，评审能够进行评估的已实施安全措施项的适当性和有效性。

注2：将在生产子阶段实施、但开发阶段无法评估的安全措施，跟生产工艺能力一起进行评估（见ISO26262-7:2011, 5.4.2.2）。

6.4.9.5 功能安全评估应该考虑：

1. 其他确认措施的规划[见6.4.3.5 i]；

2. 确认评审和功能安全审计的结果；

3. 先前功能安全评估给出的建议（如适用）（见6.4.9.7、6.4.9.8和ISO26262-8:2011， 8.4.5.2）。

6.4.9.6 根据6.4.9.3，功能安全评估报告应包括相关项功能安全的接受、有条件接受或拒绝的建议。在有条件接受的情况下：

1. 如果相关项的功能安全经过考虑后被认为是明显的、已确定的开发性问题；

2. 有条件验收的建议应包括与功能安全评估标准的偏差，以及特定偏差被认为可接受的原因。

6.4.9.7 若根据6.4.9.6的功能安全评估报告中的建议是有条件接收，那么就要执行功能安全评估报告中提供的纠正措施。

6.4.9.8 如果6.4.9.6的功能安全评估报告中的建议是拒绝，那么：

1. 应采用适当的纠正措施；

2. 应重复功能安全评估。

6.5 工作产品

6.5.1 安全计划，产生于6.4.3 到 6.4.5；

6.5.2 项目计划（优化后），产生于6.4.3.4；

6.5.3 安全用例，产生于6.4.6；

6.5.4 功能安全评估计划，产生于6.4.9；

6.5.5 确认措施报告，产生于6.4.9.

7 投产后的安全管理

7.1 目的

本条款的目的是明确项目投产后的组织机构和功能安全负责人的责任。涉及到投产后的生命周期子阶段中，相关项所需功能安全的一般活动。

7.2 概述

见5.2.

7.3 本条目的输入

7.3.1 前提条件

以下信息应该有效：

• 基于5.5.3的质量管理；

7.3.2 更多支持信息

无。

7.4 需求和建议

7.4.1 概述

涉及到安全生命周期执行的组织，要遵守7.4.2，其相关项至少有一个ASIL A/B/C/D的安全目标。

7.4.2 责任、计划于所需流程

7.4.2.1 组织应根据第5.4.2.8的规定，制定负责人并进行一定授权，保证投产后产品的功能安全。

7.4.2.2 按照ISO26262-7的要求，规划投产后的产品功能安全活动，并在产品系统开发阶段按照ISO26262-4的要求启动这些活动。

7.4.2.3 组织应建立、执行和维护流程，使得产品的功能安全在投产后的生命周期阶段中继续保持。

7.4.2.4 组织应建立、执行和维护与相关项功能安全相关的现场监控流程。

注1：安全事故现场检测过程包括事故报告、纠正措施（如召回）以及相应决策过程。

注2：现场检测收集的数据可用于在用证明（见ISO26262-8:2011第14条）。

7.4.2.5 如果相关项投产后发生变化，应根据ISO26262-4:2011第11条重新进行生产发布（投产）。

注：这些变更应接受变更管理（见ISO26262-8:2011第8条）。

7.5 工作产品

7.5.1 现场监控证据，产生于7.4.2.4。

 

附录：