什么是功能安全?功能安全工程师需要做什么?
1.为什么需要功能安全
2.什么是功能安全
3.功能安全考虑的角度
4.安全完整性要求
5.安全目标的制定与分解
6.安全评估
1.为什么需要功能安全
随着汽车电动化、智能化、网联化、共享化的发展,汽车的功能及承载的服务也不断延伸,智能网联汽车将有望取代智能手机成为下一代智能终端。汽车“四化”的发展带来的是整车电子电气架构日趋复杂与集中、整车电子软件代码量激增。根据调研数据发现:目前先进的智能汽车代码量已经达到了2亿行,这一数据超越了IT史上任何一件产品,预计未来L5级自动驾驶汽车软件代码量将突破10亿行。
随着汽车硬件复杂度激增,电子软件和机电设备的爆炸式增长,来自系统失效和随机硬件失效的风险也日益增加。与安全相关的软件和硬件出现任何一个失效,都有可能会给人员、设备及环境带来非常严重的后果,比如非预期的车辆加速、非预期的车辆制动、非预期的车辆转向、电子器件故障引起的车辆着火、车辆被入侵导致的车辆失控等等。
到底有没有一项技术能够最大程度地避免风险保证安全呢?有,那就是功能安全技术。
2.什么是功能安全
欧盟很多汽车准入法规都有功能安全的要求,例如:UN R13H要求汽车制动系统需要满足功能安全的考量;UN R79要求汽车转向系统需要满足功能安全的考量;UN R152要求自动紧急制动系统AEBS需要满足功能安全的考量;EU 2021/646要求紧急车道保持系统ELKS需要满足功能安全的考量。
功能安全这么重要,究竟什么是功能安全呢?
功能安全:不能存在因电子、电气系统的功能失效造成危害而引起的不合理风险。 Functional Safety: Absence of unreasonable risk due to hazards caused by malfunctioning behaviour of E/E systems.
在现代工业控制领域中,可编程电子硬件、软件系统的大量使用,大大提升了自动化程度。但由于设备设计中的缺失,以及开发制造中风险管理意识的不足,一些存在设计缺陷的产品大量流入相关行业的安全控制系统中,已经造成了人身安全、财产损失和环境危害等灾难频出。为此,世界各国历来对石化过程安全控制系统、电厂安全控制系统、核电安全控制系统领域的产品安全性设计技术非常重视,并且将电子、电气及可编程电子安全控制系统相关的技术发展为一套成熟的产品安全设计指导规范,即“功能安全”技术。
ISO 26262标准名称《道路车辆功能安全》是IEC 61508标准在汽车行业的具体应用。从ISO 26262的结构构成可以看到,标准涵盖了全生命周期的安全要求,功能安全管理、概念阶段、系统研发、硬件研发、软件研发、生产和操作过程、售后,但比例最大的是站在产品设计阶段这个时间节点上,考虑怎样从设计上实现产品安全,可以基于原有的功能实现安全,也可以额外添加功能,实现安全。
功能安全是整体安全的一部分,它依赖于一个系统或设备对其输入的正确响应。
例如:盛有可燃性液体的容器内液位开关的动作,当液位到达潜在的危险值时,液位开关就会关闭阀门阻止更多的液体进入容器,从而阻止了液体从容器溢出。这一过程的正确执行,可看做是功能安全。
在电机绕组上装一个热传感器,可以在电机过热前实现断电的过热保护装置,这是功能安全,但采用特殊的隔热材料来抵御高温就不是功能安全。
在铁路道口设置信号灯和自动栏杆,当火车来临时信号灯闪红灯,同时放下栏杆,避免行人、车辆通过,像这样通过栏杆拦截和预警灯来抑制风险的技术叫功能安全。但是,直接把火车道口拆掉,改成立交桥,火车、汽车、行人各走各的道,这样就不会发生人和车横穿铁路道口的事故了。像这样,依据系统特性把危险源直接切除的方法不是功能安全,而是本质安全。
3.功能安全考虑的角度
功能安全研究的对象是电子电气系统,比如机械、液压等部件不在研究范围内。现在汽车的电子电气化水平不断增强,驾驶员的任何操作都会先转化成为相关信号,这些信号通过通信网络传递给控制器的处理芯片,最终驱动相关执行器来执行,整车的安全性将很大程度的取决于电子控制器的安全性。
因为电子控制器失效的可预见性非常低,比如芯片、电路受外界干扰等,这很难预料到什么情况会出什么问题,因此首先需要确定一个角度。德国汽车工业协会(VDA)认为:需要从车辆可控性的角度对功能安全提出需求。而IEC-61508认为:需要从人身安全(设备安全)的角度对功能安全提出需求。因此从车辆可控和人身安全两个层面上考虑功能安全就有了着陆点。
4.安全完整性要求
安全功能要求,由危险分析决定,需要清晰阐述某个具体的安全功能的目的,实现方法。需要清晰表述的要素一般包括风险相关参数,风险发生频率,措施实施后造成最严重后果是怎样的,事故率上限是多少等等。
安全完整性要求,由风险评估确定,按照一个安全功能能够完整执行的可能性的大小,安全等级划分成四个级别,四个等级中的每一个等级定义了ISO26262中相关项或要素的必要的要求和安全措施,以避免不合理的残余风险, D代表最高严格等级, A代表最低严格等级。安全等级越高,发生危险的概率越低。
功能失效和驾驶场景的组合叫做危害事件。例如:近光灯故障导致异常熄灭,如果是在白天则无任何影响,如果是在漆黑的山路上,则有可能导致驾驶员因看不清道路而坠落悬崖。
危害事件确定后,需要根据三个因素即严重度(severity)、暴露率(exposure)、可控性(contollability)来评估危害事件的风险等级,也就是ASIL等级。
严重度(severity):对可能发生在潜在危害场景中的一个或多个人员的伤害程度的预估。
暴露率(exposure):处于某运行场景的状态,在该运行场景下,如果发生所分析的失效模式,可能导致危害。
可控性(contollability):通过所涉及人员的及时反应,也可能通过外部措施的支持,避免特定的伤害或损伤的能力。
在HARA分析过程中,与决定最终ASIL等级相关的评估(S,E,C)时,往往会基于某些假设,这些基于的假设应被明确,而且在产品的安全确认阶段,应对这些假设进行确认。如果难以对一个给定的危害进行严重度、暴露概率或可控性的分级,则在分级时需要保持谨慎,即不论何时有任何疑问,给出一个较高的严重程度S、暴露概率E和可控性C。
E0:不可能;一个极其不寻常的,或不可行的、同时发生的情况;
E1:非常低的概率;
E2:低概率;<1%平均运行时间,如山路、乡村、高速公路出口入口、冰雪路面、倒车、超车、停车;
E3:中等概率;1%-10%的平均运行时间:单行道、湿滑路面、在隧道中、交通堵塞、车辆停在斜坡上,交通繁忙(频繁起停)
E4:高概率;>10%平均运行时间:高速公路、二级公路、加速、减速、转弯、停车、变换车道、停在交通灯前、变换车道(高速公路);
C0:原则上可控,易控。
例如:油量不足报警、驾驶员辅助系统失效等,需要保持既定的行驶路线。
C1:99%或者更多的驾驶员或者交通参与者通常能够避免危害。
例如:驾驶过程中座椅位置错误调整、车辆启动时转向柱锁止,需要制动减速或停止车辆。
C2:90%或者更多的驾驶员或交通参与者通常能够避免危害。
例如:紧急制动情况下ABS失效、高侧向加速时发动机失效,需要保持既定行驶路线。
C3:少于90%的驾驶员或者交通参与者通常能够或者勉强避免伤害。
例如:在低附路面上制动并转向时ABS失效,需要保持既定行驶路线,留在车道里面;制动失效,需要制动减速、停止车辆;车辆在中速或高速行驶中,不符合驾驶员预期的高速转向,需要保持既定行驶路线,留在车道里面。
5.安全目标的制定与分解
安全目标为最高层面的安全要求,通常情况下,安全目标的ASIL等级即为潜在失效的ASIL等级。功能安全关注的是系统发生故障后的行为,而不是系统原有的功能或性能。因此功能安全的目的就是当系统发生故障后,将系统进入安全的可控模式,避免对人身,财产造成伤害。
提出安全目标的同时,需要为该安全目标设定安全状态以及故障容错时间间隔(FTTI),安全状态指的是检测到失效以后应该进入的无风险的运行模式,而FTTI 指的是从发生失效到进入安全状态的最大允许时间间隔。
比如失效模式“档位意外切P挡”的安全目标就是“汽车在有车速时不能意外切换P挡”,安全状态为“撤去整车动力”,故障容错时间间隔(FTTI)为100ms,ASIL等级为D。
将“汽车在有车速时不能意外切换P挡”这一功能安全目标进一步分解就是解决问题的方法,比如将“汽车在有车速时不能意外切换P挡”分解为“汽车在有车速时,VCU不发送切换P挡指令”、“汽车在有车速时,TCU不执行切换P挡指令”。
6.安全评估
执行安全评估所需的必要条件:待评估内容所在的开发阶段主要工作已完成。
功能安全评估应结合产品开发过程的概念阶段、系统阶段、软硬件开发阶段,在相应开发阶段的工作完成后即可开展评估活动,伴随开发过程逐步执行已计划的评估活动,并在相关项生产释放前完成所有评估工作。如果功能安全评估未通过,则应启动充分的修正行动,并重新进行功能安全评估。
简而言之,功能安全是目标,ISO 26262是实现功能安全的指导手册,企业严格遵循ISO 26262标准来设计产品,就能实现功能安全。
更多汽车智驾&法规干货内容详见微信公众号“智驾小强”