[PDF] GB/T 34590.2-2017 - 自动发货. 英文版
| 标准号码 | 美元 | 购买PDF | 工期 | 标准名称(英文版) |
| GB/T 34590.2-2017 | 145 | GB/T 34590.2-2017 | 9秒内发货PDF | 道路车辆 功能安全 第2部分：功能安全管理 |
| 基本信息 | |
|---|---|
| 标准编号 | GB/T 34590.2-2017 (GB/T34590.2-2017) |
| 中文名称 | 道路车辆 功能安全 第2部分：功能安全管理 |
| 英文名称 | Road vehicles -- Functional safety -- Part 2: Management of functional safety |
| 行业 | 国家标准 (推荐) |
| 中标分类 | T35 |
| 国际标准分类 | 43.040 |
| 字数估计 | 30,382 |
| 发布日期 | 2017-10-14 |
| 实施日期 | 2018-05-01 |
| 发布机构 | 中华人民共和国国家质量监督检验检疫总局、中国国家标准化管理委员会 |
GB/T 34590.2-2017
道路车辆 功能安全 第2部分：功能安全管理
Road vehicles -- Functional safety -- Part 2: Management of functional safety
1 范围
GB/T 34590的本部分规定了应用于汽车领域的功能安全管理的要求,包括:
---独立于项目的关于所涉及组织的要求(整体安全管理);及
---项目特定的在安全生命周期内关于管理活动的要求(例如在概念阶段、产品开发阶段以及生产
发布
后的管理)。
本标准适用于安装在量产乘用车上的包含一个或多个电子电气系统的与安全相关的系统。
本标准不适用于特殊用途车辆上特定的电子电气系统,例如,为残疾驾驶者设计的车辆。
本标准不适用于已经完成生产发布的系统及其组件或在本标准发布日期前开发的系统及其组件。
对于在本标准发布
前完成生产发布的系统及其组件进行进一步的开发或变更时,仅修改的部分需要按
照本标准开发。
本标准针对由电子电气安全相关系统的故障行为而引起的可能的危害,包括这些系统相互作用而
引起的可能的危害。本标准不针对与触电、火灾、烟雾、热、辐射、毒性、易燃性、反应性、腐蚀性、能量释放等相关的危害和类似的危害,除非危害是直接由电子电气安全相关系统的故障行为而引起的。
本标准不针对电子电气系统的标称性能,即使这些系统(例如主动和被动安全系统、制动系统、自适
应巡航控制系统)有专用的功能性能标准。
2 规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅注日期的版本适用于本文
件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。
GB/T 34590.1-2017 道路车辆 功能安全 第1部分:术语(ISO 26262-1:2011,MOD)
GB/T 34590.3-2017 道路车辆 功能安全 第3部分:概念阶段(ISO 26262-3:2011,MOD)
GB/T 34590.4-2017 道路车辆 功能安全 第4部分:产品开发:系统层面(ISO 26262-4:2011,
MOD)
GB/T 34590.5-2017 道路车辆 功能安全 第5部分:产品开发:硬件层面(ISO 26262-5:2011,
MOD)
GB/T 34590.6-2017 道路车辆 功能安全 第6部分:产品开发:软件层面(ISO 26262-6:2011,
MOD)
GB/T 34590.7-2017 道路车辆 功能安全 第7部分:生产和运行(ISO 26262-7:2011,MOD)
GB/T 34590.8-2017 道路车辆 功能安全 第8部分:支持过程(ISO 26262-8:2011,MOD)
GB/T 34590.9-2017 道路车辆 功能安全 第9部分:以汽车安全完整性等级为导向和以安全
为导向的分析(ISO 26262-9:2011,MOD)
3 术语、定义和缩略语
GB/T 34590.1-2017界定的术语、定义和缩略语适用于本文件。
4 要求
4.1 一般要求
如声明满足GB/T 34590-2017的要求时,应满足每一个要求,除非有下列情况之一:
a) 按照本部分的要求,已经计划了安全活动的剪裁并表明这些要求不适用;或
b) 不满足要求的理由存在且是可接受的,并且按照本部分对该理由进行了评估。
标有“注”或“示例”的信息仅用于辅助理解或阐明相关要求,不应作为要求本身且不具备完备性。
将安全活动的结果作为工作成果。应具备上一阶段工作成果作为“前提条件”的信息。如果章条的
某些要求是依照ASIL定义的或可剪裁的,某些工作成果可不作为前提条件。
“支持信息”是可供参考的信息,但在某些情况下,GB/T 34590-2017不要求其作为上一阶段的工
作成果,并且可以是由不同于负责功能安全活动的人员或组织等外部资源提供的信息。
4.2 表的诠释
表属于规范性表还是资料性表取决于上下文。在实现满足相关要求时,表中列出的不同方法有助
于置信度水平。表中的每个方法是:
a) 一个连续的条目(在最左侧列以顺序号标明,如1,2,3);或
b) 一个选择的条目(在最左侧列以数字后加字母标明,如2a,2b,2c)。
对于连续的条目,全部方法应按照ASIL等级推荐予以使用。除了所列出的方法外,如果应用所列
出方法以外的其他方法,应给出满足相关要求的理由。
对于选择性的条目,应按照指定的ASIL等级,对这些方法进行适当的组合,不依赖于这些方法是
否在表中列出。如果所列出的方法对于一个ASIL等级来说具有不同的推荐等级,宜采用具有较高推
荐等级的方法。应给出所选的方法组合满足相关要求的理由。
注:表中所列出的方法的理由是充分的。但是,这并不意味着有倾向性或对未列到表中的方法表示反对。
对于每种方法,应用相关方法的推荐等级取决于ASIL等级,分类如下:
---“++”表示对于指定的ASIL等级,高度推荐该方法;
---“+”表示对于指定的ASIL等级,推荐该方法;
---“o”表示对于指定的ASIL等级,不推荐也不反对该方法。
4.3 基于ASIL等级的要求和建议
若无其他说明,对于ASILA、B、C和D等级,应满足每一子章条的要求或建议。这些要求和建议参照
安全目标的ASIL等级。如果在项目开发的早期对ASIL等级完成了分解,应按照GB/T 34590.9-2017
第5章,遵循分解后的ASIL等级。
如果GB/T 34590-2017中ASIL等级在括号中给出,则对于该ASIL等级,相应的子章条应被认
为是推荐而非要求。这里的括号与ASIL等级分解无关。
5 整体安全管理
5.1 目的
本章的目的是定义负责安全生命周期或在安全生命周期内执行安全活动的组织的要求。
本章是GB/T 34590安全生命周期内所有活动的前提条件。
5.2 总则
5.2.1 安全生命周期概述
GB/T 34590安全生命周期(见图2)包含了在概念阶段、产品开发、生产、运行、服务和报废期间的
主要安全活动。计划、协调和记录安全生命周期所有阶段的安全活动是关键的管理任务。
图2描述了安全生命周期的参考模型,允许进行安全生命周期的剪裁,包括子阶段迭代。
注1:GB/T 34590.3-2017(概念阶段)、GB/T 34590.4-2017(产品开发:系统层面)、GB/T 34590.5-2017(产品开发:硬件层面)、GB/T 34590.6-2017(产品开发:软件层面)和GB/T 34590.7-2017(生产和运行)分别详细描述了在概念阶段、产品开发过程和生产发布后的安全活动。
注2:附录A中表A.1概括了功能安全管理特定阶段的目的、前提条件和工作成果。
注:在图中,GB/T 34590-2017各部分中的具体条款用以下方式表示:“m-n”,m代表部分的数值,n代表章的数值。例如:3-6代表GB/T 34590.3-2017的第6章。
5.2.2 安全生命周期的解释说明
GB/T 34590-2017不仅定义了针对安全生命周期内特定阶段和特定子阶段的要求,同时也定义
了适用于安全生命周期中多个或全部阶段的要求,例如功能安全管理要求。
关键的管理任务是计划、协调和追踪与功能安全相关的活动。这些管理任务适用于安全生命周期
的所有阶段。本部分给出了功能安全管理的要求,分别是:
---整体安全管理(见本章);
---概念阶段和产品开发阶段的安全管理(见第6章);
---相关项生产发布后的安全管理(见第7章)。
安全生命周期中不同阶段和子阶段的定义以及其他关键概念的解释描述如下:
a) 子阶段:相关项定义
安全生命周期的初始任务是对相关项的功能、接口、环境条件、法规要求、已知危害等进行描
述。确定相关项的边界及其接口,以及与其他相关项、要素、系统和组件相关的假设(参见
GB/T 34590.3-2017第5章)。
b) 子阶段:安全生命周期启动
在完成相关项定义的基础上,通过确定所开发的相关项是一个全新的开发还是对现有相关项
的修改来启动安全生命周期。
如果是对现有相关项的修改,对其所做的影响分析的结果可用于剪裁安全生命周期(参见
GB/T 34590.3-2017第6章)。
c) 子阶段:危害分析和风险评估
安全生命周期启动后,应按照GB/T 34590.3-2017第7章的要求进行危害分析和风险评估。
首先,通过危害分析和风险评估预测与相关项相关的危害事件所处工况的暴露概率、危害事件
的可控性和严重度,这些参数共同决定了危害事件的汽车安全完整性等级(ASIL)。然后,通
过危害分析和风险评估确定相关项的安全目标,安全目标是相关项的最高层面的安全要求。
将所确定的危害事件的ASIL等级分配给相应的安全目标。
后续阶段和子阶段中详细的安全要求来自安全目标,这些安全要求继承了相应安全目标的
ASIL等级。
d) 子阶段:功能安全概念
基于安全目标,同时考虑初步的构架设想以定义功能安全概念(参见GB/T 34590.3-2017第
8章)。功能安全概念是通过分配给相关项要素的功能安全要求来定义的。如果能够对涉及
的其他技术或与外部措施接口的期望行为进行确认,功能安全概念可包括其他技术或与外部
措施的接口(参见GB/T 34590.4-2017第9章)。其他技术的实施不在本标准范围内,且外部
措施的实施不在相关项开发范围内。
e) 阶段:产品开发:系统层面
在定义了功能安全概念后,应按照GB/T 34590.4-2017,从系统层面进行相关项的开发。系
统开发流程基于V模型概念,V模型左侧包含技术安全要求的定义、系统架构、系统设计和实
现,V模型右侧包含集成、验证、确认和功能安全评估。
系统层面产品开发包括对发生在安全生命周期内其他阶段活动的确认任务:
---对通过其他技术实现功能安全概念的确认;
---对外部措施有效性的假设的确认和对性能的假设的确认;及
---对人员反应所做假设的确认,包括可控性和操作任务。
生产发布是产品开发的最后子阶段,并提供相关项量产发布(参见GB/T 34590.4-2017第11
章)。
f) 阶段:产品开发:硬件层面
基于系统设计规范,从硬件层面进行相关项的开发(参见GB/T 34590.5-2017)。硬件开发流
程基于V模型概念,V模型左侧包含硬件要求的定义、硬件设计和实现,V模型右侧包含硬件
集成和测试。
g) 阶段:产品开发:软件层面
基于系统设计规范,从软件层面进行相关项的开发(参见GB/T 34590.6-2017)。软件开发流
程基于V模型概念,V模型左侧包含软件要求的定义、软件架构设计和实现,V模型右侧包含
软件集成、测试和软件要求验证。
h) 生产计划和运行计划
生产计划和运行计划以及相关要求的定义在系统层面产品开发过程中启动(参见
GB/T 34590.4-2017)。GB/T 34590.7-2017第5章和第6章中给出了生产和运行的要求。
i) 阶段:生产和运行,服务和报废
该阶段描述了与相关项的功能安全目标相关的生产过程,即与安全相关的特殊特性,以及对相
关项的维护、维修、报废的指导说明的开发和管理,以确保相关项在生产发布后的功能安全(参
见GB/T 34590.7-2017第5和第6章)。
j) 可控性
在危害分析和风险评估中(参见GB/T 34590.3-2017第7章),驾驶员或其他涉险人员控制危
害情况能力的可信度。在安全确认过程中,需要确认在危害分析和风险评估、功能安全概念和
技术安全概念中关于可控性的假设(参见图2和GB/T 34590.4-2017第9章)。
注:暴露概率和严重度依赖于场景,通过人为干预的最终可控性受相关项设计的影响,因此,在确认过程中进行评估(参见GB/T 34590.4-2017的9.4.3.2)。
k) 外部措施
外部措施指相关项外部的措施,在相关项定义里对其进行了规定(参见图2和GB/T 34590.3-
2017第5章),用于减少或减轻来自相关项的风险。外部措施不仅包括附加的车载装置如动
态稳定控制器或防爆轮胎,而且也可包括车辆以外的装置如防撞栏或隧道消防系统。
在安全确认过程中,需要确认在相关项定义、危害分析和风险评估、功能安全概念和技术安全
概念中关于外部措施的假设(参见图2和GB/T 34590.4-2017第9章)。
可在危害分析和风险评估过程中考虑外部措施,然而,如果可信度来自危害分析和风险评估过
程中的外部措施,则在功能安全概念中不能认为此外部措施是一个减少风险的途径。
GB/T 34590-2017同样适用于其范围内的那些外部措施。
l) 其他技术
其他技术,如机械和液压技术,不同于本标准适用范围内的电子电气技术。这些技术可在
功能安全概念制定中(参见图2及 GB/T 34590.3-2017第8章)、安全要求分配中(参见
GB/T 34590.3-2017及GB/T 34590.4-2017)或作为外部措施被考虑。
注:如果其他技术被定义为外部措施,则考虑到降低相关风险而重新进行危害分析和风险评估是有益的,这样做可能会降低相关安全目标的ASIL等级。
5.3 本章的输入
5.3.1 前提条件
无。
5.3.2 支持信息
可考虑如下信息:
质量管理体系符合质量管理标准(如:ISO/T S16949、ISO 9001或等同要求)的证据。
5.4 要求和建议
5.4.1 总则
执行安全生命周期活动的组织应满足5.4.2~5.4.5。
5.4.2 安全文化
5.4.2.1 组织应创造、培育并保持一种安全文化,以支持并鼓励有效地实现功能安全。
示例:附录B中给出了评估安全文化的例子。
5.4.2.2 组织应建立、执行并维护专门的规章和流程,以符合GB/T 34590-2017的要求。
注:组织的专门的规章和流程可包括创建并维护通用的安全计划和流程描述。
5.4.2.3 组织应建立并维护功能安全领域与功能安全相关的其他领域之间的有效沟通渠道。
示例1:建立功能安全与信息安全之间的沟通渠道,以便于两者交互相关信息,例如,功能安全危害分析和风险评估的结果、信息安全威胁分析和风险评估的结果、功能安全目标、信息安全目标、功能安全概念、信息安全策略等。
注:功能安全针对的是由电子电气系统的内部故障行为而导致的问题,而信息安全针对的是外部恶意事件(攻击)导致的问题。在开发过程中,一些功能安全活动和信息安全活动是相类似的。为了达到产品的整体安全,功能安全和信息安全之间是有协作的,功能安全活动的输出可关系到或影响到信息安全活动,反之亦然。两者之间的交互和融合能促进产品更好的达到整体上的安全性。
示例2:建立功能安全与机械安全之间的信息沟通渠道。
5.4.2.4 组织应建立、执行并维护流程以确保识别出的功能安全异常能够明确地通报给安全经理和其
他责任者。
示例:安全经理和其他责任者可以是客户安全经理、供应商安全经理,以及与相关项开发相关的安全经理。
5.4.2.5 组织应建立、执行并维护解决安全异常的流程,以确保及时、有效地对功能安全异常进行分析、评估、解决和处理。
注:功能安全异常的解决流程可包括根本原因分析,由该根本原因分析得出对以后的修正行动。
5.4.2.6 在安全生命周期内,组织应执行所需的功能安全活动,包括相关文档的生成和管理(按照
GB/T 34590.8-2017第10章的说明)。
5.4.2.7 组织应为功能安全的实现提供所需的资源。
注:人力资源、工具、数据库和模板。
5.4.2.8 基于以下几点,组织应建立、执行并维护持续改进的流程:
---从其他相关项安全生命周期的执行过程中学习经验,包括现场经验;
---将获得的改进应用于后续相关项。
5.4.2.9 组织应确保给予执行或支持安全活动的人员以足够的权限来履行他们的职责。
5.4.3 能力管理
组织应确保执行安全生命周期活动的人员具有与其职责相匹配的技能水平、能力和资质。
注1:在开发过程中,达到足够的技能水平和能力的方法之一是考虑以下知识领域的培训和资质培养:
---常规的安全实践、概念和设计;
---GB/T 34590-2017和其他适用的安全标准;
---用于功能安全组织的专门规则;
---组织所建立的功能安全流程。
注2:为了评估执行满足GB/T 34590-2017的活动所需的技能、能力和资质,可以考量以往的专业活动经验,如:
---相关项专业领域的知识;
---相关项相关领域的专业知识;
---管理经验。
5.4.4 安全生命周期中的质量管理
执行安全生命周期活动的组织应具有满足质量标准如ISO/T S16949、ISO 9001或等同标准的质
量管理体系。
5.4.5 独立于项目的安全生命周期剪裁
组织可剪裁安全生命周期,应用于各相关项的开发,即独立于项目的剪裁,但仅限于以下的一种或
多种方式:
a) 合并或分解子阶段、活动或任务;或
注:如果所用的方法难以清晰地区分单独的子阶段,则可以合并单独的子阶段。例如,计算机辅助开发工具能在一个步骤中支持多个子阶段的活动。
b) 同一活动或任务可在不同的阶段或子阶段中执行;或
c) 同一活动或任务可在新增的阶段或子阶段中执行;或
d) 反复进行某个阶段或子阶段。
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)。
认可措施包括认可评审、功能安全审核和功能安全评估:
---认可评审的目的是核查工作成果是否符合GB/T 34590-2017的要求;
---功能安全审核的目的是评价功能安全活动所需要的流程的执行情况;
---功能安全评估的目的是评价相关项是否实现了功能安全。
除了认可措施外,还需进行验证评审。GB/T 34590-2017的其他部分也要求这些评审,目的是验
证相关的工作成果满足项目的要求,以及与应用案例和失效模式相关的技术要求。
表1列出了所需的认可措施。附录D列出了关于验证的评审,及所参考的本标准的适用部分。
安全管理有责任对所有剪裁的安全活动(参见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 总则
对于至少有一个安全目标为ASILA、B、C或D的相关项,执行安全生命周期活动的组织应满足
6.4.2~6.4.9的要求,除非有其他说明。
6.4.2 安全管理的角色和职责
6.4.2.1 在相关项开发的启动阶段应指定一名项目经理。
6.4.2.2 应赋予项目经理责任和权限,按照5.4.2.9的要求,确保:
a) 执行实现功能安全所需的安全活动;
b) 满足GB/T 34590-2017的要求。
6.4.2.3 项目经理应确认组织提供了符合5.4.2.7要求的功能安全活动所需的资源。
注:通常在计划阶段对足够的资源进行预估、确定和分配。
6.4.2.4 项目经理应确保已指定了符合5.4.3要求的安全经理。
注1:安全经理的角色可以由项目经理承担。
注2:GB/T 34590.1-2017定义了“安全经理”,在矩阵式组织里,安全经理的任务可以分配给不同的人。
6.4.3 安全活动的计划和协调
6.4.3.1 按照5.4.2.9的要求,在安全生命周期的开发阶段,安全经理应负责计划和协调功能安全活动。
注1:安全经理可将任务分配给具有所需技术、能力和资质的人员。
注2:安全活动的计划包含在安全计划(参见6.4.3.5)中。某些已纳入安全计划中的安全活动在 GB/T 34590-2017的其他工作成果(参见6.4.3.3)中进一步细化。
注3:基于相关项是一个全新开发还是一个对既有相关项的修改(参见GB/T 34590.3-2017第6章),安全活动可以不同,并据此计划相应的安全活动。
6.4.3.2 安全经理应负责维护安全计划并监督安全活动的进度是否按照安全计划进行。
6.4.3.3 在组织内部应按照5.4.2.9和5.4.3的要求,分配并通报关于细化和协调如下计划中安全活动
的责任:
---相关项的集成和测试计划,按照GB/T 34590.4-2017;
---确认计划,按照GB/T 34590.4-2017;
---软件验证计划,按照GB/T 34590.6-2017;及
---功能安全评估计划,按照6.4.9。
责任人应负责维护各自的安全计划并监督安全活动的进度是否按照各自的安全计划进行。
6.4.3.4 安全计划应:
a) 在项目计划中被引用;或
b) 包含在项目计划中,并使安全活动是可区分的。
注:在配置管理下,安全计划可交叉引用其他信息(参见GB/T 34590.8-2017第7章)。交叉引用通常优于在不同工作成果或在配置管理下的其他文档里对活动的重复描述。
6.4.3.5 安全计划应包括:
a) 实现功能安全的活动计划和流程计划;
b) 将独立于项目的安全活动应用到项目特定的安全管理中,按照第5章;
c) 如果适用,所剪裁的安全活动的定义,按照6.4.5;
d) 危害分析和风险评估计划,按照GB/T 34590.3-2017第7章;
e) 开发活动计划,包括按照GB/T 34590.3-2017第8章进行功能安全概念的开发和实施、按照
GB/T 34590.4-2017进行产品系统层面的开发和实施、按照GB/T 34590.5-2017进行产品
硬件层面的开发和实施、按照GB/T 34590.6-2017进行产品软件层面的开发和实施;
f) 如果适用,开发接口协议计划,按照GB/T 34590.8-2017第5章;
g) 支持过程计划,按照GB/T 34590.8-2017;
h) 验证活动计划,按照 GB/T 34590.3-2017、GB/T 34590.4-2017、GB/T 34590.5-2017、
GB/T 34590.6-2017和GB/T 34590.8-2017第9章;安全确认活动计划,按照GB/T 34590.4-
2017第9章;
注:在相关项集成和测试计划(参见GB/T 34590.4-2017)、软件验证计划(参见GB/T 34590.6-2017)中详细说明了验证活动。在确认计划(参见GB/T 34590.4-2017)中详细说明了确认活动。同时参见6.4.3.3。
i) 认可评审的计划、功能安全审核的启动和功能安全评估的启动,按照6.4.7~6.4.9。
注:在安全计划中规定了实施认可措施的人员的独立性级别(参见6.4.7)和资质(参见5.4.3)。
j) 相关失效分析的计划,如果适用,按照GB/T 34590.9-2017第7章;以及安全分析计划,按照
GB/T 34590.9-2017第8章;
k) 如果适用,提供候选项的在用证明,按照GB/T 34590.8-2017第14章;及
l) 如果适用,提供软件工具的可信度,按照GB/T 34590.8-2017第11章。
6.4.3.6 安全活动的计划应包括:
a) 目的;
b) 对其他活动或信息的依赖性;
c) 负责执行活动的资源;
d) 执行活动所需的资源;
e) 起点时间和持续时间;及
f) 相应工作成果的识别。
6.4.3.7 对于至少有一个安全目标为ASILB、C或D的相关项,应满足如下要求:按照6.4.3.1~6.4.3.6
的要求制定的安全计划,应由授权人批准,该授权人应考虑按照6.4.7的要求对安全计划进行认可
评审。
6.4.3.8 按照5.4.2.4的要求,对识别出的安全异常应向安全经理以及其他责任人员汇报。
注:安全异常解决方案导致的变更应纳入变更管理流程(参见GB/T 34590.8-2017第8章)。
6.4.4 安全生命周期进程
6.4.4.1 只有来自相关子阶段的信息足够充分时,才应启动安全生命周期后续子阶段的安全活动。
注:对于相关项安全目标的实现来说,如果缺失的信息不会导致不可接受的风险,则信息可以被认为是充分的。
6.4.4.2 按照GB/T 34590.8-2017第7章、第8章和第10章的要求,每一项安全计划所要求的工作成
果应分别服从配置管理、变更管理以及文档化管理,且纳入管理的时间不迟于“产品开发:系统层面”阶
段的启动时间。
6.4.5 安全活动剪裁
6.4.5.1 可以对特定相关项开发的安全活动进行剪裁,如省略或以不同的方式执行。如果对安全活动
进行剪裁,则:
a) 应在安全计划中定义该剪裁[参见6.4.3.5c)];及
b) 应给出理由说明为什么剪裁对于实现功能安全来说是恰当且充分的。
注1:该理由应考虑相关要求的ASIL等级。
注2:剪裁的理由包含在安全计划中且在安全计划认可评审(参见6.4.7)或功能安全评估(参见6.4.9)过程中进行评审。
注3:该要求适用于特定相关项的安全活动的剪裁。关于组织层面相关项开发的安全生命周期的剪裁,仅5.4.5
适用。
6.4.5.2 如果是因为对现有相关项的修改而按照6.4.5.1对某一安全活动进行剪裁,应满足
GB/T 34590.3-2017第6章的要求。
6.4.5.3 如果存在在用证明而按照6.4.5.1对某一安全活动进行剪裁时,则应满足GB/T 34590.8-
2017第14章的要求。
6.4.5.4 如果由于ASIL分解而按照6.4.5.1的要求不采用某一安全活动,则应满足GB/T 34590.9-
2017第5章的要求。
6.4.5.5 如果是基于考虑所使用软件工具的置信度而按照6.4.5.1对某一安全活动进行剪裁,则应满足
GB/T 34590.8-2017第11章的要求。
6.4.5.6 如果是因为要素独立于相关项开发而按照6.4.5.1的要求对安全活动进行剪裁,则:
a) 独立于相关项的要素的开发应基于一个需求规范,该需求规范来自对预期用途和应用环境的
假设,包括其外部接口;及
b) 应确认独立于相关项而开发的要素的预期用途和应用环境的假设的有效性。
注:本标准作为一个整体不能应用于独立于相关项的要素开发,因为功能安全不是一个要素的属性(然而一个相关项中的某一个要素可以认为是与安全相关的)。功能安全是一个可以用功能安全评估方法来评价的相关项的属性。
示例:微控制器独立于相关项开发。
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.5i)、6.4.8和6.4.9的要求,执行表1所定义的认可
措施。
注1:对表1中定义的且被安全计划所要求的工作成果进行认可评审。
注2:认可评审包括按照本标准对形式、内容、充分性、完整性方面的要求进行正确性检查。
注3:表1包括认可措施,附录D中给出了验证评审的概述。
注4:认可措施的结果报告包括已分析的工作成果或流程文档的名称和版本号(参见GB/T 34590.8-2017的10.4.5)。
注5:如果在认可评审或功能安全评估完成后,还有相关项的变更,则需要重复或补充所有这些工作。
注6:在附录C中给出了每个认可措施的目标。
注7:认可措施,如认可评审和功能安全审核,可以与功能安全评估合并、联合,以支持相关项类似变型的处理。
6.4.7.2 在相关项开发过程中,实施认可措施的人员应能接触开展安全活动的人员和组织机构,并应得
到其支持。
6.4.7.3 实施认可措施的人员应有权限获取相关信息和工具。
6.4.8 功能安全审核
6.4.8.1 当相关项安全目标的最高ASIL等级是ASIL(B)、C或D时,应按照6.4.7、6.4.3.5i)和6.4.8.2
的要求进行相关项的功能安全审核。
6.4.8.2 按照5.4.3的要求,应委派一名或多名人员开展一次或多次功能安全审核。所委派的人员应提
供包含对功能安全所要求的过程实施情况的评估报告。
注2:组织的流程定义可以同时符合多种标准,如GB/T 34590和SPICE的配置管理流程要求。这种流程的协调有助于避免重复工作或流程的不一致。对于协调后的流程,可给出组织专门流程对GB/T 34590中要求和对SPICE要求的交叉引用。
6.4.9 功能安全评估
6.4.9.1 当相关项安全目标的最高ASIL等级为(B)、C或D时,应按照6.4.7和6.4.9.2~6.4.9.8的要
求开展功能安全评估。
6.4.9.2 应按照6.4.3.3和6.4.3.5i)的要求,制定功能安全评估计划。
示例:附录E给出了功能安全评估的计划安排。
6.4.9.3 按照5.4.3的要求,应委派一名或多名人员开展功能安全评估,被委派的人员应提供一份包含
对功能安全实现程度的评判报告。
6.4.9.4 功能安全评估范围应包括:
---安全计划要求的工作成果;
---功能安全要求的流程;及
注1:流程的评估可基于功能安全审核的结果。
---对在相关项开发过程中已实施的且可评估的安全措施进行适宜性和有效性评审。
注2:对于在产品生产子阶段实施的但不能在相关项开发过程中进行评估的安全措施,可与生产过程能力结合在一起进行评估(参见GB/T 34590.7-2017的5.4.2.2)。
6.4.9.5 功能安全评估应考虑:
a) 其他认可措施的计划[参见6.4.3.5i)];
b) 认可评审和功能安全审核的结果;
c) 如果适用,来自先前的功能安全评估的建议(参见6.4.9.7、6.4.9.8和GB/T 34590.8-2017的
8.4.5.2)。
6.4.9.6 按照6.4.9.3的要求制定的功能安全评估报告应包含对相关项的功能安全接受、有条件接受或
拒绝的建议。对于有条件接受的情况:
a) 如果相关项的功能安全被认为是明显的,尽管存在已识别的未解决的问题,应为有条件接
受;及
b) 有条件接受的建议应包含与功能安全评估标准的偏差以及这些偏差可被接受的依据。
6.4.9.7 按照6.4.9.6,如果功能安全评估报告建议对已实现的功能安全是有条件接受,则宜实施在功
能安全评估报告中提供的修正措施。
6.4......
英文网页English: GB/T 34590.2-2017
相关标准: GB/T 34590.11|GB/T 34590.5|GB/T 34590.6|GB/T 34590.4|GB/T 34590.2-2017|GB/T 34590.2|