预期功能安全系列之一:预期功能安全究竟是什么?

注:本文为预期功能安全系列的第一篇,后面还有2篇,敬请期待。

“ 为了解决智能驾驶系统的能力边界和驾驶员对系统过度信任的问题,诞生了预期功能安全。”

所谓预期功能安全,英⽂为Safety Of The Intended Functionality,取⾸字母缩写——SOTIF,对应大家平常所说的标准为ISO21448。

01 为什么要有预期功能安全?

说到预期功能安全,大家的第一个问题就是:为什么要有预期功能安全呢?或者它存在的价值是什么?

人机共驾的隐忧

几年前有个观点非常流行——L3级自动驾驶是伪命题。

所谓L3,即为有条件的自动驾驶,正常工况下自动驾驶系统可以正常行驶,但是发生突发情况时,系统会退出并需要驾驶员接管,也就是所谓的“人机共驾”。

而在人机共驾模式下,驾驶权的交接很容易出现问题,尤其是在危险情况下,系统发现搞不定,可能就直接“甩锅”退出了,而此时驾驶员很可能来不及做出反应,从而酿成悲剧——这种体验是非常糟糕,也非常反人性。

这个说法是有道理的,不过并不仅是L3才存在这样的问题。

事实上,只要有人机共驾,就有这样的风险。

虽然国内L3还没有“合法”(欧盟已合法),不过随着更高级别的L2+智能驾驶功能(NOA)的发展,人机共驾也开始慢慢普及。

与独立功能的L2不同,L2+其实是多个L2功能的集合,比如高速NOA,其实就是ACC/LKA/LCC/TJA/HWA等功能的集合。而且从L2+到L3,自动驾驶等级越高,驾驶员和系统之间职责重叠就越多。

为了用户体验,系统自然不能遇到搞不定的情况就“一退了之”,要给驾驶员留出足够的反应时间。

要做到这一点,并不容易。

一方面,系统要能够适应不同场景,比如晴雨雪雾等各种天气、坑洼泥泞等各种道路及拥堵、人车混行等复杂场景;

另一方面,系统还要能清晰得知道自己的“能力边界”,即不仅要知道自己能够处理什么场景,还要知道不能够处理什么场景——这样遇到“搞不定”的场景时,才能做出预判,给驾驶员留出足够的接管时间。

比如之前发生过多起特斯拉因不能正确识别翻倒的白色卡车,径直撞上去的悲剧,小鹏也发生过多起不能识别静态障碍物而引起的交通事故,这其实就是不知道自己的能力边界导致的。

驾驶员的“过度信任”

另外一个问题是驾驶员对系统“过度信任”的问题。

随着自动驾驶系统功能越来越强大,驾驶员也会越来越觉得系统是“可以信任”的,从而主观和潜意识里,都倾向于信任系统。

无论用户手册上再怎么“危言耸听”都无济于事,这是人性,所以需要对驾驶员状态进行时刻监管,以确保驾驶员在需要的时候能够及时接管(fall back)。

这种事情也很常见,经常看到新闻中报道驾驶员一边开着高速领航辅助(NOA),一边玩手机,甚至跑到后排去睡觉,因此导致了很多悲剧。


现在NOA等L2+智驾功能,其实一定程度上已经具备L3的能力,但是仍打着L2的“幌子”(出任何事故都是驾驶员的责任),像极了一个渣男,做了所有该做的事,但是又不想承担任何责任。

为了报复渣男,哦不对,为了解决上面提到的系统能力边界和驾驶员过度信任的问题,于是就诞生了预期功能安全(SOTIF)。

预期功能安全其实以就一直在围绕这两件事展开的。后面我们会细讲。

02 预期功能安全的本质是什么?

上面提到的预期功能安全的意义和价值,是从问题的角度来讲的——SOTIF到底解决了什么问题。

那么,从另一个角度来思考,预期功能安全的本质到底是什么呢?为什么会出现呢?

ISO21448中提到了一个三圈模型,能让我们更好地理解SOTIF。三圈模型把期望行为、规定行为和实际行为的范围画3个圈来说明,每个圆圈代表某个行为的一个方面。

