本文来源：谈思实验室
先回顾一下功能安全标准（ISO 26262-1:2018(E),Road vehicles — Functional safety）中对功能安全一词的定义：
(资料图片)
Functional Safety ：absence of unreasonable risk due to hazards caused by malfunctioning behaviour of E/E systems 。即，功能安全： 不存在由于电子电气系统的异常行为引起的危害所带来的不合理的风险 。
也就是说，功能安全解决的是电子电气系统的 异常行为 所 引起的危害 和带来的。
那么，如果电子电气系统不出现异常就没有危害和风险了吗？
答案显然是否定的！因为功能安全只能应对电子电气系统内部的问题，而对于那些不属于电子电气系统内部的异常怎么办？风险，既可能来自于系统内部，也可能来自外部，尤其是对于自动驾驶系统而言更是如此。
先以一个自动驾驶最基本的功能为例——交通标识
理想中的道路交通标识都应该是下面这么规规矩矩的
（规规矩矩）
而实际上却可能是下面这样的……
（插画家转行系列）
（柱子不够用系列）
或者是前方一辆车中拉着一个看似标准的标识牌……
（拐了拐了啊，拐了拐了啊~）
如果你是自动驾驶的DRE、系统工程师或算法工程师，对于以上系列你作何感想呢？
艾玛，为啥都不按套路出牌？
不过，这确实就是现实，残酷的现实，充满着惊喜（悚）的现实……
让我们再看看下面这条著名的路，这也是算法工程师的噩梦了吧，激光雷达看到了真像，可是人眼视觉上看到的却是立体的路面。一瞬间，你会不会花容失色，两只手不知道是先揉眼睛，还是先抓方向盘呢？
自动驾驶标准中有一个词是： ODD， Operational Design Domain（运行设计域） ，指自动驾驶系统运作的前提条件及适用范围。只有当全部条件都满足的时候该自动驾驶才能保证正常运作。相应的，任何一个条件的欠缺，都会导致该系统出现故障。
从不同维度分解并举例子，梳理一下可以导致风险的风险源：
【1】【基建-道路标识】
前面所列举的交通标识标准化就是一个基本的前提条件，否则自动驾驶系统怎么判断当前道路的情况呢？仅靠相信地图中的信息吗？当然不行，因为地图不能保证实时更新，而且，还要考虑道路上随时可能出现的施工……
【2】【设备技术能力限制，及开发者能力限制】
尽管现在的各种自动驾驶车辆都安装了众多的摄像头、毫米波雷达、激光雷达、超声波雷达和V2X设备，然而，这些传感器都有各种使用限制。比如：摄像头有分辨率和动态响应范围限制，毫米波雷达易受金属物品影响，激光雷达有分辨率和探测距离的限制等等，这些自身能力的限制大部分都是由于技术发展水平限制的。在设计自动驾驶系统ODD的时候，绝大部分都是设计师和工程师应该知道的，但也无法保证全部人员的认知高度和能力水平。
【3】【突发情况防不胜防】
理论上，一个自动驾驶车辆在ODD范围内运行是安全的。但是，当你在高速公路上尽情驰骋的时候，突然出现了下面情况怎么办：
1. 前方的车辆突然扬起了很大的灰尘
2. 下大雨或出现了大雾、沙尘暴
3. 泥巴或者其他的东西把摄像头或者雷达遮住了
4. ……
以上几种情况都不属于系统本身的故障，而是外界环境造成的，但结果却与系统本身的故障非常相似，都是系统无法执行应该具有的功能了。
【4】【自己的锅，含泪背？】
1.当你的车辆处于自动驾驶状态，你（对！说的就是你）在发微信……此时车辆退出了自动驾驶，发消息让你接管，但是你在发消息，注意力都在社交上嘛~
2.你（对！还是你）不小心触发了某个自动驾驶功能，而自己却不知道，于是车辆开始自己驾驶~
3.在本不应该使用自动驾驶功能的场景下，你（哎，咋又是你）开启了自动驾驶功能~
上面的三种典型的情况，责任人（背锅侠）看起来好像都是驾驶员，可是对于普通的你（想哭……）来说，你能搞清楚座驾的ODD吗？？？作为系统的设计者是不是应该有责任避免上述情况发生呢？
从以上分析可以看到，为了保证所有的道路交通参与者的安全，仅仅遵守了功能安全标准的要求是远远不够的，对于系统的能力限制和驾驶员的误用等情况也需要在设计时做出充分的考量。 预期功能安全标准（ISO 21448）就是为了弥补功能安全标准（ISO 26262）这个方面的不足而出现的 。
预期功能安全标准ISO 21448的全名是Road vehicles — Safety of the intended functionality，简称SOTIF。当前的最新版本为2022版。其对于预期功能安全的定义如下：
absence of unreasonable risk due to hazards (3.11) resulting from functional insufficiencies of the intended functionality (3.14) or its implementation 。
即：不存在由于预期功能或其实现过程中的功能不足而产生的危害所带来的不合理风险。
初次看到预期功能安全这个名字的时候大家都会有点困惑，“功能”两个字前面加上“预期”是啥意思呢？我也是悟了很久才想明白究竟啥是所谓的“预期功能”。英语中的Intended一词指的是：计划的、想要的、预期的，也就是你所希望实现或达到的。在与“functionality”这个词合在一起后就表示： 你希望系统能够实现的功能 。
例如：
1. 我们系统摄像头能够快速地看清所有出现在范围内的物体的细节，并准确地转成数字信号。但摄像头的分辨率和识别速度等总会有限制。于是，我们所预期的摄像头的功能就没有完全实现。
2. 驾驶员预期车辆应该一直可以保持自动驾驶状态，但是自动驾驶系统却退出了。
3. 系统设计的规格书（specification）中没有写完整，导致系统的最终表现与设计预期有差距。
上述的三个例子都是实际情况与预期不符合的情形。
（理想照进现实）
对于消费者而言，SOTIF的出现绝对是福音。否则，自动驾驶系统发疯了的时候，消费者只能自求多福了。因为设计系统者的傍身之语是“用户没有按照规定使用系统”。作为小白消费者的嘴替，我们可以理直气壮地的反驳：你没有符合SOTIF的标准，这个锅必须你来背！
（话说回来，由于自动驾驶系统仍然处于发展过程中，而且所有的系统总有能力的边界和使用的限制，我们最好还是珍爱自己的生命，老老实实的看说明书和专心开车最为稳妥。）
SOTIF的分析过程 如下图所示，此处就不赘述了，感兴趣的朋友可以去ISO21448标准中仔细研读。
下图是 SOTIF中最为著名的一张方法论的图 ，解释了SOTIF所有工作中的最为核心的思想。SOTIF将所有可能对系统产生影响的场景分为了两个维度共四个象限，分别是：
象限1 -已知安全的场景
象限2 -已知不安全的场景
象限3 -未知的不安全的场景
象限4 -未知的安全的场景
所有SOTIF的工作就是尽量扩大已知的场景，并减少未知的场景，尤其是 将未知的不安全场景 （象限3）尽可能缩小，从而减少系统可能带来的危害和风险。
功能安全（ISO26262）中应对的情况大都属于 已知的不安全场景 （象限2）。因此，SOTIF应该是更为广泛的分析了影响系统安全的各种因素。但因为功能安全早已经深入人心，所以ISO21448就将ISO26262中没有考虑到的情形加以补充完善，且仍然沿用了很多ISO26262中的方法和概念，如HARA、FSC等。其整体流程也大同小异，只是分析的范围有所不同而已。
下表对 SOTIF与功能安全的边界 做一个梳理和总结
最后，又到了分享实践中关于SOITF的一些感受的环节~~~
1. 做好SOTIF的工作首先需要深刻理解 功能安全（ISO26262) ，如果只看21448可能会一头雾水。
2. 由于SOTIF的工作需要涉及到各个传感器、执行器和控制器的细节能力，因此需要大量的 系统内部的专业知识 ，否则可能会变成空谈方法论而无法落地。
3. 对于用户误用等的场景和危害分析，需要对整车的“人机交互”知识非常了解，而且也要有大量的人机工程学理论知识。这些肯定是无法通过熟悉SOTIF标准来解决的。最好的方式是让 “人机交互UX”设计工程师 也参与其中，甚至要了解SOTIF。
4. 现在的系统安全已经不只是功能安全和预期功能安全这么简单了， 网络安全 也深刻的影响着系统的安全。无论你车内系统的逻辑设计的多么完备，如果被黑客控制了，就没啥是安全的了。
5. 做一名汽车工程师是越来越难了！%&*@……
- End -
免责声明：
凡本公众号注明“来源：XXX（非智车科技）”的作品，均转载自其它媒体，转载目的在于传递和分享更多信息，并不代表本平台赞同其观点和对其真实性负责，版权归原作者所有，如有侵权请联系我们删除。
