[PDF] GB/T 34590.10-2017 - 自动发货. 英文版
| 标准号码 | 美元 | 购买PDF | 工期 | 标准名称(英文版) |
| GB/T 34590.10-2017 | 495 | GB/T 34590.10-2017 | 9秒内发货PDF | 道路车辆 功能安全 第10部分：指南 |
| 基本信息 | |
|---|---|
| 标准编号 | GB/T 34590.10-2017 (GB/T34590.10-2017) |
| 中文名称 | 道路车辆 功能安全 第10部分：指南 |
| 英文名称 | Road vehicles -- Functional safety -- Part 10: Guideline |
| 行业 | 国家标准 (推荐) |
| 中标分类 | T35 |
| 国际标准分类 | 43.040 |
| 字数估计 | 82,891 |
| 发布日期 | 2017-10-14 |
| 实施日期 | 2018-05-01 |
| 发布机构 | 中华人民共和国国家质量监督检验检疫总局、中国国家标准化管理委员会 |
GB/T 34590.10-2017
道路车辆 功能安全 第10部分：指南
Road vehicles -- Functional safety -- Part 10: Guideline
1 范围
GB/T 34590的本部分提供了GB/T 34590的概览,也给出了额外的解释,目的是增强对本标准其
他部分的理解。本部分只具有资料性特性,描述了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.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.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 GB/T 34590中的关键概念
4.1 针对汽车系统的功能安全(与GB/T 20438的关系)
GB/T 20438是关于电气、电子、可编程电子安全相关系统的功能安全通用标准和基础安全标准。
这意味着,各工业领域将基于GB/T 20438的要求建立自身的功能安全标准。
在汽车行业,如果直接应用GB/T 20438会存在许多问题。其中的一些问题和GB/T 34590中相
应的差异描述如下。
GB/T 20438基于“受控设备”模型,例如具有如下关联控制系统的工业嵌入装置:
a) 危害分析识别出与受控设备(包括设备控制系统)关联的危害,并对此应用风险降低措施。这
可通过电子/电气/可编程电子系统、其他技术的安全相关系统(例如:安全阀)或外部措施(例
如:嵌入装置的物理围堵)来实现。GB/T 34590基于严重度、暴露概率和可控性,为危害分级
提供了规范化的汽车领域的方案。
b) 分配给电子/电气/可编程电子系统的风险降低,是通过指定的安全功能实现的。这些安全功
能要么是独立的保护系统的一部分、要么嵌入装置控制中。但在汽车系统中,未必能做出这
种区分。车辆的安全依赖于控制系统自身的表现。
GB/T 34590使用了安全目标和安全概念的如下思想:
---通过危害分析和风险评估识别出需要防止、减轻或控制的危害和危害事件;
---为每个危害事件制定安全目标;
---将汽车安全完整性等级(ASIL)与每个安全目标关联;
---功能安全概念是实现安全目标的功能性的表述;
---技术安全概念是功能如何通过硬件和软件在系统层面实现的表述;及
---软件安全要求和硬件安全要求表述了特定的安全要求,这些要求将作为软硬件设计的一部分
而被实施。
示例:
---安全气囊系统:其中一个危害是气囊非预期的起爆;
---相关的安全目标是气囊不能起爆,除非发生需要气囊起爆的碰撞;
---功能安全概念可定义冗余的功能来探测车辆是否发生碰撞;
---技术安全概念可定义两个具有不同轴向的独立加速度传感器和两个独立点火回路的实施方案,如果两路均闭合则起爆点火管。
GB/T 20438针对的是单一的或小批量的系统。系统经过制造和测试后安装到嵌入装置,然后执
行安全确认。对于大批量销售的系统,如道路车辆,安全确认在量产之前执行。因此GB/T 34590中生
命周期活动的次序有所不同。对此,GB/T 34590.7-2017第5章提出了对生产的要求。而在
GB/T 20438中并未覆盖此部分内容。
GB/T 20438未对管理跨多个组织和供应链的开发提出特定要求,而GB/T 34590明确地提出了这
个问题,包括开发接口协议(DIA)[参见GB/T 34590.8-2017第5章(分布式开发的接口)],这是因为
汽车系统是由客户(如整车厂、客户的供应商或客户自己)的一个或多个供应商生产的。
GB/T 20438不包含危害分级的规范化要求。GB/T 34590则包含了汽车领域危害分级的方案。
此方案认为不是汽车系统的每个危害都会导致事故。其结果取决于涉险人员是否实际暴露在危害发生的场景下,且它们能否采取措施以控制危害的结果。图2给出了应用了此概念的失效示例,即:影响运
动中车辆可控性的失效。
注:此概念仅为了阐述失效的发生和事故之间没有必然的直接关联。尽管此过程中评估的参数与图中状态过渡的可能性相关,但它不是危害分析和风险评估过程的展示。
为符合汽车工业的当前技术水平,对硬件开发(GB/T 34590.5-2017)和软件开发(GB/T 34590.6-
2017)要求进行了调整。特别地,GB/T 34590.6-2017包含涉及基于模型开发的要求;GB/T 20438规
定了特定方法的应用,对于使用任何替代方法,必需提供详细的理由。而对于GB/T 34590中列出方
法,给出了特定的目标。为实现这些目标,可应用给出的方法,或应用替代方法,但需提供理由证明替代
方法也能实现目标。
为GB/T 34590中的安全要求分配汽车安全完整性等级(ASIL)而不是安全完整性等级(SIL),其
主要原因是GB/T 20438中的SIL表述为概率术语(参见GB/T 20438.1-2006表3)。GB/T 20438阐
述:“在评估目标的失效措施是否达成时,可以接受仅考虑硬件安全完整性的量化技术及应用可靠性预
测技术。为满足(有关系统性安全完整性的)目标失效措施的必要预防措施,需使用定性技术和判断。”
ASIL不是基于这类有关危害发生的概率的要求,但也存在关于符合ASIL要求的概率目标。
4.2 相关项、系统、要素、组件、硬件元器件和软件单元
GB/T 34590.1-2017中定义了相关项、系统、要素、组件、硬件元器件和软件单元。图3展示了系
统、要素、组件、硬件元器件和软件单元的关系。图4举例展示了相关项的分解(构成关系)。可分解的要素可被标注为系统、子系统或组件。满足系统标准的可分解要素可被标注为系统或子系统。当着重强调要素是一个更大系统的一部分时,使用术语“子系统”。组件是非系统层面的、逻辑上和技术上独立的要素。通常,术语“组件”用于仅由元器件和单元组成的要素,但也能用于由更低层面的特定技术领域[例如:电子电气技术(参见图4)]要素组成的要素。
示例:对于微控制器或特定用途集成电路(ASIC),可使用如下分割:整个微控制器是一个组件,处理单元[例如:中央处理单元(CPU)]是一个元器件,处理单元中的寄存器(例如:中央处理单元寄存器组)是一个子元器件。
在进行微控制器分析时,需要进行更细节层面的分割,为帮助达到此目的,可能要将元器件分割成子元器件,再将子元器件进一步分割成基础子元器件。
注1:根据上下文,要素可用于此图表中的系统、组件、硬件元器件和软件单元,按照GB/T 34590.1-2017的2.3.2。
注2:GB/T 34590.1中定义的系统至少包含传感器、控制器和执行器,例如:至少3个相关的要素。
注3:*表示可能有N 个要素。
4.3 故障、错误和失效之间的关系
在GB/T 34590.1-2017中定义了术语:故障、错误和失效。图5从三个不同类型的原因(系统性
软件问题、随机硬件问题和系统性硬件问题)描述了故障到错误并从错误到失效的发展过程。系统故障(参见GB/T 34590.1-2017)起因于设计和规范的问题;软件故障和部分硬件故障是系统性的。随机硬
件故障(参见GB/T 34590.1-2017)起因于物理过程,比如疲劳、物理退化或环境应力。在组件层面,每
个不同类型的故障会导致不同的失效。然而,组件层面的失效是相关项层面的故障。注意,在此示例
中,整车层面不同原因导致的故障可引起相同的失效。如果额外的环境因素使失效叠加了事故场景,相
关项层面的部分失效将会是危害(参见GB/T 34590.1-2017)。
示例:当车辆开始穿越十字交叉路口时发生非期望的行为,可能发生碰撞,例如:对危害事件“当车辆开始穿越十字交叉路口时发生猛烈窜动”的风险进行严重度、暴露概率和可控性的评估(“猛烈窜动”是指突然的剧烈移动)。
5 关于安全管理的精选话题
5.1 工作成果
本子章条描述术语“工作成果”。
工作成果是满足GB/T 34590相应要求的结果(参见GB/T 34590.1-2017)。因此,文档化的工作
成果可提供符合这些安全要求的证据。
示例:需求规范是可通过需求数据库或文本文件来记录的一种工作成果。可执行模型是能通过可执行建模语言文件表示的一种工作成果,例如,通过使用软件工具达到仿真的目的。
工作成果的文档(参见GB/T 34590.8-2017第10章)作为已执行的安全活动、安全要求或相关信
息的记录,不局限于任何形式或媒介。
示例:工作成果的文档可通过电子或纸质文件表示,通过单一或系列文档表示。它可以与其他工作成果的文档合并,或与非功能安全直属文档合并。
为避免信息重复,可在文档内或文档间使用交叉引用。
5.2 认可措施
5.2.1 总则
GB/T 34590中定义的工作成果,或作为认可措施的一部分,或作为验证活动的一部分,在后续活
动中得到评估。本子章条描述了验证和认可措施间的差异。
一方面,开展验证活动是为了确定安全要求的完整性,及安全要求的定义和实施的正确性。工作成
果的验证可包括:
---验证评审,对比更高层面的安全要求,验证导出后的安全要求在定义和实施的完整性及正确
性;或
---测试案例的执行或测试结果的检查,通过检测相关项或其要素,来提供满足已定义的安全要求
的证据。
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.8-2017第6章(安全要求的定义和管理)定义了对安全要求进行验证的进一步细节。
另一方面,执行认可措施是为了评估相关项功能安全的实现,包括对以下内容的认可:
---依照GB/T 34590的要求,对相关项开发过程中开展的安全活动和实施的安全过程,进行恰当
的定义、剪裁和执行;
---符合GB/T 34590相应要求的恰当工作成果内容。
GB/T 34590.2-2017第6章(概念阶段和产品开发过程中的安全管理)定义了认可措施。
示例:如果在系统设计阶段应用ASIL分解,则:
---根据技术安全概念(参见GB/T 34590.4-2017的7.4.8)对生成的系统设计进行验证;及
---依照GB/T 34590.9-2017第5章(关于ASIL剪裁的要求分解)对正确实施ASIL分解的确认,可作为
功能安全评估的一部分,包括:对已经开展的相关失效分析的确认和对声明执行相应冗余安全要求的
要素间具备充分独立性的论证。
5.2.2 功能安全评估
如果相关项安全目标的最高ASIL等级是ASILC或D,则开展功能安全评估以评价相关项是否实
现功能安全。在GB/T 34590.2-2017中,分别描述了功能安全评估的某些方面,即功能安全审核和认
可评审。
功能安全评估包括:
a) 对已实施的、可在相关项开发过程中评估的安全措施的恰当性和有效性的评审;
b) 对安全计划所要求的工作成果的评估,着重对选定的工作成果进行评审,这些活动作为认可
评审,目的是确认这些工作成果符合GB/T 34590的相应要求;
c) 一次或多次功能安全审核,以评估功能安全所要求的流程的实施情况。
功能安全评估可被重复或更新。
示例1:因变更管理流程识别出相关项或其要素的变更对相关项的功能安全存在影响[参见GB/T 34590.8-2017第8章(变更管理)],而对功能安全评估进行更新。
示例2:因功能安全评估报告包含了对相关项功能安全进行“有条件接受”或“拒绝”的建议,由此需要重复进行功能安全评估。在此情况下,重复评估包含对上一次功能安全评估所做建议的跟进,如果适用,还包括对已实施的纠错行动的评价。
如果相关项安全目标的最高ASIL等级是ASILB,功能安全评估可被省略或以不严格的方式执
行。然而,即使不执行功能安全评估,仍需执行其他认可措施,即:对危害分析和风险评估、安全计划、相关项集成和测试计划、确认计划、适用的安全分析、在用证明(如果适用)和安全档案的完整性的认可评审(参见GB/T 34590.2-2017表1)。
如果相关项安全目标的最高ASIL等级是ASILA,GB/T 34590不要求、不建议、但也不反对执行
功能安全评估。然而,仍需执行对危害分析与风险评估及适用的安全分析的认可评审。
在分布式开发的情况下,功能安全评估的范围包括由整车厂和相关项供应链中的供应商生成的工
作成果、实施的流程及安全措施[参见GB/T 34590.2-2017和GB/T 34590.8-2017第5章(分布式开发
的接口)]。
功能安全评估的目的是评价相关项功能安全的实现,这只能在相关项层面进行。因此,在(开发相
关项要素的)供应商处所作的功能安全评估具有局限性,从本质上它是后续(客户层面)功能安全评估活
动的输入。作为相关项开发中的最终客户,整车厂指派人员开展完整范围内的功能安全评估,以判断相
关项功能安全的实现。此判断包括对相关项的功能安全提供“接受”“有条件接受”和“拒绝”的建议。
注1:对于由一级供应商负责包括整车集成的相关项开发的情况,该供应商承担整车厂的上述角色。
实际方法上,分布式开发中的功能安全评估可就此分解为:
---在供应商处的有限范围的功能安全评估,涉及供应链中的供应商。适用的ASIL等级是供应
商开发的相关项各要素所继承的(相关项各安全目标的)最高ASIL等级(参见GB/T 34590.8-
2017的5.4.5);
---最终的功能安全评估,包括对集成的相关项实现功能安全的判断,例如由整车厂开展的评估。
适用的ASIL等级是相关项全部安全目标中最高的ASIL等级(参见GB/T 34590.2-2017)。
示例:整车厂开发一个具有ASILD安全目标(SG1)和ASILA安全目标(SG2)的相关项,并将对其开展功能安全评估。存在如下可能情况,某二级供应商或三级供应商只开发了相关项的 ASILA要素,即仅继承SG2的ASIL等级的要素[然而,如果适用,参考GB/T 34590.9-2017第6章(要素共存的准则)]。对于在该供应商处开展有关此相关项开发的功能安全评估,GB/T 34590未给出(支持或反对的)要求或建议。
与客户和供应商接口有关的功能安全评估的范围、评估的流程(例如:需由供应商提供的工作成果,
需由客户评审的工作成果)和评估的执行,在相应开发接口协议中进行了定义[参见GB/T 34590.8-
2017第5章(分布式开发的接口)]。
示例:整车厂(客户)与一级供应商之间的开发接口协议(DIA)。一级供应商与二级供应商之间的开发接口协议(DIA)。
在分布式开发的情况下,功能安全评估的可能开展方式是整车厂和供应链中的供应商各自处理所
负责的评估活动[参见上述a)、b)、c)项]的如下方面:
---供应商对所开发要素中实施的安全措施进行评审,包括措施对满足相应安全目标或安全要求
(由客户提供或由供应商开发)的适当性和有效性,并评估安全措施的实施过程及适用的工作
成果。供应商也评估所开发要素对相关项功能安全的潜在影响,例如:对实施的可带来新危害
的安全措施的识别;
---整车厂对集成后的相关项的功能安全进行评估。评估的一部分可基于由一个及以上供应商提
供的工作成果或信息,包括在供应商处开展的功能安全评估的报告。
注2:客户可对供应商实施的安全措施及完成的工作成果进行评估。客户也可对供应商处的实施过程进行评估(参见GB/T 34590.8-2017的5.4.4.8)。
5.3 安全档案的理解
5.3.1 安全档案的解释
安全档案的目的是提供一个由证据支持的、清晰的、全面的和正当的论据,以证明当运行在预期的
环境中时,相关项不存在不合理的风险。
此处提供的指南聚焦于GB/T 34590的范畴。
安全档案有三个主要素:
---要求;
---论证;及
---证据,即GB/T 34590的工作成果。
图6描述了GB/T 34590上下文中这三个要素间的关系。
图6 安全档案(参见参考文献[2])的关键要素
安全论证表达了证据和目标之间的关系。安全论证的重要性经常被忽视。可能展示了许多页的支
持证据却没有清晰的解释此证据如何联系到安全目标。论证和证据都是安全档案的决定性要素,并且
是齐头并进的。没有支持证据的论证是没有事实根据的,因此是不足以令人相信的。没有论证的证据
是不清楚的,以致缺乏安全目标如何得到满足的清晰解释。通过开发和展示安全档案报告,表达安全档
案。安全档案报告的任务是汇总安全论证,并对记录安全支持证据的报告进行引用(例如:测试报告)。
在其他行业中使用的安全论证,经常是通过叙述性文本的安全案例报告表达的。叙述性文本可描
述安全目标是如何被解释、分配和分解的,最终引用证据证明符合较低层面的安全声明。或者,使用图
形化论证符号(如:“声明-论证-证据”和目标结构表示法[2])正变得越来越流行,形象化的和明确的展示
安全论证的独立要素(要求、声明、证据和背景),同时展示这些要素间存在的关系(即,特定声明如何支
持独立要求,证据和为论证定义的假设背景如何支持声明)。
通过直接诉诸实施的相关项的特征(例如:定时看门狗的行为)来证明安全的安全论证通常被称为
产品论证。通过诉诸开发和评估过程的特征(例如:采用的设计符号)来证明安全的安全论证通常被称
为过程论证。
可使用两种类型的论证,以达到对相关项安全的完整论证,这里,过程论证可被看成是为产品论证
中用到的证据提供可信度。
5.3.2 安全档案开发生命周期
安全档案的开发可被视为与安全生命周期内其余开发阶段集成的增量活动。
注:安全计划可包含安全档案增量步骤的计划和安全档案初始版本的计划。
这种方法允许在产品开发的给定节点生成安全档案的中间版本。例如:安全档案的初始版本可在
技术安全要求验证后生成;安全档案的中间版本可在系统设计验证后生成;及最终版本可在功能安全评
估前生成。
安全档案应符合 GB/T 34590.2-2017的6.4.7(认可措施:类型、独立性和权限)中给定的认可
评审。
如果相关项被修改,需评估对安全档案的影响,如果必要,需根据修改对安全档案进行更新。
6 概念阶段和系统开发
6.1 总则
本节通过使用简单的示例,为概念阶段提供了危害分析和风险分级的原理概览。
6.2 危害分析和风险评估示例
6.2.1 总则
考虑以控制车载嵌入式能量存储装置的相关项为示例。关于此示例的用途,只有在车辆行驶速度
大于或等于15km/h时才试图释放储存的能量。如果车速低于15km/h,储存能量的释放会导致过热
进而引发装置爆炸。
6.2.2 分析1
a) 危害识别
---导致装置中能量非预期释放,从而产生爆炸的失效。
b) 危害事件
关于此示例的用途,进行危害分析和风险评估所考虑的驾驶场景为:
---交通堵塞中行驶速度低于15km/h。
相关项发生失效导致非预期的能量释放,储能装置爆炸,对车辆乘员造成严重伤害。
c) 对识别出的危害事件分级
爆炸对车辆中的乘员导致危及生命的伤害,存活不确定,因此,危害严重度预估为S3。
车辆处在交通堵塞中,且车速低于15km/h。基于对车辆目标市场的交通统计,此场景的暴露
概率预估为E3(1%~10%的驾驶时间内发生)。
车辆驾驶员或乘客控制相关项失效和装置爆炸的能力被认为是不可能的:可控性预估为C3
(难以控制或不可控)。
应用GB/T 34590.3-2017表4:ASIL等级确定为ASILC。
6.2.3 分析2
a) 危害识别
---未导致能量释放的失效。
b) 危害事件
---任何驾驶场景。
相关项发生失效但不导致能量从储能装置中释放,所以不产生伤害。
c) 对识别出的危害事件分级
由于相关项的失效不会导致伤害,严重度评为S0,无需确定可控性,也无需定义安全目标。
6.3 关于可控性分级
如GB/T 34590.3-2017第7章(危害分析和风险评估)中的解释,可控性代表对驾驶员或其他交
通参与者能够避免特定伤害的能力的预估。
在最简单的情况下,只考虑给定危害事件的一个后果,可控性代表了对避免此后果的可能性的预
估。然而,也可能存在其他情况。例如,可能有一个严重后果(例如:严重度S2),却很容易避免(例如:
可控性C1);又或者后果的严重度较低(例如:S1),却难以避免(例如:C3)。假设暴露概率等级为E4,下
面几组数值是可能的结果,其说明了最高的严重度导致最高的ASIL等级不是必然成立的。
---E4,S2,C1大于或等于ASILA
---E4,S1,C3大于或等于ASILB
在此示例中,ASILB是危害事件的合理分级。
6.4 外部措施
6.4.1 总则
外部措施是独立于且不同于相关项的措施,用于降低或减轻相关项失效造成的风险。
6.4.2 基于车辆的外部措施示例1
车辆A装备手动变速箱,当熄火后,变速箱能处于任何挡位,包括空挡。车辆B装备自动变速箱,
熄火状态下,维持一个挡位啮合且离合器常闭状态。两辆车都有附加相关项,电子驻车制动(EPB)。
对两辆车辆都分析的场景含:
---车辆处于驻车状态(熄火,驾驶员不在)。
---在人口稠密的城市区域、有坡度的路边驻车。
---发生涉及电子驻车功能突然丧失的失效。
在此场景中,对于车辆A,熄火时处于空挡(对应于合理可预见的误用的场景),如果无人看管,车辆
将可能发生移动。这会导致评估的可控性为C3、严重度为S2或更高(这取决于车辆附近是否有容易受伤的人员)且暴露概率等级大于E0。按照实际分配的暴露概率等级,得出的 ASIL等级在 QM 和C
之间。
车辆B一直结合在挡位上而不会发生移动,所以不会导致危害。此设计中包含的基于车辆的外部
措施有助于消除该场景下的风险,但前提是自动变速器和电子驻车系统能被证明是充分独立的。
6.4.3 基于车辆的外部措施示例2
车辆A装备动态稳定控制系统和启停功能。车辆B只装备了启停功能。
对两辆车辆都分析的场景包含:
---车辆以中高速行驶(50km/h< v< 90km/h)。
---路面平坦、干燥,且在郊区。
---车辆正在接近一个中等曲率的道路。
---车速和道路曲率会产生中高侧向加速度。
---启停功能中的失效引起发动机非预期熄火,导致在此场景中突然失去驱动力。
作为突然丢失牵引力的后果,车辆会产生横摆力矩,这要求驾驶员调整方向盘以重新控制车辆。在
车辆B上执行这个动作可被证明具有更低的可控性,导致C或D的ASIL分级。相比之下,车辆A的
动态稳定性控制功能会限制侧向不稳定的影响。结果是,对于车辆A,降低了可控性的级别。因此,由
动态稳定性控制实现的基于车辆的外部措施有助于此场景下的风险降低。然而,仅当能证明所考虑的
启停功能失效不会影响动态稳定性控制功能,并且对这两个功能来说不是相关失效,才适用这种情况。
6.5 合并安全目标的示例
6.5.1 介绍
安全目标是相关项的顶层安全要求。它们导出避免危害事件产生不合理风险所需的功能安全要
求。按照GB/T 34590.3-2017的7.4.8,概念阶段中会确定安全目标。当安全目标相似或涉及不同场
景下的相同危害时,它们可以被合并成以原始安全目标的最高ASIL等级为最终ASIL等级的一个安
全目标。这使管理的安全目标变少,却覆盖了所有识别出的危害,因此可简化后续的开发活动。
6.5.2 总则
下面示例中展示的相关项、安全目标和ASIL分级仅为了说明安全目标合并的过程。该示例不能
反映将GB/T 34590应用到相似真实项目的情况。特别是,它没有完整表述失效模式识别、场景分析和
整车层面的影响评估。
为简单起见,示例只限于两个安全目标的合并,但相同的方法可以扩展到更多初始安全目标的
合并。
6.5.3 功能定义
考虑车辆装备了电子驻车制动(EPB)系统。当被驾驶员的特定请求激活时,EPB系统在车辆后轮
施加制动力矩以防止驻车时车辆非预期的移动。
6.5.4 应用于不同场景下相同危害的安全目标
6.5.4.1 危害分析和风险评估
为简化示例,考虑驻车功能的如下失效模式:
---非预期的驻车制动激活。
6.5.4.2 安全目标的阐述
如上所示,相同的安全目标和安全状态适用于两种场景。因此,可定义如下安全目标:
---安全目标:当车辆移动时,避免在没有驾驶员请求的情况下激活驻车功能。
---安全状态:禁止EPB功能。
---ASIL:表1中确定的较高ASIL等级分配给此安全目标。
7 安全过程的要求结构-安全要求的运行和顺序
图7和图8展示了符合GB/T 34590的安全要求开发流和顺序,并在下面略述。特定章以如下方
式表示:“m-n”,m代表部分的数值,n代表章的数值或子章的数值。
开展危害分析和风险评估以识别风险并为这些风险定义安全目标[见GB/T 34590.3-2017第7
章(危害分析和风险评估)]。
导出的功能安全概念定义了功能安全要求,以满足功能安全目标。这些要求定义了被相关项所使
用的安全机制和安全措施。此外,对支持这些要求的系统架构要素进行了识别[见GB/T 34590.3-
2017第8章(功能安全概念)]。
导出的技术安全概念定义了技术安全要求及其对系统要素的分配,以被系统设计所实现。这些技
术安全要求将指明硬件要素和软件要素的分割[见GB/T 34590.4-2017第6章(技术安全要求的定
义)]。
按照技术安全要求进行系统设计开发。技术安全要求的实施可在系统设计规范中进行定义[见
GB/T 34590.4-2017第7章(系统设计)]。
最后,将提供硬件和软件安全要求以符合技术安全要求和系统设计[见GB/T 34590.5-2017第6
章(硬件安全要求的定义)和GB/T 34590.6-2017第6章(软件安全要求的定义)]。
---系统设计:
从相关项定义(3-5)到初步架构设想、再到系统设计(4-7),不断细化系统设计。
---测试层面间的相关性:
每个层面上的测试规范和测试案例主要取决于相应的要求和设计。它们不取决于其他测试层
面的测试规范、测试案例和测试结果。测试规范通常依赖于测试环境。
---测试层面与要求层面的相关性、测试层面与设计层面的相关性:
测试规范和测试案例由相同层面的要求得出,并由相同层面的设计信息所支持。
示例:对于性能测试,设计信息是必要的。
---软件安全要求验证:
软件安全要求验证阶段(6-11)需要对软硬件进行集成。
---外部措施和其他技术:
在整车层面确认外部措施和其他技术。
8 关于硬件开发
8.1 随机硬件故障的分类
8.1.1 总则
一般来说,所考虑的故障组合限定于两个独立硬件故障的组合,除非基于功能安全概念或技术安全
概念的分析显示,n(n >2)点故障是相关的。因此,在大多数情况下,对于给定的安全目标和给定的硬
件要素,故障可被归为以下某种类别:
a) 单点故障;
b) 残余故障;
c) 可探测的双点故障;
d) 可感知的双点故障;
e) 潜伏的双点故障;或
f) 安全故障。
下文将给出对于不同故障类别的解释及示例。
8.1.2 单点故障
该故障:
---可直接导致违背安全目标;及
---是硬件要素的故障,对于该硬件要素,没有任何安全机制预防其某些故障违背安全目标。
示例:一个未被监控的电阻,该电阻至少有一种失效模式(例如:开路)有违背安全目标的潜在可能。
注:如果一个硬件元器件有至少一个安全机制(例如:微控制器的看门狗),则该元器件的故障不被归类为单点故障。对于安全机制未预防其违背安全目标的故障,被归类为残余故障。
8.1.3 残余故障
该故障:
---可直接导致违背安全目标;及
---是硬件要素的故障,对于该硬件要素,有至少一个安全机制预防其某些违背安全目标的故障。
示例:如果仅用棋盘RAM测试的安全机制来检查随机存储器(RAM)模块,则不能探测出某些种类的桥接故障。
因这些故障导致的对安全目标的违背不能被安全机制所预防。这些故障即为残余故障的示例。
注:此情况中,安全机制的诊断覆盖率小于100%。
8.1.4 可探测的双点故障
该故障:
---促使安全目标的违背;
---仅与另一个(双点故障有关的)独立硬件故障联合,才能导致安全目标的违背;及
---被防止其潜伏的安全机制所探测。
示例1:被奇偶校验保护的闪存:按照技术安全概念对单个位故障进行探测并触发响应,如:关闭系统并通过警示灯
通知驾驶员。
示例2:被错误探测和纠错码(EDC)保护的闪存:按照技术安全概念通过测试对这些EDC逻辑中的故障进行探测
并触发响应,如:通过警示灯通知驾驶员。
对于安全机制使相关项恢复到无故障状态的瞬态故障情况,即使驾驶员从未被通知故障的存在,此
故障可被考虑为可探测的双点故障。
示例:在数据提供给CPU前,瞬态的位翻转被错误探测和纠错码(EDC)纠正,并通过写回正确值得到后续纠正。
可使用记录来区分间发故障和真正的瞬态故障。
8.1.5 可感知的双点故障
该故障:
---促使安全目标的违背,但仅与另一个(双点故障有关的)独立硬件故障联合,才会导致安全目标
的违背;及
---在规定的时间内被驾驶员所感知(有或无安全机制探测)。
示例:如果故障后果显著和清楚的影响功能,双点故障可被驾驶员感知。
注:如果双点故障同时被驾驶员感知并被安全机制探测,该故障可被归类为可探测的双点故障或可感知的双点故障。但它不能同时被归类为这两种类型,因为一个故障如果既是可探测的双点故障,又是可感知的双点故障,则潜伏故障度量会错误的计算该故障两次。
8.1.6 潜伏的双点故障
该故障:
---促使安全目标的违背,但仅与另一个独立硬件故障联合,才会导致安全目标的违背;及
---不被安全机制所探测也不被驾驶员感知。直到第二个独立故障发生前,系统始终可以运行且
驾驶员也不知道发生了故障。
示例1:对于被EDC保护的闪存:在读取时,EDC纠正了单个位的永久性故障值,但这不是在闪存中纠正也无信号指示。在此情况中,故障不能导致安全目标的违背(因故障位已得到了纠正),且它不是可探测的(因对单个位故障无信号指示),也不是可感知的(因对应用的功能性无影响)。如果在EDC逻辑中发生了额外的故障,它可导致失去对单个位故障的控制,从而导致潜在的安全目标的违背。
示例2:对于被EDC保护的闪存:导致EDC不可用的EDC逻辑故障未被测试探测出来。
8.1.7 安全故障
安全故障可以是以下两类故障中的一种:
a) n >2的全部n点故障(除非安全概念显示它们与安全目标的违背有关联);或
b) 与安全目标违背无关的故障。
示例1:对于被EDC和循环冗余校验(CRC)保护的闪存:被EDC纠正的单个位故障不通过信号指示出来。该故障对安全目标的违背得到了EDC的预防,但未通过信号指示出来。如果EDC逻辑失效,该故障被CRC探测到,系统被关闭。只有当闪存中存在单个位故障、EDC逻辑失效、且CRC校验和监控失效时,才能发生对安全目标的违背(n=3)。
8.1.8 故障分类及故障类别贡献率计算的流程图
硬件要素的失效模式可按照GB/T 34590.5-2017图B.1展示的,并使用GB/T 34590.5-2017
图B.2描述的流程图进行分类。图9展示了考虑基础失效率及不同失效模式(残余对潜伏)覆盖率的多
种失效率计算。
8.1.9 在处理随机硬件失效时,如何考虑与基于软件的安全机制相关的多点故障失效率
虽然软件和硬件的系统性故障在GB/T 34590中未被量化,在处理随机硬件失效时,对于支持运行
基于软件的安全机制的硬件资源,可计算其随机硬件失效的失效率。
如果那些硬件资源同时用于支持具有直接违背安全目标潜在可能的功能,则选取反映此情况的失
效模式并考虑潜在的相关失效。
8.2 残余失效率和局部单点故障度量评估的示例
8.2.1 总则
本示例阐述了一种评估传感器残余失效率λRF,Sensor、单点失效率λSPF和单点故障度量MSPFM,Sensor本地化版本的方法。在此示例中,测量相同物理量并具有已知误差的两个传感器,一个传感器与另一个传感器的值相比较。应用功能使用传感器A_Master的值,另一个传感器A_Checker的值仅用于确认传感器A_Master的值。
此监控在GB/T 34590.5-2017附录D中得到了引用,作为“传感器合理性检查”或“输入比较/表
决”。
8.2.2 传感器A_Master的技术安全要求
图10中展示了传感器A_Master的安全运行边界,并作为此示例的前提(即:此处不讨论如何从安
全目标导出)。
8.2.3 安全机制的描述
安全机制的要素是传感器A_Checker和监控硬件,其包含带有嵌入式软件的微控制器。在小于容
错时间TSenA的周期内,软件周期性的对比两个传......
英文网页English: GB/T 34590.10-2017
相关标准: GB/T 34590.11|GB/T 34590.5|GB/T 34590.6|GB/T 34590.4|GB/T 34590.10-2017|GB/T 34590.10|