​三圈行为模型

这三种行为分别代表的含义为:

期望行为:不考虑任何技术限制,用户对自动驾驶系统的期望行为是理想的行为,代表了100%的场景适用性和安全性,反映了用户和社会对系统行为的期望,比如对AEB的期望行为应该是零误触发、零漏触发。

规定行为:规定行为是考虑了现实世界的约束后的期望行为,也就是开发人员对系统的定义,具体约束可以是法律、技术、成本、用户体验等。

实际行为:即系统实际所表现出来的真实行为。

很明显这三个圆圈是不重合的,也就是用户对系统的期望、开发人员对系统的定义以及系统的实际表现是有差异的。可能大多数情况下,都不会触发这3个圆圈中的差异部分,可一旦这些差异被某些场景中的特定条件触发,就可能会发生安全事件。这里的触发条件既包括系统功能的局限性,也包括合理可预见的误用。而预期功能安全其实就是致力于将这三个圈的重叠率做的越来越高,从而降低发生预期不一致的几率。从这个角度来说,正确理解系统功能及其行为的局限性(包括人机交互),对于确保安全至关重要。

03 预期功能安全和功能安全是什么关系?

在学习预期功能安全时,经常会有个疑问:预期功能安全和功能安全到底是什么关系?这是个好问题。

功能安全针对的是电子电器的系统性失效和硬件随机失效带来的安全问题。简单来讲,功能安全更关注系统是否能够“正常”地按照设计要求运行。这种分析对于传统汽车电气系统或许是“充分且必要”的,因为其性能要求和测试规范等都是非常明确和成熟的,行业里也有一定之规,不大有歧义和风险。所以,在功能安全的思维框架下,没有人质疑系统的设计是否“合理”。但是对于步入“无人区”的高阶智能驾驶来说,考虑功能安全,仍然是“必要的”,但是就未必“充分”了。很多智能驾驶的功能定义、人机职责边界和控制权的交接,行业内并没有统一的做法,用户也没有清晰的认知,基本上属于“公说公有理,婆说婆有理”的“自说自话”阶段。这时候,在做功能安全分析中的智能驾驶系统的设计要求定义时,其实开发人员也心虚,心里打鼓:

  • “这样的设计要求,真的合理吗?”

  • “是否功能安全的要求全部满足,就能保证系统不会出问题呢?”

如果开发人员面对这样的灵魂拷问,或许良心真的会痛(开个玩笑)。在预期功能安全的思考框架下,开发人员在定义系统时,就需要发动一下善于思考的脑袋,在接到需求时,先不要思考怎么做,而是要——先问对不对,再问怎么做。也就是说,需要工程师使用批判性思维思考,边做边思考:

  • 这样设计真的完善嘛?

  • 有没有考虑xx工况呢?

  • 如果xxx发生怎么办呢?

这也就是功能安全和预期功能安全最根本的差异所在。换个角度可能更好理解。在一个大公司里,功能安全的执行就像是众多“打工人”在做事。打工人要做的是按部就班的完成自己职责范围内的事,接到管理层的指令后不折不扣的去完成,这也是体现团队“执行力”的部分。执行力当然很重要,如果身处于成熟的传统行业,这样做或许大概率是没问题的,行业变化没那么快,信息不对称也不严重,这种情况下管理层做的决策偏差不会很大。可是,当处于快速发展的行业时,市场瞬息万变,管理层在做决策时很可能没有掌握足够的信息,或者决策时某个重要的依赖项今非昔比了,以前的决策逻辑就不再成立了。如果执行者只带着“打工人思维”,可能方向会跑偏,项目会因此失败。这时就需要带着“CEO思维”,站在全局的高度,去思考当前执行的策略是否正确,是否有更好、效率更高的方式去完成目标,以便及时纠正和完善公司的战略发展方向。“打工人思维”和“CEO思维”的区别,就像是功能安全和预期功能安全的区别。确保没有故障的功能安全是最基础的,是预期功能安全的前提,而预期功能安全则致力于思考如何让系统更加完善,对功能安全是一种良好的补充(ISO21448语)。

功能安全和预期功能安全的关系

