关闭

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

发表于:2023-9-08 09:30

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:茉莉雨    来源:焉知

  “ 为了解决智能驾驶系统的能力边界和驾驶员对系统过度信任的问题,诞生了预期功能安全。”
  所谓预期功能安全,英?为Safety Of The Intended Functionality,取?字母缩写——SOTIF,对应大家平常所说的标准为ISO21448。
  一、为什么要有预期功能安全?
  说道预期功能安全,大家的第一个问题就是:为什么要有预期功能安全呢?或者它存在的价值是什么?
  人机共驾的隐忧
  几年前有个观点非常流行——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)。
  预期功能安全其实以就一直在围绕这两件事展开的。后面我们会细讲。
  二、预期功能安全的本质是什么?
  上面提到的预期功能安全的意义和价值,是从问题的角度来讲的——SOTIF到底解决了什么问题。
  那么,从另一个角度来思考,预期功能安全的本质到底是什么呢?为什么会出现呢?
  ISO21448中提到了一个三圈模型,能让我们更好地理解SOTIF。三圈模型把期望行为、规定行为和实际行为的范围画3个圈来说明,每个圆圈代表某个行为的一个方面。
三圈行为模型 
  这三种行为分别代表的含义为:
  期望行为:不考虑任何技术限制,用户对自动驾驶系统的期望行为是理想的行为,代表了100%的场景适用性和安全性,反映了用户和社会对系统行为的期望,比如对AEB的期望行为应该是零误触发、零漏触发。
  规定行为:规定行为是考虑了现实世界的约束后的期望行为,也就是开发人员对系统的定义,具体约束可以是法律、技术、成本、用户体验等。
  实际行为:即系统实际所表现出来的真实行为。
  很明显这三个圆圈是不重合的,也就是用户对系统的期望、开发人员对系统的定义以及系统的实际表现是有差异的。
  可能大多数情况下,都不会触发这3个圆圈中的差异部分,可一旦这些差异被某些场景中的特定条件触发,就可能会发生安全事件。
  这里的触发条件既包括系统功能的局限性,也包括合理可预见的误用。
  而预期功能安全其实就是致力于将这三个圈的重叠率做的越来越高,从而降低发生预期不一致的几率。
  从这个角度来说,正确理解系统功能及其行为的局限性(包括人机交互),对于确保安全至关重要。
  三、预期功能安全和功能安全是什么关系?
  在学习预期功能安全时,经常会有个疑问:预期功能安全和功能安全到底是什么关系?
  这是个好问题。 
  功能安全针对的是电子电器的系统性失效和硬件随机失效带来的安全问题。
  简单来讲,功能安全更关注系统是否能够“正常”地按照设计要求运行。
  这种分析对于传统汽车电气系统或许是“充分且必要”的,因为其性能要求和测试规范等都是非常明确和成熟的,行业里也有一定之规,不大有歧义和风险。
  所以,在功能安全的思维框架下,没有人质疑系统的设计是否“合理”。
  但是对于步入“无人区”的高阶智能驾驶来说,考虑功能安全,仍然是“必要的”,但是就未必“充分”了。
  很多智能驾驶的功能定义、人机职责边界和控制权的交接,行业内并没有统一的做法,用户也没有清晰的认知,基本上属于“公说公有理,婆说婆有理”的“自说自话”阶段。
  这时候,在做功能安全分析中的智能驾驶系统的设计要求定义时,其实开发人员也心虚,心里打鼓:
  “这样的设计要求,真的合理吗?”
  “是否功能安全的要求全部满足,就能保证系统不会出问题呢?”
  如果开发人员面对这样的灵魂拷问,或许良心真的会痛(开个玩笑)。
  在预期功能安全的思考框架下,开发人员在定义系统时,就需要发动一下善于思考的脑袋,在接到需求时,先不要思考怎么做,而是要——先问对不对,再问怎么做。
  也就是说,需要工程师使用批判性思维思考,边做边思考:
  这样设计真的完善嘛?
  有没有考虑xx工况呢?
  如果xxx发生怎么办呢?
  这也就是功能安全和预期功能安全最根本的差异所在。
  换个角度可能更好理解。
  在一个大公司里,功能安全的执行就像是众多“打工人”在做事。打工人要做的是按部就班的完成自己职责范围内的事,接到管理层的指令后不折不扣的去完成,这也是体现团队“执行力”的部分。
  执行力当然很重要,如果身处于成熟的传统行业,这样做或许大概率是没问题的,行业变化没那么快,信息不对称也不严重,这种情况下管理层做的决策偏差不会很大。
  可是,当处于快速发展的行业时,市场瞬息万变,管理层在做决策时很可能没有掌握足够的信息,或者决策时某个重要的依赖项今非昔比了,以前的决策逻辑就不再成立了。
  如果执行者只带着“打工人思维”,可能方向会跑偏,项目会因此失败。
  这时就需要带着“CEO思维”,站在全局的高度,去思考当前执行的策略是否正确,是否有更好、效率更高的方式去完成目标,以便及时纠正和完善公司的战略发展方向。
  “打工人思维”和“CEO思维”的区别,就像是功能安全和预期功能安全的区别。
  确保没有故障的功能安全是最基础的,是预期功能安全的前提,而预期功能安全则致力于思考如何让系统更加完善,对功能安全是一种良好的补充(ISO21448语)。
