作者|booksoser
来源|汽车电子硬件设计
6.1目的
相关项依赖安全管理的目的是确保参与概念阶段或开发阶段的组织在系统、硬件或软件层面实现以下目标:
A. 定义和分配有关安全活动的角色和责任;
B. 在相关项层面进行影响分析,以确定该相关项是一个新相关项、对一个现有相关项的修改,还是一个具有修改环境的现有相关项;一次或多次修改的情况下,分析所确定的修改对功能安全的影响;
C. 在复用现有要素的情况下,在要素层面执行影响分析,以评估复用的要素是否能够符合分配给该要素的安全要求,同时考虑到该要素被复用的运行环境;
注:相关项或要素层面的影响分析可以支持安全活动的计划(见6.4.6.7)。
D. 定义量身定做的安全活动,为裁剪提供相应的理由,并评审所提供的理由;
E. 计划安全活动;
F. 根据安全计划协调和跟踪安全活动的进展;
G. 计划分布式开发(见ISO26262-8:2018,第5条);
H. 确保安全活动在整个安全生命周期中的正确进展;
I. 创建一个可理解的安全档案,为实现功能安全提供论据;
J. 判断相关项是否达到功能安全(即。功能安全评估),或判断对实现某一要素的功能安全的贡献(即。供应商执行的功能安全评估活动)或工作成果(例如:认可评审);及
K. 在开发结束时,根据支持对所实现的功能安全的置信度的证据,决定该相关项或要素是否可以发布用于生产。
6.2概述
在一个相关项中,有关安全活动的角色和责任被定义和分配。
在相关项层面进行影响分析,以确定该相关项是新相关项、对现有相关项的修改还是具有修改环境的现有相关项。在修改的情况下,分析了对功能安全的影响。
在考虑到复用要素的运行环境的情况下,在要素层面执行影响分析。
安全管理包括有责任计划和协调安全活动,对照相应的计划跟踪安全活动的进展,并描述和证明量身定做的安全活动。
安全计划被记录下来,并引用开发接口协议(见ISO26262-8:2018,第5条),这些协议定义了分布式开发中与其他各方的安全计划的接口。
安全管理还包括确保认可措施得到执行的责任。根据适用的ASIL,认可措施在资源、管理和发布权限方面具有足够的独立性。
认可措施包括认可评审,功能安全审核和功能安全评估:
认可评审旨在判断关键工作成果(见表1)是否提供
Ø 充分和令人信服的证据表明它们对实现功能安全的贡献;
Ø 如果适用,功能安全审核评估安全活动所需流程的实施;及
Ø 如果适用,功能安全评估判断相关项是否达到功能安全,或判断对实现功能安全的贡献,例如。关于要素的开发。
表1列出了认可措施。
除认可措施外,还进行验证活动。这些验证活动符合ISO26262系列标准其他部分的要求,旨在验证相关工作成果是否符合相关项要求和技术要求,特别是在用例和故障模式方面。
最后,负责发布相关项或相关项要素的人根据支持对实现的功能安全的置信度的证据,决定相关项或要素是否准备好进行批量生产和运行。
6.3.相关项依赖安全管理的输入
6.3.1前提条件
应提供下列资料:
Ø 符合5.5.1的组织特定的功能安全规则和流程;
Ø 符合5.5.2的能力管理证据;及
Ø 符合5.5.3的质量管理体系的证据。
6.3.2进一步的支持信息
如有,可考虑以下信息:
Ø 项目计划(来自外部来源);
Ø 依赖其他活动,包括其他安全活动;及
Ø 用于进行冲击分析的其他现有信息(见6.4.3和6.4.4)。
示例:产品概念、修改请求、实现计划或在使用论据中证明。
6.4.要求和建议
6.4.1概述
第6.4.2至6.4.13款适用于参与该相关项的概念阶段或产品开发阶段(系统、硬件或软件)或该相关项的一个或多个要素的组织。
示例:开发一个要素的供应商,预期由客户集成(见ISO26262-8:2018,第5条),该供应商按照4.4与ASIL A、B、C或D一起执行一个或多个安全要求。
6.4.2.安全管理中的角色和职责.
6.4.2.1项目经理应在开始有关该相关项的产品开发时任命。
注:在分布式开发的情况下(见ISO26262-8:2018,第5条),项目经理是在客户和供应商指定的,他们开发了一个或多个预期集成的要素。
6.4.2.2赋予项目经理职责和权限,符合5.4.2.7,确保:
Ø 实现功能安全所需的安全活动被执行;及
Ø 符合ISO26262。
6.4.2.3项目经理应按照5.4.2.5的规定,核实组织已提供安全活动所需资源。
注:充分资源的估计、确定和分配包括在计划中。
6.4.2.4项目经理应确保安全经理的任命符合5.4.4的规定。
注1:安全经理的角色可以由项目经理完成。
注2:由于“安全经理”一词被定义为一个角色(见ISO26262-1),它的任务可以根据组织的不同在不同的人之间分开。
注3:在分布式开发的情况下(见ISO26262-8:2018,第5条),安全经理是在客户和供应商指定的,他们开发了一个或多个预期集成的要素。
6.4.3.相关项层面的影响分析.
6.4.3.1在安全生命周期开始时,应在相关项层面进行影响分析,以确定该相关项是新开发、对现有相关项的修改还是具有修改环境的现有相关项。
注:在用证明的参数可以应用于修改(见ISO26262-8:2018,第14条)。
6.4.3.2在对某一相关项或其环境进行修改的情况下,根据第16.4.3在相关项层面进行的影响分析应确定并描述对该相关项适用的修改,包括:
注1:本条款中考虑的影响分析涉及对计划阶段所审议相关项的修改。在开发执行过程中考虑的设计修改是通过变更管理过程实现的(见ISO26262-8:2018,第8条)。
a. 对设计的修改;
注2:设计修改可以从需求修改中产生。注3:设计修改可能影响相关项的行为。
示例1:校准数据修改后的设计修改
示例2:由于实施的相关项修改的运行模式的改变而产生的设计修改;
b. 实施的修改;及
注4:实施修改非预期影响相关项的规格或性能。
注5:对相关项的实施修改可能影响相关项的行为。
注6:实现修改可能是由于软件的更正。
c. 与环境有关的修改。
示例3:温度、高度、湿度、振动、电磁干扰(“EMI”)和燃料类型
注7:修改包括:
Ø 在新的目标环境中安装相关项(例如:另一种车辆变型);
Ø 运行情况的变更;及
Ø 车辆内相关项的不同位置。
6.4.3.3根据第26.4.3在相关项层面进行的影响分析应:
评估修改对功能安全的影响;及
根据修改的影响,确定和描述要执行的安全活动。
6.4.4.复用现有要素
在复用现有要素的情况下,应在要素层面进行影响分析,应:
A. 确定对运行环境的修改,包括由此产生的要素修改;
B. 评估复用的要素是否能够符合从所考虑的要素集成到其中的相关项或要素中所分配的安全要求;
注1:现有要素可以在计划对该要素进行修改或不进行修改的情况下复用。例如,可以计划对要素进行修改,以便集成现有要素。
C. 根据对修改的影响的评估,包括对先前所作假设的有效性的影响,确定要进行的安全活动;以及
D. 评估有关复用要素的现有安全相关文档是否足以支持将要素集成到要集成所考虑的要素的相关项或要素中。
注2:本条款中考虑的影响分析涉及对计划阶段所考虑的要素的运行背景的修改。在开发执行过程中考虑的设计修改是通过变更管理过程实现的(见ISO26262-8:2018,第8条)。
注3:现有要素可以复用:
a. 基于对硬件要素的评估(见ISO26262-8:2018,第13条),
b. 基于【软件组件的资格】(见【软件组件的资格】(ISO26262-8:2018,第12条)),
c. 基于【在用证明】参数(见ISO26262-8:2018,第14条),或
d. 基于【独立于环境的安全要素】(见ISO26262-10)。
6.4.5.安全活动的裁剪
6.4.5.1与某一特定相关项开发有关的安全活动可加以调整,即。省略或以不同于参考ISO26262生命周期中规定的方式执行。如果这样的安全活动是量身定做的,则:
A. 裁剪应在安全计划中定义(见6.4.6.5,b);及
B. 应提供理由说明为什么裁剪是适当和足够的,以实现功能安全。
注1:理由考虑相应要求的ASIL等级。
注2:裁剪的理由包括在安全计划中,并在认可评审安全计划(见6.4.9)或在功能安全评估(见6.4.12)期间进行评审。
注3:本要求适用于针对特定相关项的应用进行裁剪。关于组织内跨相关项开发应用流程的安全生命周期的裁剪,只有5.4.6适用。
6.4.5.2如果根据6.4.3或6.4.4进行冲击分析后,根据第6.4.5.1对安全活动进行裁剪,则裁剪应符合6.4.6.7。
6.4.5.3.如果存在在用证明而按照6.4.5.1对某一安全活动进行剪裁时,则裁剪应符合ISO26262-8:2018,第14条。
6.4.5.4如果由于对硬件要素的评估,安全活动是按照6.4.5.1对某一安全活动进行剪裁时,则裁剪应符合ISO26262-8:2018,第13条。
6.4.5.5如果由于软件组件的资格,安全活动是按照6.4.5.1对某一安全活动进行剪裁时,则裁剪应符合【软件组件的资格】(ISO26262-8:2018,第12条)。
6.4.5.6.如果是基于考虑所使用软件工具的置信度而按照6.4.5.1对某一安全活动进行剪裁,则裁剪应符合【软件工具使用的置信度】(ISO26262-8:2018,第11条)。
6.4.5.7如果是因为要素独立于相关项开发而按照6.4.5.1的要求对安全活动进行剪裁(“SEooC【独立于环境的安全要素】”),则:
a. 独立于环境的安全要素的开发应基于从对预期用途和环境的假设(包括其外部接口)导出的需求规范;以及
b. 应确认独立于环境的安全要素的预期用途和应用环境的假设的有效性。
注1:ISO26262系列标准作为一个整体不能应用于作为安全要素开发的要素,因为功能安全不是要素属性(然而,相关项的要素可以被识别为安全相关的要素)。功能安全是一种相关项属性,可以通过功能安全评估来评估。
示例:一个微控制器作为一个安全元件开发出的背景
注2:有关独立于环境的安全要素开发的进一步细节,请参见ISO26262-10。
6.4.5.8本要求适用于T&B的相关项开发:如果超出ISO26262系列标准范围的应用流程正在与根据这些标准开发的基本车辆或项目接口,则应按照【独立于ISO26262应用的接口】(ISO26262-8:2018,第15条)进行相应的安全活动的裁剪。
6.4.5.9本要求适用于T&B的项目开发:如果安全活动是为了使人们相信未按照ISO26262系列标准开发的系统或组件满足按照这些标准开发的相关项所需的功能安全水平,则这些安全活动的裁剪应按照ISO26262-8:2018,第16条进行。
6.4.6.安全活动的策划与协调
6.4.6.1根据5.4.2.7,安全经理应负责组织所参与的安全活动的计划和协调。
注1:安全经理可以将任务委托给具有所需技能、能力和资格的人(见5.4.4)。
注2:根据相关项是新开发、对现有相关项或具有修改环境的现有相关项的修改(见6.4.3),或该要素是新的还是沿用的(见6.4.4),安全活动的范围可能有所不同,活动也相应地计划。
6.4.6.2安全管理人员应负责维护安全计划,并对照安全计划对安全活动进行进度监控。
6.4.6.3应按照5.4.2.7和5.4.4在组织内明确分配和传达执行安全活动的责任。
注安全管理人员负责安全活动的策划和协调。其他人可以负责详细计划(另见6.4.6.8)或执行安全活动(例如:计划或执行集成和验证活动和配置管理)。
6.4.6.4安全计划应为:
A. 在项目计划中引用,或
B. 包括在项目计划中,以便安全活动是可区分的。
注:安全计划可以包含对配置管理下的其他信息的交叉引用(见【配置管理】(ISO26262-8:2018,第7条))。交叉引用通常比在不同的工作成果或处于配置管理中的其他文档中并行描述活动更可取。
6.4.6.5安全计划应确定实现功能安全的活动和流程的计划,包括:
a. 根据第5条,将项目独立的安全活动实施到相关项特定的安全管理中;
b. 根据6.4.5(如果适用的话)对定制安全活动的定义;
注1:例如,在相关项层面(见6.4.3)或在单元层面(见6.4.4)进行冲击分析后进行裁剪。另见6.4.6.7。
c. 安全活动的计划符合ISO26262-3、ISO26262-4、ISO26262-5和ISO26262-6的要求;
d. 根据ISO26262-8计划支持过程,包括在适用的情况下,参考开发接口协议(“DIA”),根据ISO26262-8:2018,第5条定义与分布式开发中其他各方的安全计划的接口;
e. 按照ISO26262-3、ISO26262-4、ISO26262-5、ISO26262-6和ISO26262-8:2018第9条的要求计划集成和验证活动;并按照ISO26262-4:2018第8条计划安全确认活动;
注2:工作成果“安全计划”包括详细的集成、验证和安全确认计划,但这种计划可以在其他文件中(见ISO26262-8:2018,第10条)。
f. 根据6.4.9至6.4.12安排认可评审、功能安全审核和功能安全评估;
注3:实施认可措施的人在6.4.9中给出的独立性程度在安全计划中规定。
注4:安全经理负责安排认可措施。认可措施的细节由负责该认可措施的人计划。计划分析相关故障,如果适用的话,并进行安全分析,以符合ISO26262-3、ISO26262-4、ISO26262-5、ISO26262-6、ISO26262-9:2018、第7条和ISO26262-9:2018、第8条的要求;
注5:安全分析的目标和范围是在其计划过程中确定的,并取决于相应的子阶段和背景。
g. 根据ISO26262-8:2018提供经证实的候选项使用论据,
h. 第14条,如果适用的话;及
i. 根据【软件工具使用的置信度】(ISO26262-8:2018,第11条),如果适用的话,对软件工具的使用提供可信度。
6.4.6.6安全活动的策划应包括:
A. 目标;
B. 对其他活动或信息的依赖性;
C. 负责执行活动的人;
D. 执行活动所需的资源;
E. 起点或终点时间和持续时间;
F. 和f):相应工作成果的识别。
6.4.6.7在相关项修改的情况下,根据6.4.3对现有相关项的环境进行修改,或者在根据6.4.4:复用某一要素的情况下:
a. ISO26262系列标准的参考安全生命周期应根据相应的影响分析结果量身定做;
注1:考虑到适用的生命周期阶段和子阶段,在安全计划中定义了量身定做的安全活动(见6.4.5)。
b. 需要创建或更新的受影响的工作成果应相应地识别、描述和重新加工;及
注2:受影响的工作成果包括安全确认规范(见ISO26262-4:2018,第8条)。
c. 如果安全文件不符合ISO26262系列标准,则应确定符合这些标准相应要求的必要活动。
示例1:根据与ISO26262系列标准不同的安全标准开发的要素,相应的安全文件不完整,以符合ISO26262
示例2:继承要素,但缺少安全文档,或安全文档不足以符合ISO26262
6.4.6.8安全计划应在每个阶段开始时至少逐步更新。
注:至少在每个阶段的开始,安全计划被更新,以便详细计划该阶段的安全活动。安全计划可以在一个子阶段进一步详细说明。
6.4.6.9安全计划所要求的工作成果应在开发阶段保持最新,以便在生产发布之前和发布时保持相关项或要素的适当表示。
6.4.6.10在分布式开发的情况下,客户和供应商都应确定有关各自安全活动的安全计划。
注:相应的开发接口协议是根据【分布式开发接口】(ISO26262-8:2018,第5条)定义的。
已完成
数据加载中