要想区分功能安全、预期功能安全和网络安全各解决了什么问题,可以参考下图所示。

不同危险来源适用的安全标准(出自ISO21448,经过翻译调整)

04 预期功能安全都分析了些啥?

预期功能安全的分析主要涉及两个方面:一方面是功能不足(Functional insufficiencies)。就好比你甩给你的员工5块钱:“去,帮我买包华子,零钱不用找了”,这就有点过于高估员工能力了,员工内心OS:“臣妾做不到啊”。功能不足可以体现在自动驾驶系统的各个部分,主要体现在:

  • 感知端:如传感器本身的性能局限(如摄像头在雨雾天气下性能不良)导致部分场景不能覆盖或者功能受限。

  • 规划端:如智能驾驶系统还不能应对复杂的交通场景,如十字路口无保护左转、窄路人车混行等。

另一方面是人为误用(Misuse,ISO21448称之为合理可预见的人员误操作)。主要包括以下两方面:

1. 人机信息传达方式不完善:

  • 人为因素对系统的影响,特别是与人机交互界面的接口;

  • 驾驶员对系统能力和限制的理解,以及驾驶员的责任;

  • 驾驶员理解和应对警告和警报的能力。(属于信息传达失误,你说往东,他以为往西,你说城门楼子,他以为是胯骨轴子。)

2. 没有正确的监控驾驶员状态:

  • 在需要驾驶员参与的环节中,驾驶员状态不好,不具备接管条件,因为驾驶员有过度信任系统的倾向。

  • 对驾驶员的检测,包括检测驾驶员没有将手放在方向盘上(脱手检测),视线有没有偏离前方行驶区域(脱眼检测),就像老板时刻盯着员工有没有划水一样。

05 预期功能安全的法规和标准盘点

  • ISO21448

提到预期功能安全,最具影响力的、最权威的自然是ISO 21448,其地位和功能安全领域的ISO 26262差不多。ISO 21448标准于2016年启动,自2019年以来作为规范公开发布,并于2022年6月最终发布。ISO 21448详细介绍了SOTIF的背景、流程和操作方法论和实践案例,是学习SOTIF的必看资料。后面在介绍SOTIF时主要以ISO21448为主。

  • UN-R157 ALKS:

L3对SOTIF的要求肯定要比L2要高得多,而欧洲在法规制定方面一直走在前列。在2021年正式推出了第一部L3法规:UN-R157 ALKS- Automatic Lane Keeping Assistance System。当然,R157做为世界首部L3的正式法规,具有非常高的参考价值,但它也有局限性。首先,它只适用于一个L3功能ALKS,而对其他功能不涉及;其次,ALKS适用的是低速高速场景(封闭公路),法规第二版将把速度上限进一步提升到更符合一般高速场景的130 kph,并对变道(LCP)放松了限制,也更加符合实际工况。后面章节会重点讲解一下这个法规。

  • 国内:国标的起草

和功能安全GB/T 34590是ISO26262的中国落地版类似,中汽研也在牵头起草《道路车辆:预期功能安全》,也是推荐标准(GB/T),2022年4月份发布了征求意见稿。本文中也会引用征求意见稿部分的内容。

06 预期功能安全的应用

当前预期功能安全更多停留在理念和方法论层次,实际落地应用的具体实操业内尚没有达成一致,不过认证机构倒是很积极做起了布道者,也如火如荼地做起了发证业务(毕竟赚钱是第一位的),一些企业(如地平线、长城等)也纷纷拿到了ISO21448的流程认证(并高调做了宣传)。

整体来说,由于SOTIF提出比较晚,还不是很成熟,距离应用落地还有一段距离。不过很多人认为,预期功能安全是L3的必要不充分条件,只有预期功能安全成熟了,L3才可能真的普及。L3不等人啊,所以需要各位在ISO21448的基础上继续创新。

