SASETECH

建立安全生态圈，成为汽车安全的布道者

满德虎

关于自动驾驶安全性的一些基本认知

做安全要始终怀揣对生命的敬畏，坚持通过“端到端”的综合性思维方式来解决现实场景面临的各种复杂局面。

01

和各位小伙伴 Say Hi

大家好，我叫满德虎，是SASETECH的老朋友和资深观众。

在汽车领域，我过去有在主机厂和零部件企业多年的功能安全及预期功能安全从业经历，产品技术领域主要涉及ADAS功能下，从整车到零部件，再到芯片等相关领域的实际工作。积累了一定的经验，也更喜欢从“端到端”的角度思考如何将功能安全方法论有效的实践和落地，尽可能减少或杜绝在实际项目开发中“说起来重要，做起来次要，忙起来不要”的尴尬局面，期望将功能安全变为不可或缺的一个存在。

作为一个并非科班出身的汽车行业从业者，结识汽车功能安全有一定的机缘巧合。当初在非标自动化领域的一个项目经历，至今仍然可以看做是一个还不错的基础起点，让我认识到安全设计的重要性和价值，也使我正式走上了功能安全这个领域。

随着汽车智能化与网联化的发展,汽车领域的安全话题正在成为日益突出的问题。无论是传统的油汽车,还是如今如日中天的纯电动化智能汽车,尤其是在越来越多的车辆控制功能由智能汽车操作系统完成的情况下,汽车的安全性属性显得愈发重要。毕竟,作为消费者,人命关天,没有人会敢于把自己的生命交给汽车机器来保证。

自从 2011 年汽车行业功能安全标准 ISO 26262 发布以来（国内标准 GB/T 34590-2017），距今已经过去了 10个年头。

在这10年的时间里,从安全出发,从解决事故后安全性的被动安全领域到预防事故发生的主动安全领域,汽车的安全功能配置越来越丰富,可以实现的驾驶辅助能力也越来越强。从早期的主动安全功能 AEB （自动紧急制动），BSD（盲区预警），到舒适性功能DCC（定速巡航）, ACC（自适应巡航）,再到具备一定能力的横纵向控制的APA（主动泊车辅助）, RPA（遥控泊车辅助）,功能越高级,给驾驶员带来的舒适性和安全性就越足。目前,上述功能基本都成了新车型的标配。

在这 10 年的汽车安全功能配置不断丰富和高级的同时,也驱动着功能安全在传统汽车研发体系和流程中的不断被引入和融入,且逐渐成为汽车行业标准研发体系和流程中的一个重要环节。同时，功能安全在汽车行业不断更新和发展的 E/E 架构中，也在不断地适应和发挥其关键价值,保证各大车企提供给消费者的辅助驾驶功能不仅能解决好用和易用的问题,也保证了始终如一的安全性属性继续被加强和保证。

但同时，伴随着近几年智能辅助驾驶领域的不断发展，安全功能由 ADAS（高级驾驶辅助系统）向 ADS（自动驾驶系统）发展的过程中，貌似“风光无限”的功能安全（IS026262）已经渐露窘色。

作为一名汽车行业系统安全从业者,在参与众多的功能安全开发项目的过程中,既深深的体会到了功能安全(IS026262)在保证 ADAS 系统安全中的作用和价值，也同时感受到了功能安全在ADS系统安全中的不足和无力感,甚至有时稍显尴尬。本文从自动驾驶功能安全与预期功能安全的角度出发,浅谈两者的区别,两者在智能辅助驾驶领域的主要价值体现,预期功能安全的开发流程以及如何通过预期功能安全的开展发挥安全把关者的重要角色。

02

从 ISO26262 角度看待智能辅助驾驶领域

如下图为SAE Level->Leve1 的分级定义，具体定义及说明可以参考相关标准的详细描述，此处仅作一般性解读。

从IS026262的角度来理解 SAE 的分级,区别仅仅在于驾驶安全责任的归属不同:

• 低等级自动驾驶级别(SAE Level1/Level2)功能的驾驶安全主体为驾驶员,也称之为辅助驾驶汽车,如ACC, LCC, NP等

•高等级自动驾驶(SAE Level3Level4Leve15)功能的驾驶安全主体为系统，也称之为自动驾驶汽车,如TJP, AVP, Robotaxi等

从功能安全设计的角度，两者区别不大。功能安全开发的目的就是避免电子电器系统功能异常(失效)引起不合理的风险而对驾驶员或者其他交通参与者造成危害。其中的电子电器系统功能异常（失效）可以分为系统性失效（原因：人一定会犯错）和随机硬件失效（原因：硬件一定会坏)。简而言之，功能安全聚焦解决系统出现故障后该怎么做，功能安全并不关注系统标称性能的表现及具体影响。

具体展开来看：

• 对于低等级自动驾驶功能,一旦检测到系统出现影响安全驾驶的故障,系统只需要保证能够及时的向驾驶员报告,并且后续的行为全部由驾驶员负责,厂家无责。

