(二十)通俗易懂理解——汽车功能安全

来源:
2020-03-12
1
1
1

——提供了汽车生命周期(管理,研发,生产,运行,服务,拆解)和生命周期中必要的改装活动。

——使用 ASILs方法来确定获得可接受的残余风险的必要安全要求。

主要用于安装在最大毛重不超过 3.5 吨的乘用车上的一个或多个 E/E 系统的安全相关系统。不包括电击,火灾,热,辐射,有毒物质,可燃物质,反应物质,腐蚀性物质,能量释放及类似的危险,除非这些危险是由于 E/E 安全相关系统故障导致的。

Part 1:定义

Part 3:概念阶段

Part 5:产品研发:硬件级

Part 7:生产和操作

Part 9:基于 ASIL 和安全的分析

ISO26262 系列标准分为 10 本,从 ISO26262-1 到 ISO26262-10,分别从功能安全管理,概念,系统级研发,软硬件的研发,生产和操作等方面对产品的整个生命周期进行了规范和要求。从而使得产品在各个生命周期都比较完善的考虑了其安全功能。

那么各部分又有什么具体含义和措施呢?下面就来分别说明:

项目定义,是对所研发项目的一个描述,是安全生命周期的初始化任务,其包括了项目的功能,接口,环境条件,法规要求,危险等内容,也包括项目的其他相关功能,系统和组件决定的接口和边界条件等。

基于项目定义,安全生命周期要对项目进行区分,确定是新产品研发,还是既有产品更改。如果是既有产品更改,影响分析的结果可以用来进行安全生命周期的拼接。

安全生命周期初始化之后,就要按照 ISO26262-3 的第七条款来进行危险分析和风险评估,危险分析和风险评估的流程要考虑暴露的可能性,可控性和严重性,以便确定项目的 ASIL 等级。接下来就是为每一个风险设立安全目标,并确定合适的 ASIL 等级。

基于安全目标,功能安全概念就要考虑具体的基本架构。功能安全概念就是对定位到每个项目元素中的功能安全要求的具体化和细化。超出边界条件的系统和其他技术可以作为功能安全概念的一部分来考虑。对其他技术的应用和外部措施的要求不在 ISO26262 考虑的范围之内。

有了具体的功能安全概念之后,接下来就是按照 ISO26262-4 的系统级研发了。系统级研发的过程基于技术安全要求规范的 V 模型。左边的分支都是系统设计和测试,右边的分支是集成,验证,确认和功能安全评估。

基于系统的设计规范,硬件级的产品研发要遵循 ISO26262-5 的要求。硬件研发流程应符合 V 模型概念左侧分支的硬件设计和硬件要求。硬件的集成和验证在右侧分支。

基于系统的设计规范,软件级的产品研发应遵循 ISO26262-6 的要求。软件研发流程应符合 V 模型概念中左侧分支的软件需求规范和软件设计架构设计的要求。软件安全需求中的软件集成和验证在右侧分支中。

其包括:生产和操作计划,相关的需求规范,系统级产品研发的开始等。ISO26262-7 的第 5 条款和第 6 条款给出了生产和操作的具体要求。

产品发布是产品研发的最后一个子阶段,该项目也将完成,具体要求在ISO26262-4 的第 11 条款中。

产品的操作、服务和拆解应符合 ISO26262-7 的第 5 条款和第 6 条款中,对产品的生产、操作、服务和拆解的相关要求。

在危险分析和风险评估中,要考虑司机和处于危险中的其他人可以采取措施来控制危险情况的能力。如何提供对可控性的有效性证明不在 ISO26262 的范围之内。

参考项目以外的,在项目定义中被描述的措施(参加 ISO26262-3 的第 5 条款),以便减小项目的危险结果。外部危险降低措施不但可以包括附加的车载设备,如:动态稳定控制器防爆轮胎等,也可以包括非车载装置,如:护栏,隧道消防系统等。这些外部措施在进行危险分析和风险评估的时候应该被考虑到,但如何为这些外部措施的有效性提供证明不在 ISO26262 的范围之内,除非是 E/E设备。但要注意的是,没有明确安全例证的外部措施是不完整的。

其他技术是指那些不在 ISO26262 范围之内的,不同于 E/E 技术的设备。如:机械和液压技术。这些都要在功能安全概念的规范中加以考虑或者在制定安全要求时加以考虑。


1.1 本质安全与功能安全

假如以铁道的路口为例,比较一下基于两种安全概念的避免路口事故的方法。这里避免路口事故就是安全目标,为了实现这个目标,可进行如下操作:

其次,假如我们在铁道路口设置信号灯和道口自动栏杆,当火车来临时前闪红灯,同时将栏杆放下,避免行人或者车辆通过。像这样通过栏杆的拦截功能及预警灯来抑制事故风险的技术叫做「功能安全」。在这里信号灯和自动栏杆一种安全机制(Safety Mechanism)。理想的情况是不管什么场合都采用 「本质安全」,但事实上,在很多场合里,由于系统自身的原因,不可能把危险源除掉。特别是像车载电控系统这样非常复杂的电子化系统,以上所述的本质安全很难被实现和应用。因此我们只能采用功能安全,它的目的就是在本质安全无法达到时,尽可能的通过增加安全机制去提高安全等级,实现安全目标。

1.2 电子控制器的功能安全

对于传统汽车而言,它的结构简单,且大多数命令都是通过机械方式来实现的,如老式汽车的机械式节气门等,其失效的可预见性大;而现在汽车,其电子电气化增强,驾驶员的指令会先转换成相关信号,然后这些信号传递给控制器的处理芯片,然后最终驱动相关的执行器来执行,其失效的可预见性大大降低。


针对电子控制器失效了怎么办这个问题,首先得确定一个角度。比如极端高温情况下的ECU自燃,爆炸等这种系统本身带来的风险,这种风险不在功能安全的考虑范围内。

根据国际上知名的安全协会的定义,比如英国的MISARA(The Motor Industry Software Reliability Association 汽车工业软件可靠性协会),比如德国的德国VDA协会(VDA(Verband der Automobilindutrie)德国汽车工业协会)他们是从车辆可控性的角度对功能安全提出要求。而IEC-61508强调从人身安全(还可以考虑设备安全)角度提出需求。


ISO 26262是专门用作提升汽车电子电气产品功能安全的国际标准,它派生于电子、电气及可编程器件功能安全基本标准IEC61508。那26262是如下定义功能安全这个概念的:

没有由电子、电气系统故障行为导致的危险所引起的不合理风险。

A.没有风险:absence of risk

C.没有由电子、电气系统故障行为导致的危险所引起的不合理风险

总体来说,功能安全是指避免由系统功能性故障导致的不可接受的风险。它关注的是系统发生故障之后的行为,而不是系统的原有功能或性能。因此功能安全的目的就是当系统发生故障后,将系统进入安全的可控模式,避免对人身、财产造成伤害。

2,ASIL汽车安全完整性等级

对电子控制器ECU来说,引起失效主要是两个方面:软件和硬件。

硬件失效:如下图所示可以分为传感器失效;ECU硬件失效(比如CPU或者RAM/ROM失效);执行器失效;

功能故障在特定的驾驶场景下才会造成伤亡事件,比如近光灯系统,其中一个功能故障就是灯非预期熄灭,如果在漆黑的夜晚行驶在山路上,驾驶员看不清道路状况,可能会掉入悬崖,造成车毁人亡;如果此功能故障发生在白天就不会产生任何的影响。

危害事件确定后,根据三个因子——严重度(Severity)、暴露率(Exposure)和可控性(Controllability)评估危害事件的风险级别——也就是ASIL等级。

ASIL等级的定义是为了对失效后带来的风险进行评估和量化以达到安全目标,其全称是Automotive Safety Integration Level--汽车安全完整性等级。这个概念来源于IEC61508,其通过失效概率的方式定义了安全完整性等级(SIL)。但是在汽车界只有硬件随机失效可以通过统计数字评估失效概率,软件失效却难以量化,因此26262根据汽车的特点定义了ASIL。

2.3 危险分析和风险评定

A.危险事件所导致伤害或损失的潜在严重性 (Severity of failure, S)

C.危险所涉及的驾驶员和其它交通人员通过及时的反应避免特定伤害或损失的能力 (controllability, 简称C)

按照以上的划分并进行组合相加得到5个ASIL等级(QM,A,B,C,D),原则是:

B. 无伤害S0的组合不考虑;

D. 其余的得分安全评定为QM,代表与安全无关的功能(Non Safety Relevant Function)

1,EPB(Electrical Park Brake)电子手刹

得出了EPB系统的安全目标为:防止非期望的制动,ASIL等级为D

2.4 功能安全目标的分解

从安全目标可以推导出开发阶段的安全需求,安全需求继承安全目标的ASIL等级。如果一个安全需求分解为两个冗余的安全需求,那么原来的安全需求的ASIL等级可以分解到两个冗余的安全需求上。因为只有当两个安全需求同时不满足时,才导致系统的失效,所以冗余安全需求的ASIL等级可以比原始的安全需求的ASIL等级低。ISO 26262标准的第9章给出了ASIL分解的原则。ISO 26262中提出了在满足安全目标的前提下降低ASIL等级的方法——ASIL分解,这样可以解决上述开发中的难点。

具体降解的方法如下所示,比如应按照下列之一对一个 ASIL D 的要求进行分解:

2) 一个ASIL B(D)的要求和一个ASIL B(D)的要求;或

其它ASIL等级分解可如下图所示:

功能安全
收藏
点赞
2000
  • 13*******67

    dfg

    2020-03-16
    回复
    点赞