革命尚未成功,同志们继续努力啊。

  • 1
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
自动驾驶- 功能安全预期功能安全相互作用的挑战 ISO 26262 《道路车辆—功能安全》就如何预防由汽车电子电气系统产生故障导致的意外风险提供了指导 意见。但是,即使电子电气系统没出故障,因技术或系统定义缺陷也会造成安全隐患。 ADAS 开发人员一方面要解决车辆功能安全问题,一方面要考虑时下热议的“预期功能安全(SOTIF)”, 处境越发地艰难。目前为止,关于SOTIF 的指导文件并不多。不过,即将发行的ISO PAS 21448《道路车辆— 预期功能安全》文件或将填补这一空缺。 Automated Driving - Challenges in the Interplay between Functional Safety and Safety of the Intended Functionality Mirko Conrad Samoconsult GmbH ABSTRACT ISO 26262 "Road vehicles — Functional safety" provides guidance on how to avoid unreasonable risk due to hazards caused by malfunctioning behavior of automotive E/E systems. However, hazards can also been caused by these systems in the absence of any faults, i.e., resulting from technological shortcomings or shortcomings in their system definitions. Developers of ADAS are increasingly caught between addressing functional safety and the latter topic area, dubbed SOTIF (safety of the intended functionality). To date, there is only limited guidance on SOTIF, but ISO PAS 21448 "Road vehicles— Safety of the Intended Functionality", an upcoming Publicly Available Specification, might improve this situation.
### 回答1: 中国传统节日的种类非常丰富,每个节日都有自己独特的庆祝方式和意义。其中,春节是中国最重要的传统节日之一。春节是农历新年的开始,通常在每年的1月或2月之间,具体日期根据农历的变化而定。 春节是中国传统文化中最热闹、最喜庆的节日之一。它是家庭团聚的时刻,中国人会返乡和亲人共度佳节。在春节期间,家人之间会互相送礼、拜访亲友,并一起享用丰盛的年夜饭。 除了家庭聚会外,春节还有一系列独特的传统庆祝活动。其中最常见的是放鞭炮和观赏烟花。这些传统的庆祝方式象征着驱邪和迎福,也会吓跑恶灵,给新的一年带来吉祥和好运。 此外,春节期间还有丰富多样的庙会和花市。人们会逛庙会,观赏舞狮、舞龙等传统表演,并品尝各种美食。花市则是人们购买年花和装饰品的地方,有各式各样的鲜花和彩灯,为节日增添了热闹喜庆的气氛。 春节还有一项传统活动是贴春联和挂红灯笼。春联是用红纸写上吉祥的字和祝福的话语,贴在门上或墙壁上,以带来好运和吉祥。红灯笼则是用来照亮家门口,并象征着新的一年的希望和祝福。 总的来说,春节是中国人传承了数千年的传统节日,它代表着新年的开始和新的希望。无论身在何处,中国人都会通过各种方式庆祝这个重要的节日,并向亲友们表达祝福和美好的愿望。 ### 回答2: 软件测试是指对软件系统进行验证和验证的过程,旨在确保软件系统的质量和功能。它是软件开发生命周期中的重要环节,可以帮助开发人员发现和修复软件系统中的错误和缺陷,提高软件的可靠性和稳定性。 软件测试的目标是确定软件系统是否满足预期的需求和设计,并且能够在实际使用情况下正常运行。通过测试,可以识别和修复软件系统中的错误和缺陷,确保系统的正确性、健壮性和安全性。 软件测试包括多种测试方法和技术,如单元测试、集成测试、系统测试、性能测试等。通过这些测试方法,可以验证软件系统的各个部分和功能模块的功能、性能和稳定性。 软件测试的过程通常分为测试计划、测试设计、测试实施和测试评估几个阶段。在测试计划阶段,需要制定测试目标、测试方法和测试资源等。在测试设计阶段,需要定义测试用例和测试数据,以验证软件系统的各个方面。在测试实施阶段,需要执行测试用例并记录测试结果。在测试评估阶段,需要评估测试结果,并根据评估结果进行修复和优化。 软件测试是一项复杂和持续的工作,需要测试人员具备较高的技术和专业知识。他们需要熟悉软件开发过程和相关技术,并能够准确地识别和报告错误和缺陷。 总之,软件测试是确保软件系统质量的重要环节,通过验证和验证软件系统的功能和性能,可以提高软件的可靠性和稳定性,满足用户的需求和期望。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值