•对于高等级自动驾驶,一旦检测到系统出现影响安全驾驶的故障,系统自身需要主动介入并采取最佳的方式来避免发生事故,而驾驶员在这个过程中是可以完全不需要接管的，厂家有责。

T公司的NP (智能导航辅助驾驶)功能,在路况良好时,系统表现正常时,功能表现从表面上来看可以媲美“无人驾驶”。但是在各种非正常情况出现时,如系统故障出现时,驾驶员必须及时介入才有可能避免潜在的事故发生。对于这种安全降级的行为,驾驶员很难说能够对NP系统做到完全放心,无法取得合理的安全,安心和舒心感。

而如何确保安全,即在保证系统故障后还能继续运行到安全状态(如安全停车),核心的逻辑就是采取“冗余设计”。

在这里,冗余设计的逻辑比较容易理解,即在已知系统会发生随机失效且无法预测发生时机的情况下,通过另外一套冗余系统来提升安全性。比如在SAE L4 等级的产品安全架构中的Active主控制器和Fallback冗余控制器,两套独立的车端电源供电系统,两套制动能力一致的刹车系统等等,都是上述“冗余设计”思想的具体表现。采用上述设计思路,就可以保证一旦关键控制器(如制动,转向等)在故障后备份系统仍能够及时切换,维持车辆继续运行到安全状态。

03

ISO26262 面临自动驾驶的尴尬之一：成本！成本！成本！

基于上述功能安全对智能辅助驾驶领域的分析,无论低等级还是高等级的自动驾驶,其功能安全开发的方法基本一致：

•场景危害分析,定义安全目标及安全等级ASIL

•基于安全目标和系统初始架构,进行安全设计,定义架构安全需求

•对功能安全设计及需求进行各层级的验证和确认

对于低等级自动驾驶和高等级自动驾驶,在step1的“场景危害分析,定义安全目标及安全等级ASIL”的过程中,后者因为无需驾驶员的车辆驾驶监控和控制,在HARA(危害分析和风险评估)分析中的可控性指标C值会上升,因而安全目标的ASIL等级会提升,比如QM提升到ASILB,或者ASIL B提升到ASIL D。由此导致的“后果”便是开发成本的上升。比如上述提到的冗余的制动系统,在L4等级的自动驾驶功能中,需要两个系统都需要满足ASILD的制动需求,以此来保证中/高速场景下,主制动系统故障时,备用制动系统依然可以正常响应控制器的刹车请求,保证无驾驶员参与情况下的“本车道安全停车” (安全状态)或者“靠边停车”（安全状态）。

由上述分析可知,自动驾驶功能安全性的基本能力保证需要如此高的成本提升要求。汽车作为一件大宗商品,永远无法回避的是成本诉求,而功能安全对此是天然的troublemaker(麻烦制造者) ,也是某些场景下,功能安全无法很好在企业落地的原因之一。

而上述“困境”的破局之道,便是在合理的成本约束下,取得功能安全开发成本与收益比能够被接受的水平,这也是功能安全从业者要不断去思考的问题。

04

ISO26262面临自动驾驶的尴尬之二:高成本的功能安全设计依然无法保证产品安全

人命大于天,企业也会把“安全第一”融入到自己的产品设计中去并花费适当的成本来换取自动驾驶功能的安全性。毕竟,自动驾驶开发的初衷就是为了解决人类驾驶的不安全问题。

然而,通过下面公开的T公司的例子,可以很清楚的说明上述的高成本投入不见得会取得良好效果,即系统依然无法保证足够安全。

上述图片显示，T公司的智能辅助驾驶系统在初入中国时，把中国特色的幸运红绸识别为了路障。

在出现上述的“错误”后,系统如果按照预先的功能逻辑,势必会做出某种“不合理”的响应,最终影响到驾驶的安全性。但是上述行为的发生,并没有出现ISO26262所覆盖范围的任何系统失效,既没有出现软件错误,也没有发生硬件随机失效。分析下来,这里出现“错误”的原因不是传感器故障导致,而是传感器本身的功能局限和算法深度学习不够。

类似的案例其实也可以发生在其他类型的传感器上,比如智能辅助驾驶系统常用到的毫米波雷达和摄像头。对于毫米波雷达来说，由于其采集数据的多普勒效应原理，造成其对静态物体的识别性能不佳,且无法分辨物体的高度信息,这种性能的问题会导致车辆漏识别或者误识别,表现在驾驶行为上就会触发某种危险驾驶动作,造成潜在的安全事故风险。对于摄像头来说,由于摄像头的“被动”识别原理,在雾天或者光线不足的情况下,探测度都会降低,因为在某些情况下会因为无法正确识别物体而导致系统做出错误的驾驶动作,引起交通事故。

上述问题总结下, ISO26262功能安全可以解决电子电器故障导致功能异常而引起的不合理危害。但是对于传感器功能受限,或者软件的算法能力不足,都已经超出了功能安全的范畴。

对于上述场景下ISO26262面临的问题和局限性,在自动驾驶功能不断演进的过程中,功能安全的不足会被继续放大,也是继续尴尬下去。破解之策,便是引入当前自动驾驶行业比较热门的研究领域:预期功能安全(ISO21448)。

