点击上方蓝字谈思实验室
获取更多汽车网络安全资讯
（插画家转行系列）
（柱子不够用系列）
或者是前方一辆车中拉着一个看似标准的标识牌……
（拐了拐了啊，拐了拐了啊~）
如果你是自动驾驶的DRE、系统工程师或算法工程师，对于以上系列你作何感想呢？
艾玛，为啥都不按套路出牌？
不过，这确实就是现实，残酷的现实，充满着惊喜（悚）的现实……
让我们再看看下面这条著名的路，这也是算法工程师的噩梦了吧，激光雷达看到了真像，可是人眼视觉上看到的却是立体的路面。一瞬间，你会不会花容失色，两只手不知道是先揉眼睛，还是先抓方向盘呢？
从不同维度分解并举例子，梳理一下可以导致风险的风险源：
【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. 做一名汽车工程师是越来越难了！%&*@……
WISS 2023 第四届世界物联网安全及数据安全治理峰会火热报名中 , 欢迎报名↓
来源：侯哥工作感悟
更多文章
会员权益: (点击可进入)谈思实验室VIP会员
END
微信入群
谈思实验室专注智能汽车信息安全、预期功能安全、自动驾驶、以太网等汽车创新技术，为汽车行业提供最优质的学习交流服务，并依托强大的产业及专家资源，致力于打造汽车产业一流高效的商务平台。
每年谈思实验室举办数十场线上线下品牌活动，拥有数十个智能汽车创新技术的精品专题社群，覆盖BMW、Daimler、PSA、Audi、Volvo、Nissan、广汽、一汽、上汽、蔚来等近百家国内国际领先的汽车厂商专家，已经服务上万名智能汽车行业上下游产业链从业者。专属社群有：信息安全、功能安全、自动驾驶、TARA、渗透测试、SOTIF、WP.29、以太网、物联网安全等，现专题社群仍然开放，入满即止。
扫描二维码添加微信，根据提示，可以进入有意向的专题交流群，享受最新资讯及与业内专家互动机会。
谈思实验室，为汽车科技赋能，推动产业创新发展！
如有侵权请联系:admin#unsafe.sh