标准搜索结果: 'GB/T 34590.4-2017'
| 标准编号 | GB/T 34590.4-2017 (GB/T34590.4-2017) | | 中文名称 | 道路车辆 功能安全 第4部分：产品开发：系统层面 | | 英文名称 | Road vehicles -- Functional safety -- Part 4: Product development at the system level | | 行业 | 国家标准 (推荐) | | 中标分类 | T35 | | 国际标准分类 | 43.040 | | 字数估计 | 38,341 | | 发布日期 | 2017-10-14 | | 实施日期 | 2018-05-01 | | 起草单位 | 中国汽车技术研究中心、泛亚汽车技术中心有限公司、博世汽车部件(苏州)有限公司、中国第一汽车股份有限公司、上海海拉电子有限公司、舍弗勒投资(中国)有限公司、北京兴科迪科技有限公司、联合汽车电子有限公司、大陆汽车投资(上海)有限公司、上海汽车集团股份有限公司技术中心、东风汽车公司技术中心 | | 归口单位 | 全国汽车标准化技术委员会(SAC/TC 114) | | 提出机构 | 全国汽车标准化技术委员会(SAC/TC 114) | | 发布机构 | 中华人民共和国国家质量监督检验检疫总局、中国国家标准化管理委员会 | GB/T 34590.4-2017
道路车辆 功能安全 第4部分：产品开发：系统层面
Road vehicles -- Functional safety -- Part 4: Product development at the system level
1 范围
GB/T 34590的本部分规定了车辆在系统层面产品开发的要求,包括:
---启动系统层面产品开发;
---技术安全要求的定义;
---技术安全概念;
---系统设计;
---相关项集成和测试;
---安全确认;
---功能安全评估;及
---生产发布。
本标准适用于安装在量产乘用车上的包含一个或多个电子电气系统的与安全相关的系统。
本标准不适用于特殊用途车辆上特定的电子电气系统,例如,为残疾驾驶者设计的车辆。
本标准不适用于已经完成生产发布的系统及其组件或在本标准发布日期前开发的系统及其组件。
对于在本标准发布前完成生产发布的系统及其组件进行进一步的开发或变更时,仅修改的部分需要按
照本标准开发。
本标准针对由电子电气安全相关系统的故障行为而引起的可能的危害,包括这些系统相互作用而
引起的可能的危害。本标准不针对与触电、火灾、烟雾、热、辐射、毒性、易燃性、反应性、腐蚀性、能量释
放等相关的危害和类似的危害,除非危害是直接由电子电气安全相关系统的故障行为而引起的。
本标准不针对电子电气系统的标称性能,即使这些系统(例如,主动和被动安全系统、制动系统、自
适应巡航系统)有专用的功能性能标准。
2 规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅注日期的版本适用于本文
件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。
GB/T 34590.1-2017 道路车辆 功能安全 第1部分:术语(ISO 26262-1:2011,MOD)
GB/T 34590.2-2017 道路车辆 功能安全 第2部分:功能安全管理(ISO 26262-2:2011,
MOD)
GB/T 34590.3-2017 道路车辆 功能安全 第3部分:概念阶段(ISO 26262-3: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) 按照GB/T 34590.2-2017的要求,已经计划了安全活动的剪裁并表明这些要求不适用;或
b) 不满足要求的理由存在且是可接受的,并且按照GB/T 34590.2-2017对该理由进行了评估。
标有“注”或“示例”的信息仅用于辅助理解或阐明相关要求,不应作为要求本身且不具备完备性。
将安全活动的结果作为工作成果。应具备上一阶段工作成果作为“前提条件”的信息。如果章条的
某些要求是依照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.8-2017中所描述的必要的支持过程。
系统层面安全活动的计划包含在安全计划中。
5.2 总则
图2给出了在系统开发过程中的必要活动。在启动产品开发和定义技术安全要求后,进行系统设
计。在系统设计过程中建立系统架构,将技术安全要求分配给硬件和软件,并且,如果适用,也可分配给
其他技术。同时,细化技术安全要求,并添加来自系统架构的要求,包括软硬件接口的要求。根据架构
的复杂性,可以逐步得出子系统的要求。完成相关开发后,集成硬件和软件要素并测试以形成一个相关
项,然后,将该相关项集成在整车上。一旦在整车层面完成了系统集成,进行安全确认以提供与安全目
标相关的功能安全证据。
GB/T 34590.5-2017和GB/T 34590.6-2017描述了软硬件的开发要求。本部分适用于系统和
子系统的开发。图3是具有多层集成的系统示例,阐明了如何应用本部分及GB/T 34590.5-2017和
GB/T 34590.6-2017。
注:附录A中表A.1提供了对系统层面产品开发特定子阶段的目的、前提条件和工作成果的概览。
注:在图中,GB/T 34590的各部分具体条款用以下方式来表示:“m-n”,其中“m”代表“部分”的编号和“n”表示“章”的编号,例如,“4-5”表示GB/T 34590第4部分的第5章。
注:在图中,GB/T 34590的各部分具体条款用以下方式来表明:“m-n”,其中“m”代表“部分”的编号和“n”表示“章”的编号,例如,“4-5”表示GB/T 34590的第4部分的第5章。
5.3 本章的输入
5.3.1 前提条件
应具备下列信息:
---项目计划(细化的),按照GB/T 34590.2-2017的6.5.2;
---安全计划,按照GB/T 34590.3-2017的6.5.2;
---功能安全评估计划,按照GB/T 34590.2-2017的6.5.4;及
---功能安全概念,按照GB/T 34590.3-2017的8.5.1。
5.3.2 支持信息
可考虑下列信息:
---初步架构设想(来自外部);及
---相关项定义(参见GB/T 34590.3-2017的5.5)。
5.4 要求和建议
5.4.1 应制定系统层面产品开发的安全活动计划,包括确定设计和集成过程中适当的方法和措施。
注:按照6.4.6(验证和确认)和7.4.8(系统设计的验证)的要求,设计过程中对验证活动所做计划的结果是安全计划的组成部分,而按照8.4.2(软硬件集成和测试)、8.4.3(系统集成和测试)和8.4.4(整车集成和测试)制定的相关项集成和测试计划在一个单独相关项集成和测试计划(按照8.4.1.3的要求)中进行描述。
5.4.2 应制定确认活动的计划。
5.4.3 应制定系统层面产品开发的功能安全评估活动计划(参见GB/T 34590.2-2017)。
注:GB/T 34590.2-2017附录E提供了一个功能安全评估安排的示例。
5.4.4 应按照GB/T 34590.2-2017的要求并基于图2给出的参考阶段模型,进行系统层面产品开发
的生命周期剪裁。
注:项目计划可用于提供系统层面产品开发各子阶段和软硬件开发阶段的关系。这包括每个层面的集成步骤。
5.5 工作成果
5.5.1 项目计划(细化的),由5.4.4的要求得出。
5.5.2 安全计划(细化的),由5.4.1~5.4.4的要求得出。
5.5.3 相关项集成和测试计划,由5.4.1的要求得出。
5.5.4 确认计划,由5.4.2的要求得出。
5.5.5 功能安全评估计划(细化的),由5.4.3的要求得出。
6 技术安全要求的定义
6.1 目的
该子阶段的第一个目的是制定技术安全要求。技术安全需求规范同时考虑功能概念和初步的架构
设想(参见GB/T 34590.3-2017),从而进一步细化功能安全概念。
第二个目的是通过分析来验证技术安全要求是否符合功能安全要求。
6.2 总则
在整个开发生命周期中,技术安全要求是实现功能安全概念必要的技术要求,目的是将相关项层面
的功能安全要求细化到系统层面的技术安全要求。
注:避免潜伏故障的要求,可在第一轮系统设计子阶段之后引出。
6.3 本章的输入
6.3.1 前提条件
应具备下列信息:
---功能安全概念,按照GB/T 34590.3-2017的8.5.1;及
---确认计划,按照5.5.4。
6.3.2 支持信息
可考虑下列信息:
---安全目标(参见GB/T 34590.3-2017的7.5.2);
---功能概念(来自外部,参见GB/T 34590.3-2017的5.4.1);及
---初步架构设想 (来自外部,参见GB/T 34590.3-2017的8.3.2)。
6.4 要求和建议
6.4.1 技术安全要求的定义
6.4.1.1 技术安全要求应根据功能安全概念、相关项的初步架构设想和如下系统特性来定义:
a) 外部接口,如通讯和用户接口,如果适用;
b) 限制条件,例如环境条件或者功能限制;
c) 系统配置要求。
注:具有为选择性用途而重新配置系统的能力是重复使用已有系统的一种策略。
示例:标定数据(参见 GB/T 34590.6-2017附录C)常用于定制不同车辆的发动机电子控制单元。
6.4.1.2 应确保GB/T 34590.3-2017的8.3.2中的初步架构设想和本子阶段中的初步架构设想的一
致性。
6.4.1.3 除按照6.4.1定义技术安全要求的那些功能外,如果其他功能或要求也由系统或其要素实现,
则应定义这些功能或要求,或者标明其参考规范。
示例:其他要求来源于欧洲经济委员会(ECE)法规,美国联邦机动车安全标准(FMVSS)或者企业平台策略。
6.4.1.4 技术安全要求应定义系统间或相关项要素间,及相关项和其他系统间的安全相关的关联性。
6.4.2 安全机制
6.4.2.1 技术安全要求应定义系统或要素对于影响实现安全目标的激励的响应。这包括失效和相关的
激励组合,并与每个相关运行模式及规定的系统状态进行组合。
示例:如果自适应巡航(ACC)的电控单元从制动系统电控单元收到车辆稳定性控制功能不可用的通知,它将会关闭ACC功能。
6.4.2.2 技术安全要求应定义必要的安全机制(参见GB/T 34590.8-2017的第6章)包括:
a) 与系统自身故障相关的探测、指示和控制措施;
注1:包括系统或者要素的自身监控,用于探测随机硬件故障,以及,如果适用,探测系统性失效。
注2:包括对通讯通道(例如:数据接口、通讯总线、无线射频链接)失效模式的探测和控制的措施。
b) 涉及探测、指示和控制与本系统有相互影响的外部设备中所发生故障的措施;
示例:外部设备包括其他的电控单元、电源或者通讯设备。
c) 使系统实现或者维持在安全状态下的措施;
注3:包括在安全机制冲突时的优先和仲裁逻辑。
d) 细化和执行报警和降级概念的措施;以及
e) 防止故障潜伏的措施[参见6.4.4(潜伏故障的避免)]。
注3:这些如同a)~d)的措施,通常与上电过程(运行前检查),运行中,下电过程(运行后检查)及作为维护的一部分实施的测试相关。
6.4.2.3 对于每个使相关项实现安全状态或维持安全状态的安全机制,应定义下列内容:
a) 向安全状态的过渡;
注1:包括执行器的控制要求。
b) 故障容错时间间隔;
注2:整车测试和试验能够用于确定故障容错时间间隔。
c) 如果不能立即进入安全状态时的紧急运行时间间隔;及
注3:整车测试和试验能够用于确定紧急运行时间间隔。
示例1:关闭系统可以是一种紧急运行。
d) 维持安全状态的措施。
示例2:一个依赖于电源的线控制动应用的安全机制,可以包括定义备用电源或储能设备(容量、启动和运行时间等)。
6.4.3 ASIL分解
如果在定义技术安全要求时进行ASIL分解,应根据GB/T 34590.9-2017第5章进行(与ASIL
剪裁相关的要求分解)。
6.4.4 潜伏故障的避免
6.4.4.1 按照4.3,此要求适用于ASIL(A)、(B)、C和D等级:如果适用,应定义防止故障潜伏的安全
机制。
注1:就随机故障而言,只有多点故障可能包含潜伏故障。
示例:车载测试是用于检测潜伏故障的安全机制,它验证在不同运行模式(例如上电、下电、运行或一个额外的测试模式)下组件的状态。阀、继电器或灯在上电时做的功能测试就是这类车载测试的例子。
注2:识别是否需要防止故障潜伏的安全措施的评估标准来源于好的工程实践。GB/T 34590.5-2017第8章给出的潜伏故障度量,提供了评估的标准。
6.4.4.2 按照4.3,此要求适用于ASIL(A)、(B)、C和D等级:为了避免多点失效,应为每个按照6.4.4
(潜伏故障的避免)执行的安全机制定义多点失效探测时间间隔。
6.4.4.3 按照4.3,此要求适用于ASIL(A)、(B)、C和D等级:为确定多点故障探测时间间隔,宜考虑下
列参数:
a) 硬件组件的可靠性,并考虑其在架构中的角色;
b) 相关危害事件的暴露概率;
c) 定义的量化目标值,表征由于硬件随机失效而违背各安全目标的最大可能性(参见要求7.4.4.3);及
d) 相关安全目标分配的ASIL等级。
注:下列措施的使用依赖于时间限制:
---系统或要素在运行过程中的周期性测试;
---要素在上下电时的车载测试;及
---系统或要素在维护时的测试。
6.4.4.4 按照4.3,此要求适用于ASIL(A)、(B)、C和D等级:用于防止双点故障变成潜伏故障的安全
机制的开发应符合:
a) ASILB(对于分配为ASILD的技术安全要求);
b) ASILA(对于分配为ASILB和ASILC的技术安全要求);及
c) 工程判断(对于分配为ASILA的技术安全要求)。
6.4.5 生产、运行、维护和报废
应定义在GB/T 34590.7-2017中所表述的生产、运行、维护、维修和报废期间的关于相关项或其
要素的功能安全的技术安全要求。
注:有两个方面确保了生产、运行、维护、维修和报废期间的安全。第一个方面涉及到在6.4.5和7.4.7的要求(对生产、运行、服务和报废的要求)中所给出的开发阶段期间执行的那些活动,而第二个方面涉及到在GB/T 34590.7-2017中描述的生产和运行阶段期间执行的那些活动。
6.4.6 验证和确认
6.4.6.1 技术安全要求应按照GB/T 34590.8-2017第9章来验证,以提供证据证明它们:
a) 与功能安全概念的符合性和一致性;及
b) 与初步架构设计设想的符合性。
6.4.6.2 应基于技术安全要求细化相关项的安全确认标准。
注:系统确认计划和系统确认规范是与技术安全要求并行开发的(参见第9章)。
6.5 工作成果
6.5.1 技术安全需求规范,由6.4.1~6.4.5的要求得出。
6.5.2 系统验证报告,由6.4.6的要求得出。
6.5.3 确认计划(细化的),由6.4.6.2的要求得出。
7 系统设计
7.1 目的
该子阶段的第一个目的是进行系统设计和技术安全概念开发,以满足相关项的功能要求和技术安
全需求规范。
该子阶段的第二个目的是验证系统设计和技术安全概念满足技术安全需求规范。
7.2 总则
系统设计和技术安全概念的开发是基于功能安全概念的技术安全需求规范。如果系统由子系统构
成,这个子阶段可以迭代使用。
进行系统架构的开发以实现功能安全要求、技术安全要求和非安全相关要求。因此,在该子阶段,
用同一个开发流程来处理安全相关和非安全相关的要求。
7.3 本章的输入
7.3.1 前提条件
应具备下列信息:
---相关项集成和测试计划,按照5.5.3;及
---技术安全需求规范,按照6.5.1。
7.3.2 支持信息
可考虑下列信息:
---初步架构设想(来自外部,参见GB/T 34590.3-2017的8.3.2);
---功能概念(来自外部);及
---功能安全概念(参见GB/T 34590.3-2017的8.5.1)。
7.4 要求和建议
7.4.1 系统设计规范和技术安全概念
7.4.1.1 系统设计应基于功能概念、初步架构设想和技术安全要求。应保证在GB/T 34590.3-2017
的8.3.2中的初步架构设想和这个子阶段中的初步架构设想的一致性。
7.4.1.2 技术安全要求应分配给系统设计要素。
7.4.1.3 系统设计应实现技术安全要求。
7.4.1.4 与实现技术安全要求相关,在系统设计中应考虑:
a) 验证系统设计的能力;
b) 与实现功能安全相关的预期的软硬件设计的技术能力;及
c) 系统集成中执行测试的能力。
7.4.2 系统架构约束条件
7.4.2.1 系统和子系统架构应满足它们各自ASIL等级的技术安全要求。
7.4.2.2 每个要素应继承来自它所执行的技术安全要求的最高ASIL等级。
7.4.2.3 如果一个要素由指定为不同ASIL等级的子要素组成,或由非安全相关子要素和安全相关子
要素组成,则它们中的每一个应按照最高的 ASIL等级来处理,除非它们满足按照GB/T 34590.9-
2017第6章所定义的共存标准。
7.4.2.4 应定义安全相关要素的内部和外部接口,以避免其他要素对安全相关要素有不利于安全的
影响。
7.4.2.5 如果在系统设计期间对安全要求应用了ASIL等级分解,应按照GB/T 34590.9-2017第5章
进行。
7.4.3 避免系统性失效的措施
7.4.3.1 对系统设计进行安全分析以识别系统性失效的原因和系统性故障的影响,应按照表1和
GB/T 34590.9-2017第8章进行。
7.4.3.2 应消除已识别出的引起系统性失效的内部原因,或减轻它们的影响。
7.4.3.3 应消除已识别出的引起系统性失效的外部原因,或减轻它们的影响。
7.4.3.4 为减少系统性失效,宜应用值得信赖的汽车系统设计原则。这些原则可能包括:
a) 值得信赖的技术安全概念的再利用;
b) 值得信赖的要素设计的再利用,包括硬件和软件组件;
c) 值得信赖的探测和控制失效的机制的再利用;
d) 值得信赖的或标准化接口的再利用。
7.4.3.5 为了确保值得信赖的设计原则或要素在新相关项中的适用性,应分析其应用结果,以及应在再
利用之前检查其基本设想。
注:影响分析包括确定的诊断、环境限制、时序限制的能力和可行性,确定资源的兼容性,以及系统设计的鲁棒性。
7.4.3.6 本要求适用于ASILD:对不再利用值得信赖的设计原则的决定,宜阐明理由。
7.4.3.7 按照4.3,本要求适用于ASIL(A)、(B)、C和D等级:为了避免高复杂性导致的失效,架构设计
应通过使用表2中的原则来展示所有下述属性:
a) 模块性;
b) 适当的粒度水平;及
c) 简单。
7.4.4 运行过程中随机硬件失效的控制措施
7.4.4.1 应按照7.4.1(系统设计规范和技术安全概念)中的系统设计,定义探测、控制或减轻随机硬件
失效的措施。
示例1:这些措施可以是硬件的诊断特性和通过软件对其的使用来探测随机硬件失效。
示例2:在随机硬件失效发生时,直接转到安全状态的硬件设计,甚至不需要探测即可控制失效。
7.4.4.2 按照4.3,本要求适用于ASIL(B)、C和D等级:应为相关项层面的最终评估(参见9.4.3.3)定
义单点故障和潜伏故障度量(参见GB/T 34590.5-2017第8章)的目标值。
7.4.4.3 按照4.3,本要求适用于ASIL(B)、C和D等级:应选择可替代流程中的一个,用于评估随机硬
件失效导致的对安全目标的违背 (参见GB/T 34590.5-2017第9章),并应定义目标值以用于相关项
层面的最终评估(参见9.4.3.3)。
7.4.4.4 按照4.3,本要求适用于 ASIL(B)、C和D等级:适当的失效率和诊断覆盖率的目标值宜在要
素层面进行定义,以符合:
a) GB/T 34590.5-2017第8章中度量的目标值;及
b) GB/T 34590.5-2017第9章中的流程。
7.4.4.5 按照4.3,本要求适用于ASIL(B)、C和D等级:对于分布式开发(参见GB/T 34590.8-2017
第5章),推导出的目标值应通报给每个相关团队。
注:GB/T 34590.5-2017第8章和第9章中描述的构架限制,不直接适用于商业现成产品的元器件和组件。这是因为供应商通常无法预测终端相关项中如何使用他们的产品以及潜在的安全影响。在这种情况下,元器件供应商会提供基本的数据,例如失效率、失效模式、每种失效模式的失效率分布、内置的诊断等,以便允许在整体硬件架构层面上预估架构约束。
7.4.5 分配到硬件和软件
7.4.5.1 技术安全要求应直接或通过进一步的细化后,分别或同时分配到硬件和软件。
7.4.5.2 如果技术安全要求分配到具备可编程功能的定制硬件要素(比如专用集成芯片(ASICs)、可编
程门阵列(FPGA)或是其他形式的数字化硬件,宜结合GB/T 34590.5-2017和GB/T 34590.6-2017
的要求来定义和实施适当的开发流程。
注:如果满足GB/T 34590.8-2017第13章的应用准则,可按照该章的认证措施提供上述硬件要素中的某些要素满足分配的安全要求的证据。
7.4.5.3 系统设计应遵从分配和分区决策。
注:为了实现独立性和避免失效传播,系统设计可采用功能分区和组件分区。
7.4.6 软硬件接口规范(HSI)
7.4.6.1 HSI规范应定义硬件和软件的交互,并保持与技术安全概念一致。HSI规范应包括组件中由
软件控制的硬件装置以及支持软件运行的硬件资源。
示例:HSI中详细描述的方面和特性参见附录B。
7.4.6.2 HSI规范应包含下列特性:
a) 硬件装置的相关运行模式和相关配置参数;
示例1:硬件装置的运行模式,例如:默认模式、初始化模式、测试模式或者高级模式。
示例2:配置参数,例如:增益控制、带通频率或时钟分频。
b) 确保要素间独立性和支持软件分区的硬件特征;
c) 硬件资源的共用和专用;
示例3:内存映射、寄存器分配、计时器、中断、I/O端口。
d) 硬件装置的访问机制;及
示例4:串、并、从、主/从。
e) 为技术安全概念涉及到的每一个服务定义的时序限制。
7.4.6.3 硬件的相关诊断能力和软件对其的使用应在HSI规范中定义:
a) 应定义硬件的诊断特性;及
示例:过流、短路或过温的探测。
b) 应定义需要在软件中实现的对硬件的诊断特性。
7.4.6.4 HSI应在系统设计过程中得到定义,并在硬件开发(见GB/T 34590.5-2017第7章)和软件开
发(见GB/T 34590.6-2017第7章)过程中进行细化。
7.4.7 生产、运行、服务和报废的要求
7.4.7.1 在考虑了安全分析的结果和所实施的安全机制的情况下,应定义需具备的诊断特性,以提供运
行中对相关项或其要素进行现场监控所需的数据。
7.4.7.2 为了保持功能安全,应定义诊断特性以便需要维护时车间人员能够识别故障。
7.4.7.3 应定义在系统设计中识别出的对生产、运行、服务和报废的要求(见GB/T 34590.7-2017),
包括:
a) 装配指导的要求;
b) 安全相关的特殊特性;
c) 专用于确保正确识别系统或要素的要求;
示例1:要素标识。
d) 生产的验证方法和措施;
e) 包含诊断数据及服务记录的服务要求;及
f) 报废要求。
示例2:报废指南。
7.4.8 系统设计的验证
7.4.8.1 应使用表3列出的方法验证系统设计对于技术安全概念的符合性和完备性。
7.4.8.2 应按照GB/T 34590.3-2017危害分析和风险评估及GB/T 34590.8-2017第8章变更管理
流程,提出并评估系统设计中新识别出且未包含在安全目标中的危害。
注:新识别出且未在安全目标中体现的危害,通常是非功能性的危害。非功能性的危害不在GB/T 34590考虑的范围内,但在危害分析和风险评估中可以标注为“因不在GB/T 34590规定范围内,不为其指定 ASIL等级”。
7.5 工作成果
7.5.1 技术安全概念,由7.4.1和7.4.5的要求得出。
7.5.2 系统设计规范,由7.4.1~7.4.5的要求得出。
7.5.3 软硬件接口(HSI)规范,由7.4.6的要求得出。
7.5.4 生产、运行、服务和报废要求的定义,由7.4.7的要求得出。
7.5.5 系统验证报告(细化的),由7.4.8的要求得出。
7.5.6 安全分析报告,由7.4.3的要求得出。
8 相关项集成和测试
8.1 目的
相关项集成和测试阶段包含三个阶段和两个主要目标:第一个阶段是相关项所包含的每一个要素
的软硬件集成;第二个阶段是构成一个完整系统的一个相关项的所有要素的集成;第三个阶段是相关项
与车辆上其他系统的集成以及与整车的集成。
相关项集成过程的第一个目标是测试每一条安全要求是否满足规范以及ASIL级别的要求。
相关项集成过程的第二个目标是验证涵盖安全要求的“系统设计”(参见第7章)在整个相关项上是
否得到正确实施。
8.2 总则
相关项要素的集成按照系统化的方法进行,从软硬件集成开始,经过系统集成,最后完成整车集成。
在每个集成阶段要进行特定的集成测试,以证明所集成的要素之间交互的正确性。
按照GB/T 34590.5-2017和GB/T 34590.6-2017充分完成硬件和软件开发后,可启动按照第8
章(相关项集成和测试)的系统集成。
8.3 本章的输入
8.3.1 前提条件
应具备下列信息:
---安全目标,按照GB/T 34590.3-2017的7.5.2;
---功能安全概念,按照GB/T 34590.3-2017的8.5.1;
---相关项集成和测试计划,按照5.5.3;
---技术安全概念,按照7.5.1;
---系统设计规范,按照7.5.2;及
---软硬件接口(HSI)规范,按照7.5.3。
8.3.2 支持信息
可考虑下列信息:
---整车架构(来自外部);
---车辆其他系统的技术安全概念(来自外部);及
---安全分析报告(参见7.5.6)。
8.4 要求和建议
8.4.1 集成和测试的计划与定义
8.4.1.1 为证明系统设计符合功能和技术安全要求,应按照GB/T 34590.8-2017第9章执行集成测试
活动。
8.4.1.2 应基于系统设计规范、功能安全概念、技术安全概念、相关项集成和测试计划,定义集成和测试策略,提供测试目标被充分覆盖的证据。该策略应覆盖电子电气要素以及在安全概念中考虑的其他技术要素。
注:通常集成层面包括软硬件、系统及整车层面。
8.4.1.3 为使系统集成子阶段能够进行,应执行:
a) 细化集成与测试计划以用于软硬件集成与测试;
b) 细化相关项集成与测试计划以包含系统及整车层面的集成测试规范,应确保来自于软硬件验
证的未解决问题得到处理;
c) 系统及整车层面的相关项集成与测试计划应考虑车辆子系统(与该相关项相关的内部子系统
和外部子系统)与环境之间的接口。
注1:当制定整车层面相关项集成与测试计划时,可考虑车辆在典型和极端车辆状况和环境条件下的正确行为,但应组成一个充分的子集(参见表4)。
注2:在软硬件集成层面和相关项层面上进行的集成与测试计划,要考虑软硬件间的接口及其交互。
8.4.1.4 如果系统使用了配置或标定数据,在系统或整车层面的验证应为在应用层面的每个配置或用
于量产的每个配置提供满足安全要求的证据。
注:如果在系统或整车层面对每个配置的完整验证是不可行的,则可选择一个合理的子集。
8.4.1.5 测试设备应受质量监控体系的监管。
8.4.1.6 在整个集成子阶段,对每个功能和技术安全要求应至少进行一次验证(如果可以通过测试进行
验证)。
注1:一个常规的做法是在更高一级的集成层面上对已定义的安全要求进行验证。
注2:对集成测试期间识别出的安全异常按照GB/T 34590.2-2017的5.4.2的要求进行报告。
8.4.1.7 为了恰当的定义集成测试的测试案例,应考虑集成的层面,使用表4中所列的恰当的方法组合
导出测试用例。
8.4.2 软硬件集成和测试
8.4.2.1 软硬件集成
8.4.2.1.1 应对按照GB/T 34590.5-2017开发的硬件和按照GB/T 34590.6-2017开发的软件进行集
成,作为表4~表8中测试活动的对象。
8.4.2.1.2 按照4.3,该要求适用于ASILC和D等级:应以适当的覆盖率测试软硬件接口(HSI)要求,
同时考虑ASIL等级或应给出没有关于HSI遗留问题的理由。
注:首选使用用于生产的硬件和软件。如必要,特定测试技术可以使用修改的硬件或者软件。
8.4.2.2 软硬件测试中的测试目标和测试方法
8.4.2.2.1 为了发现系统设计中的系统性故障,在软硬件集成过程中,对于按照8.4.2.2.2~8.4.2.2.6得
出的测试目标,应使用对应表中给出的可行的测试方法来实现。
注:基于系统已实施的功能、功能复杂性或分布特性,如有足够的理由,将测试方法用于其他集成的子阶段是合理的。
8.4.2.2.2 技术安全要求在软硬件层面的正确执行,应使用表5中给出的可行的测试方法进行论证。
8.4.2.2.3 按照4.3,该要求适用于ASIL(A)、B、C和D等级:安全机制在软硬件层的正确功能性能、准
确性和时序,应使用表6中给出的可行的测试方法进行论证。
8.4.2.2.4 按照4.3,该要求适用于ASIL(A)、B、C和D等级:外部和内部接口在软硬件层执行的一致
性和正确性,应使用表7中给出的可行的测试方法进行论证。
8.4.2.2.5 按照4.3,该要求适用于ASIL(A)、(B)、C和D等级:对于硬件失效探测机制在软硬件层面
上与故障模型有关的诊断覆盖率的有效性,应使用表8中给出的可行的测试方法进行论证。
注:参考的故障模型,见GB/T 34590.5-2017附录D。
8.4.2.2.6 按照4.3,该要求适用于ASIL(A)、(B)、(C)和D等级:要素在软硬件层的鲁棒性水平,应使
用表9中给出的可行的测试方法进行论证。
8.4.3 系统集成和测试
8.4.3.1 系统集成
组成系统的各个要素应按照系统设计进行集成,并按照本部分规定的系统集成测试、GB/T 34590.5-
2017和GB/T 34590.6-2017中规定的系统集成测试进行测试。
注:测试目的是提供证据证明各个系统要素正确交互、符合技术和功能安全要求,并为没有可能导致违背安全目标的非预期行为提供足够的置信度水平。
8.4.3.2 系统测试中的测试目标和测试方法
8.4.3.2.1 为了发现系统集成过程中的系统性故障,对于按照8.4.3.2.2~8.4.3.2.6得出的测试目标,应
使用对应表中给出的适当的测试方法来实现。
注:基于系统已实施的功能、功能复杂性或分布特性,如有足够的理由,将测试方法用于其他集成的子阶段是合理的。
8.4.3.2.2 功能和技术要求在系统层面的正确执行,应使用表10中给出的可行的测试方法进行论证。
8.4.3.2.3 按照4.3,该要求适用于ASIL(A)、B、C和D等级:安全机制在系统层的正确功能性能行为、
准确性和时序,应使用表11中给出的可行的测试方法进行论证。
8.4.3.2.4 外部和内部接口在系统层面执行的一致性和正确性,应使用表12中给出的可行的测试方法
进行论证。
8.4.3.2.5 按照4.3,该要求适用于ASIL(A)、(B)、C和D等级:安全机制在系统层面的失效覆盖率的
有效性,应使用表13中给出的可行的测试方法进行论证。
8.4.3.2.6 系统层面的鲁棒性水平应使用表14中给出的可行的测试方法进行论证。
8.4.4 整车集成和测试
8.4.4.1 整车集成
8.4.4.1.1 应将相关项集成到整车上,并完成整车集成测试。
8.4.4.1.2 应对相关项与车内通讯网络以及车内供电网络的接口规范进行验证。
8.4.4.2 整车测试期间的测试目标和测试方法
8.4.4.2.1 为了探测整车集成期间的系统性故障,由8.4.4.2.2~8.4.4.2.6得出的测试目标,应使用对应
表格中所给出的适当的测试方法来实现。
注:基于系统已实施的功能、功能复杂性或分布特性,如有足够的理由,将测试方法用于其他集成的子阶段是合理的。
8.4.4.2.2 功能安全要求在整车层面的正确的执行,应使用表15中给出的可行的测试方法进行论证。
8.4.4.2.3 按照4.3,该要求适用于ASIL(A)、(B)、C和D等级:安全机制在整车层面的正确功能性能、
准确性和时序,应使用表16中给出的可行的测试方法进行论证。
8.4.4.2.4 按照4.3,该要求适用于ASIL(A)、(B)、C和D等级:整车层面外部接口实现的一致性和正
确性,应使用表17中给出的可行的测试方法进行论证。
8.4.4.2.5 按照4.3,该要求适用于ASIL(A)、(B)、C和D等级:安全机制在整车层面的失效覆盖率的
有效性,应使用表18中给出的可行的测试方法进行论证。
8.4.4.2.6 按照4.3,该要求适用于ASIL(A)、(B)、C和D等级:整车层面的鲁棒性水平,应使用表19
中给出的可行的测试方法进行论证。
8.5 工作成果
8.5.1 相关项集成和测试计划(细化的),由8.4.1的要求得出。
8.5.2 集成测试规范,由8.4.1的要求得出。
8.5.3 集成测试报告,由8.4.2、8.4.3和8.4.4的要求得出。
9 安全确认
9.1 目的
第一个目的是提供符合安全目标的证据及功能安全概念适合相关项的功能安全的证据。
第二个目的是提供安全目标在整车层面上是正确的、完整的并得到完全实现的证据。
9.2 总则
前述验证活动(如:设计验证、安全分析、硬件集成和测试、软件集成和测试、相关项的集成和测试)
的目的是提供每项特定活动的结果符合规定要求的证据。
对典型车辆上所集成的相关项的确认,目的是为预期使用的恰当性提供证据并确认安全措施对一
类或一组车辆的充分性。安全确认基于检查和测试,确保安全目标足够且得到实现。
9.3 本章的输入
9.3.1 前提条件
应具备下列信息:
---危害分析和风险评估,按照GB/T 34590.3-2017的7.5.1;
---安全目标,按照GB/T 34590.3-2017的7.5.2;及
---功能安全概念,按照GB/T 34590.3-2017的8.5.1。
9.3.2 支持信息
可考虑下列信息:
---项目计划(细化的)(参见5.5.1);
---技术安全概念(参见7.5.1);
---功能概念(来自外部);
---相关项的集成和测试计划(细化的)(参见8.5.1);及
---安全分析报告(参见7.5.6)。
9.4 要求和建议
9.4.1 确认的环境
应对典型车辆上所集成的相关项的安全目标进行确认。
注:如适用,集成的相关项包括:系统、软件、硬件、其他技术要素和外部措施。
9.4.2 确认的计划
应细化确认计划,包括:
a) 待确认的相关项配置,包括其标定数据,按照GB/T 34590.6-2017附录C;
注:如果对于每个相关项配置的完整确认是不可行的,则可选择合理的子集。
b) 确认流程、测试案例、驾驶操作和接受准则的定义;
c) 设备和要求的环境条件。
9.4.3 确认的执行
9.4.3.1 如果测试用于确认,则可应用与验证测试(参见GB/T 34590.8-2017的9.4.2和9.4.3)相同的
要求。
9.4.3.2 应在整车层面确认相关项的安全目标,通过评估:
a) 可控性;
注:使用运行场景确认可控性,包括预期用途和可预见的误用。
b) 用于控制随机失效和系统性失效的安全措施的有效性;
c) 外部措施的有效性;及
d) 其他技术要素的有效性。
9.4.3.3 此要求适用于ASIL(B)、C和D等级的安全目标:应在相关项层面实施随机硬件失效度量的
确认,为了:
a) 基于7.4.4.3定义的目标值,对依照GB/T 34590.5-2017第9章确定的因随机硬件失效而导
致的安全目标违背进行评估;及
b) 基于7.4.4.2定义的目标值,依照GB/T 34590.5-2017第8章的评估准则对硬件架构度量进
行评估。
注:在GB/T 34590.5-2017的9.4.2和9.4.3中定义了相关项要素的定量评估。假如相关项中涉及其他技术,则定性评估整个相关项。
9.4.3.4 应基于安全目标、功能安全要求和预期用途,按计划执行整车层面的确认,使用:
a) 包括详细的通过/未通过准则的每个安全目标的确认流程和测试案例;
b) 应用范围。可包括例如配置、环境条件、驾驶场景和操作用例等。
注:可创建操作用例,以助于将安全确认集中在整车层面上。
9.4.3.5 应使用以下方法的适当组合:
a) 已定义了测试流程、测试案例和通过/未通过准则的可重复性测试;
示例1:功能和安全要求的正向测试、黑盒测试、仿真、边界条件下的测试、故障注入、耐久测试、压力测试、高加速寿命测试、外部影响模拟。
b) 分析;
示例2:FMEA、FTA、ETA、仿真。
c) 长期测试,例如车辆驾驶日程安排和受控测试车队;
d) 实际使用条件下的用户测试、抽测或盲测、专家小组;及
e) 评审。
9.4.4 评估
应对确认结果进行评估。
9.5 工作成果
9.5.1 确认计划(细化的),由9.4.2的要求得出。
9.5.2 确认报告,由9.4.3和9.4.4的要求得出。
10 功能安全评估
10.1 目的
本章中所列要求的目的是评估相关项所实现的功能安全。
10.2 总则
由负责功能安全的组织(如:整车厂或供应商,如果后者负责功能安全)启动功能安全评估。
10.3 本章的输入
10.3.1 前提条件
应具备下列信息:
---安全档案,按照GB/T 34590.2-2017的6.5.3;
---安全计划(细化的),按照5.5.2、GB/T 34590.5-2017的5.5.2和 GB/T 34590.6-2017的
5.5.2;
---认可措施报告,按照GB/T 34590.2-2017的6.5.5;
---审核报告(如有),按照GB/T 34590.2-2017的6.5.4;及
---功能安全评估计划(细化的),按照5.5.5。
10.3.2 支持信息
无。
10.4 要求和建议
10.4.1 该要求适用于安全目标ASIL(B)、C、和D等级:对于GB/T 34590.2-2017图2中的安全生命
周期各步骤,应识别功能安全评估的具体议题。
10.4.2 该要求适用于安全目标ASIL(B)、C、和D等级:应根据GB/T 34590.2-2017的6.4.9(功能安
全评估)开展功能安全评估。
10.5 工作成果
功能安全评估报告,由10.4.1和10.4.2的要求得出。
11 生产发布
11.1 目的
本章的目的是定义相关项开发完成后生产发布的准则。生产发布确认了相关项在整车层面满足功
能安全要求。
11.2 总则
11.2.1 生产发布确认相关项已做好量产和运行的准备。
11.2.2 满足量产前提条件的证据由以下提供:
---完成硬件、软件、系统、相关项及整车层面开发过程中的验证和确认;
---成功通过整体功能安全评估。
11.2.3 发布的文件是零部件、系统或整车生产的基础,并由负责发布的人员签字。
11.3 本章的输入
11.3.1 前提条件
应具备下列信息:
---功能安全评估报告,按照10.5.1;及
---安全档案,按照GB/T 34590.2-2017的6.5.3。
11.3.2 支持信息
无。
11.4 要求和建议
11.4.1 生产发布
如果适用(视ASIL等级而定),只有具备11.3.1所列的工作成果才能批准相关项的生产发布,为功
能安全提供信心。
11.4.2 生产发布文件
11.4.2.1 功能安全生产发布文件应包含下面的信息:
a) 负责发布人员的名字和签名;
b) 所发布相关项的版本;
c) 所发布相关项的配置;
d) 参考的相关文件信息。
注:功能安全文件可以是相关项生产发布文件的一部分或是一个独立的文件。
11.4.2.2 生产发布时,应具备软件和硬件的基线,并应依据GB/T 34590.8-2017第10章进行文档
记录。
11.4.2.3 应根据 GB/T 34590.2-2017的5.4.2和 GB/T 345......
|