05

ISO21448预期功能安全的价值及应用

针对上述ISO26262的不足之处,业内目前引入了预期功能安全SOTIF(Safety of Int-endedFunctionality)来加强。作为对比,预期功能安全强调的是避免因为预期的功能表现局限或驾驶员误用而导致不合理的风险。

同时,预期功能安全的诞生正是伴随着智能驾驶发展而来的。具体到智能驾驶的技术架构上，可以将定义中的“功能表现局限”阐述在如下方面：

•传感器感知局限导致场景识别错误

•算法能力限制导致决策错误

•执行器执行性能不足,与预期目标的偏离

•驾驶员误用或滥用

不同于传统功能安全以失效及其传播为主的安全设计理念,预期功能安全从系统的功能局限性出发,考虑特定场景下该局限性引起的安全问题

预期功能安全标准ISO21448标准尚未正式颁布,详细内容可参考草稿版本,这里不做详细展开。如下通过两个示例来说明预期功能安全的应用及开发流程:

NP预期功能安全设计典型案例-ULC超越慢车变道

系统实时监测前方目标速度，在前车速度低于本车速度一定量且旁车道车辆速度较高时,自动控制本车变道至车速较高车道,提升本车通行效率。

预期功能安全设计：

•功能定义:当前车车速持续低于本车车速80%,且时间超过10s后,本车开始规划变道,选择目标车道，左侧优先；初始架构为 5R+1V

• SOTIF 危害分析：侧后方有异形车辆驶来，角雷达漏检，不满足变道条件，车辆自主换道存在碰撞风险，S>O；C>O，该风险是 SOTIF 相关风险。

•缺陷识别和触发条件识别:角雷达对异形车辆识别的漏检率偏高,角雷达分辨率较低,“点云”稀疏,触发条件是异形车辆。

•功能改进：

通过对上述方案从安全，成本，安心的角度综合评定，选择方案1作为最终的优化方案。

后续在优化方案1实施后,通过对方案的验证及确认工作,最终完成功能发布前的安全评价，形成有效闭环。

同样的,在功能发布之后,在实际的用户使用场景下,还需要持续监控功能是否有出现新的异常或者功能不足,此时需要分析原因并迭代制定优化措施。

NP预期功能安全设计典型案例-语音变道

相比上述的系统自主决策的ULC超越慢车主动变道,语音变道提供了驾驶员主动语音发起变道的方式，提升了驾驶体验。

预期功能安全设计:

•功能定义:当前车道的临车道满足变道条件,收到驾驶员的合法语音变道指令后,系统发起变道,本车开始规划变道,选择目标车道,左侧优先；初始架构为5R+1V

• SOTIF 危害分析: 语音变道由驾驶员主动发起,驾驶员需要对变道时机和变道过程中的各种意外情况保持时刻关注,以确保安全,即非驾驶员侧的其他车辆乘员发起的语音变道是不被允许的。如果驾驶员语音检测出现漏检,将其他乘员的语音变道指令识别为有效指令,在不满足变道条件时,车辆自主换道存在碰撞风险,S>0; C>0,该风险是SOTIF相关风险。

•缺陷识别和触发条件识别:智能语音系统对车辆非驾驶员的其他车辆成员语音的识别漏检率偏高,触发条件是其他车辆乘员语音变道请求。

•功能改进：

通过对上述方案从安全,成本,安心的角度综合评定,选择方案1作为最终的优化方案。

功能安全与预期功能安全，做智能辅助驾驶产品安全把关者。我想，这应该是当前阶段，系统安全从业者所应该具备的担当和企业责任定位。

以上NP预期功能安全的简单示例说明了随着自动驾驶功能的发展,系统日益面临更多的由于系统功能局限性所引起的安全隐患。这是一项巨大的系统工程,需要确保在真实的用户场景下面临的各种“已知不安全”和“未知不安全”的危害,提供给用户真正敢用,愿意用，好用的自动驾驶产品。

基于对自动驾驶产品安全的分析和示例说明,可以看出在通过功能安全手段保证了产品基础安全的前提下,需要更多的从产品和功能的深刻理解和应用出发,识别智能辅助驾驶领域占据绝大部分比例的“已知不安全”和“未知不安全”的SOTIF问题。从而真正做到从企业实际业务出发,从消费者的安全出发,做一个合格的安全把关者的重要角色。

NP: Navigation Pilot,目前自动驾驶发展阶段，竞争较为激烈，也较为清晰的典型L2+产品的落地场景产品。国内新势力汽车及T公司，均有类似公司推出，其性能有所差异，但整体功能实现和预期效果基本一致。

近期热门

【线下沙龙】第十三期“智能驾驶安全”报名进行中

2023 SASETECH年度峰会6月7日 上海举办

汽车安全系列课程 预期功能安全入门8讲

SAE&磐时汽车【功能安全】系列培训报名进行中

往 期 精 选

SASETECH是国内首个由汽车安全专家发起组建的技术社区，致力于为汽车安全的从业者提供交流、学习、合作的中立性平台。

SASETECH

扫码联系管理员加入交流群→