汽车电子电气系统的日益复杂使得功能安全成为保障车辆可靠性和驾乘安全的关键。
本文将围绕ISO 26262标准的核心内容展开,帮助大家理解如何通过系统化的方法控制风险,进行测试,确保产品安全。
01 什么是功能安全?
首先,我们需要明确功能安全的定义。根据ISO 26262,功能安全是指:“不存在因电子电气系统(E/E)的功能异常表现而导致的不合理风险。”
ISO 26262对功能安全的定义为:
Absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems.
国标GB/T 34590对这一定义的翻译为:(《GB/T 34590道路车辆 功能安全》 )
不存在由电子电气系统的功能异常表现引起的危害而导致不合理的风险。
这里有两个关键点:
-
关注对象:仅针对E/E系统(如ECU、传感器等)的故障行为,因此机械/液压/化学等设计都不在ISO 26262的研究范围。换句话说,功能安全只是产品安全的一部分。
-
目标:避免因E/E系统故障导致的人身伤害,而非财产损失、车辆防盗、黑客入侵等问题。
危害涵盖多种形式,包括人身伤害或财产损失等。但在功能安全领域,危害特指由电子电气系统(E/E)故障行为引发的健康风险,例如对驾驶员、行人或其他车辆乘员的伤害。功能安全的核心目标是防止人员伤亡,而非避免车辆损坏或防盗问题。换句话说,功能安全开发目的是避免伤人,而不是避免损伤你的豪车,也不是避免你的豪车被偷。
此外,我们也要了解到,绝对安全的系统不存在,功能安全并非追求零风险,而是通过系统化设计将风险降至可接受水平。例如,刹车系统故障可能导致碰撞,但引入冗余设计和故障检测机制可将此类事件发生概率控制在极低范围内。风险管理的重点在于平衡技术可行性与安全需求。如下图所示。
从上图来看,判定风险是否可被接受,需要从两个维度去衡量:危害的严重性和危害发生的频率。
举例来说,飞机失事几乎无人生还,但是正因为飞机失事的概率非常低,所以飞机依然是最重要和最受欢迎的交通工具之一。
如果汽车上的空调开关出现故障的频率比较高,但故障只会影响驾驶员或乘客舒适性体验,不会造成人员受伤,你很可能等到下个月去4S店时才想起来维修它;但是,如果你的车突然在高速上自动加速,估计你马上停在应急车道弃车而逃,喊着要退车了,因为这种原本可以通过设计规避的故障是不可接受的。这也正是功能安全开发期望避免的故障。
功能安全的核心在于通过设计降低系统失效带来的危害。当技术系统出现故障时,能否有效控制风险、避免人身伤害是衡量安全性的关键指标。
简而言之,功能安全聚焦系统故障后怎么做。
02 危害分析与风险评估 HARA(Hazard analysis and risk assessment)
我们从功能安全的定义了解到,功能安全是为了避免风险,那么首先要做的就是“识别风险”,专业术语为“危害分析与风险评估”,这部分在ISO 26262的第3部分里有详细的阐述。
不同故障带来的风险等级差异决定了处理优先级。非安全相关的舒适性功能故障通常被归类为低风险,而涉及制动、转向或动力控制的故障会被识别为高风险事件。
总的来说,危害分析、风险识别和ASIL等级评定都是为了定义研究对象(item)的安全目标(Safety Goal),而所有活动都是基于相关项定义的功能和接口来展开,识别并评估相关项的可能失效导致的危害和风险。针对这一活动,有3点需要强调。
在对这3点进行展开之前,我们需要先了解什么是相关项,这在功能安全里面是一个非常重要的概念。
在对某个产品展开功能安全分析与开发之前,需要先明确产品的功能以及产品的边界。这一活动被称为“相关项定义”。
以上就是相关项定义,英语里叫做 Item Definition。明确了相关项的定义后,我们继续来谈一谈有哪三点需要特别注意:
1. 应在整车层面定义由相关项的功能异常表现导致的危害。—— GB T-34590.3-2022 6.4.2.3
既然是以整车层面观察到的行为来定义危害,那么,从整车动力学的角度,汽车的运动轨迹可以被下图中的运动坐标系完全包含。而在每一个坐标系上,因为控制不当而可能产生的所有的整车表现也能被界定。如这个表所示,这张表列出的是部分汽车各个运动坐标系上可能存在的风险。
比如在纵向(longitudinal motion )上,有突然加速、突然失速等。
在横向(lateral motion )上,有非预期横向运动,这种运动可能是由于车辆控制系统失效、软件错误、传感器故障或其他与车辆动态控制系统相关的问题引起的。非预期的侧向运动可能会导致车辆稳定性降低,增加交通事故的风险。所以,现在很多汽车都有电子稳定系统(ESP)、防抱死制动系统(ABS)、牵引力控制系统(TCS)等技术来增强车辆的可控性。
在垂直方向上,有非预期的垂直运动,比如意外颠簸、跳跃等。非预期的垂直运动可能是由多种因素引起的,比如:悬挂系统的故障或异常工作。车身高度调节系统(如果有的话)的故障。电子控制系统的错误,例如在某些情况下,车辆的高度调节功能可能因为传感器错误而被激活。
因此,在进行危害分析和风险评估时,不需要明确研究对象的具体设计,只要明确研究对象的功能和接口会影响整车哪个坐标系上的控制,就可以将研究对象的功能失效可能导致的危害与该坐标系上对应的整车危害链接起来。
当然,所有运动坐标系上可能的危害并不能包括整车能产生的所有的危害。比如,人机交互界面的设计越来越受重视,当系统失效后,如果HMI系统能够及时把故障报告给驾驶员请求驾驶员接管甚至指导驾驶员接下来如何操作,可以避免危害。所以对于HMI系统也有相应的功能安全需求,相应的,也需要对其进行危害分析与风险识别。
2. 在危害分析和风险评估过程中,应对不含内部安全机制的相关项进行评估(即,在危害分析和
风险评估过程中不应考虑将要实施或已经在先前相关项中实施的安全机制)。GB T-34590.3-2022 6.4.1.2
我们以线控制动产品eBooster为例,eBooster的主要功能之一是在驾驶员制动时提供制动助力。所以该功能有车辆纵向控制的接口,那么,如果eBooster功能失效,可能在驾驶员没踩制动时产生非预期的过大制动力。到这里,我们已经地识别出了eBooster相关的一个危害。在这个过程中,无需去细究危害是eBooster的软件bug还是传感器出了问题导致的,更不能考虑因为eBooster内部已经有故障监控模块可以及时避免这个危害的产生。
换句话说,是先识别出了危害,再考虑对这个危害进行相应的安全措施设计(如监控模块设计),这是后面功能安全概念(Functional Safety Concept)设计需要考虑的内容。
虽然在危害分析与风险识别中不能考虑研究对象的内部安全措施,但是,外部措施(external measures)是可以被考虑的。怎么理解呢?比如装备eBooster的车辆同时也装备了ESC(Electronic Stability System, 车身稳定控制系统),那么对于eBooster在驾驶员没踩制动时产生非预期的过大制动力的危害,由于有ESC的存在,所以对eBooster进行危害分析时,无需考虑制动力过大而导致车辆失稳这种危害。
注:eBooster(一种电子液压助力制动系统,通常与ESC(车身稳定控制系统)配合使用,两者互为冗余)。
3. 通常,每一个危害有多种与相关项的实现相关的潜在原因,但在危害分析和风险评估中对于功能异常表现的分析时,不需要考虑这些原因。—— GB T-34590.3-2022 6.4.2.3 注1
在进行危害分析和风险评估过程中,确实会涉及到对潜在危害及其原因的识别,但重点在于危害本身及其可能带来的后果,而不是具体的潜在原因。
其次,在初步分析阶段,过多地关注潜在的具体原因可能会使分析过程变得过于复杂,从而分散了对核心危害的关注。
此外,定义危害时,通常采用一种更为通用的方法,这样可以适用于多种情况。这意味着即使具体的原因不同,只要危害的表现形式相同,就可以采取相似的缓解措施。同时,通过专注于危害而非具体原因,可以在未来发现新的潜在原因时,仍然能够有效地应用已有的缓解策略。
总之,在危害分析和风险评估的过程中,重点在于识别和评估危害本身及其可能带来的后果,而具体的潜在原因则会在后续更详细的分析和设计阶段予以考虑。这种方法有助于保持分析的清晰度和效率,同时确保安全措施的有效性。
那么,基于HARA的风险评估和处理是一个怎样的过程呢?我们看下面一个流程图。
如图所示,我们首先进行危害分析和风险评估(HARA),识别系统中的潜在危害并评估其风险等级。根据风险评估的结果,我们确定出一个汽车安全完整性等级(ASIL, Automotive Safety Integrity Level)。如果ASIL大于等于A级,就需要采取行动制定策略以增加安全措施,将风险降低到可接受的范围。
一方面,我们需要采取措施避免系统失效,从而降低随机硬件失效的概率。另一方面,我们需要实施安全管理和流程保证措施,确保系统在设计和操作过程中的安全性。最终确保不存在不合理的风险,如果有,则需要重新评估或采取额外措施。
上面提到了ASIL等级,那么ASIL等级是怎么评估出来的呢?我们继续往下看。
接下来,我们对危害事件进行简单的分类。
是不是只要危害发生就一定会导致人员伤亡的风险呢?
同样以前面提到的线控制动产品eBooster为例,eBooster有导致车辆非预期制动的危害,但是当危害发生在高速公路上时,很可能造成人员伤亡;而当危害发生在自家的车库时,几乎没有人员伤亡的风险,顶多就是驾驶员被吓一跳然后开始骂娘。
也就是说,危害识别出来后,我们还要结合危害时刻车辆运行的场景,来对危害所能造成的风险进行评估。而车辆的运行场景,可以理解为是下图中各个因素的排列组合,比如位置,高速还是国道;路况,斜坡还是宽敞大道;驾驶技巧,驾驶过程中进行的各种技巧和动作,如并线、掉头、倒车等。
ISO 26262定义了危害事件分类的方法,综合场景与危害,将筛选指标分为三个维度:
(1)S(severity 严重度):危害发生对驾驶员或乘客或路人或周边车辆中人员会造成的伤害等级。
(2)E(Exposure 曝光度):运行场景在日常驾驶过程中发生的概率。
(3)C(controllability 可控度):驾驶员或其他涉险人员控制危害以避免伤害的概率。
我们基于上述几个维度的评分,来确定ASIL等级即汽车安全完整性等级( automotive safety integrity level)。
ASIL一共分为四个等级,D代表最高严格等级,即风险最高,A 代表最低严格等级,即风险最低。实际上还有一个等级QM,表示只要按照企业流程开发就可以满足ISO 26262要求,ISO 26262开发无需考虑。
ASIL等级评定方法和指标,概括起来很简单,但是实际上操作起来却有很多困难。如上表所示,以S值为例,表格中提到的“非常低的速度”、“中速”等词太过模糊,对实际分析作用不大。
换个角度想,ISO 26262那么多专家坐在一起也只能定性到这样一个模糊的程度,说明实际上这些值的评定会受很多因素的影响,比如具体的车辆设计参数、不同国家的驾驶情况不同等等,所以无法得出一个统一的标准。或者说,即使得出了统一的标准,也会因为要同时涵盖太多的因素而导致评定结果保守严苛,不利于功能安全开发。
对C值来说,车企则会定义一系列的Controllability study测试。针对识别出来的可能存在风险的场景,设计故障注入测试,并(尽量)随机选择驾驶员进行实际道路实验。最终综合驾驶员主观评价和整车动态表现的客观参数来评定出安全边界,为后续功能设计提供边界参考,保证功能失效后仍在大多数驾驶员的可控范围内。值得一提的是,这种Controllability study成本非常高,且从测试用例设计到测试结果评价都处处体现了企业的know-how,属于企业的核心机密。
对S值和C值的评定,不同企业可以根据已有的事故数据达成基本的共识,如果出现分歧,也基本上可以通过仿真和实车测试的结果来验证以消除。但是对场景暴露度E值的评估则不同,因为定性分析的成分很大,且不同国家的驾驶场景有区别,面对分歧双方又很难提供有说服力的数据,所以,相比S值和C值,E值的评定往往争议性比较大,各个车企之间分歧比较多。
总结来说,危害分析和风险评估的流程大致可以概括如下:
若无其他说明,对于ASILA、B、C和D等级,应满足每一章条的要求或建议。但是实际项目中,ASIL D的安全级别是很难达到的,那怎么办呢?这就涉及到了ASIL 等级分解这个知识点,以下是ASIL等级的定义:
为有助于实现同一安全目标,将冗余的安全要求分配给具有充分独立性的要素,以降低分配给相关要素的冗余的安全要求的ASIL等级。
有一点需要注意的是,ASIL等级分解只是从流程上降低要求,在硬件失效率上的要求没有降低。