功能安全和预期功能安全的关系 
  要想区分功能安全、预期功能安全和网络安全各解决了什么问题,可以参考下图所示。
不同危险来源适用的安全标准
(出自ISO21448,经过翻译调整)
  四、预期功能安全都分析了些啥?
  预期功能安全的分析主要涉及两个方面: 
  一方面是功能不足(Functional insufficiencies)。
  就好比你甩给你的员工5块钱:“去,帮我买包华子,零钱不用找了”,这就有点过于高估员工能力了,员工内心OS:“臣妾做不到啊”。
  功能不足可以体现在自动驾驶系统的各个部分,主要体现在: 
  感知端:如传感器本身的性能局限(如摄像头在雨雾天气下性能不良)导致部分场景不能覆盖或者功能受限。
  规划端:如智能驾驶系统还不能应对复杂的交通场景,如十字路口无保护左转、窄路人车混行等。
  另一方面是人为误用(Misuse,ISO21448称之为合理可预见的人员误操作)。主要包括以下两方面:
  1 人机信息传达方式不完善:
  人为因素对系统的影响,特别是与人机交互界面的接口;
  驾驶员对系统能力和限制的理解,以及驾驶员的责任;
  驾驶员理解和应对警告和警报的能力。(属于信息传达失误,你说往东,他以为往西,你说城门楼子,他以为是胯骨轴子。)
  2 没有正确的监控驾驶员状态:
  在需要驾驶员参与的环节中,驾驶员状态不好,不具备接管条件,因为驾驶员有过度信任系统的倾向。
  对驾驶员的检测,包括检测驾驶员没有将手放在方向盘上(脱手检测),视线有没有偏离前方行驶区域(脱眼检测),就像老板时刻盯着员工有没有划水一样。
  五、预期功能安全的法规和标准盘点
  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月份发布了征求意见稿。本文中也会引用征求意见稿部分的内容。
  六、预期功能安全的应用
  当前预期功能安全更多停留在理念和方法论层次,实际落地应用的具体实操业内尚没有达成一致,不过认证机构倒是很积极做起了布道者,也如火如荼地做起了发证业务(毕竟赚钱是第一位的),一些企业(如地平线、长城等)也纷纷拿到了ISO21448的流程认证(并高调做了宣传)。 
  整体来说,由于SOTIF提出比较晚,还不是很成熟,距离应用落地还有一段距离。
  不过很多人认为,预期功能安全是L3的必要不充分条件,只有预期功能安全成熟了,L3才可能真的普及。
  L3不等人啊,所以需要各位在ISO21448的基础上继续创新。
  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号