这是“汽车人参考”第370篇原创内容
“推动智能电动汽车向前进”
无论是自动驾驶整车，还是解决方案，或是软件、算法、硬件单个模块，量产落地的速度有明显加快的趋势。在开发过程中，对安全的要求及管控愈加迫切，目前行业里将自动驾驶安全分为Safety（FuSa和Sotif）和Security两大部分，这里分享一些思考。
回顾Uber自动驾驶事故
2018年3月，一辆Uber无人驾驶测试车在美国酿成致死事故，一度让整个行业陷入停滞 ，事后结案报告分析了主要原因。
首先Uber对周围环境感知的模型，假定只会出现自行车、行人、车辆三类物体，且这三类物体只会沿着车道线行进。
但现实情况是行人推着自行车横穿马路，按照模型预设，Uber在任何情况下都不会对上述场景进行分类识别。
其次是车辆驾驶员对Uber并没有及时接管（过于自信），在整个系统设计中没有考虑到人为因素。
从这个事件可以看到，自动驾驶安全设计，除了去满足已有规格书Spec的要求，更需要去验证Spec的充分性。
自动驾驶安全的特殊挑战
从上述案例引申出来，自动驾驶对安全提出很多挑战。
首先，自动驾驶是以数据来驱动的，而大量数据集很难通过要求来描述；其次，AI算法的输出缺乏可解释性，难以通过传统的通过/不通过（yes/no）的方式去验证；再次，还存在大量非技术因素，包括交通系统布局不合理、交通参与者行为不规范等；最重要的是，存在大量的随机的且未知的长尾场景。
为了应对以上挑战，在Safey领域主要以功能安全FuSa和预期功能安全Sotif两大标准进行约束。
FuSa和Sotif是安全的两大命门
功能安全（Function safety），关注E/E电子电气架构本身的失效（Failure）；而预期功能（Sotif），解决的是自动驾驶由于性能局限、功能不足及合理可预见的人员误用带来的危险（Harzard）。
功能安全是假定规格书Spe是正确的前提下，去关注产品有没有遵循或实现相关的流程和标准；而预期功能安全更多是针对产品规格书Spe不足的地方进行规范，两者相互补充，是自动驾驶安全的两大命门。
在这两个安全之上，又诞生了网络安全（Cybersecurity）的要求，三者的关系可以用以下的图来表示。
针对于危险，如果是从本身系统而来的，需要遵循功能安全；如果是来源于系统外部，且被人故意误用，那么属于网络安全的范畴；其他层面全部划分到预期功能安全的范畴。
FuSa和Sotif如何解决安全问题
根据安全类型以及认知程度，可以将自动驾驶场景划分到四个区域。
区域1是已知、安全的场景（Known-Safe），区域4是未知、安全的场景（Unkown-Safe），自动驾驶汽车可以运行在这两个场景中。
针对于区域2，已知、不安全的场景（Known-Unsafe），需要在系统设计时，提前考虑。
而针对于区域3，是未知、不安全（Unknown-Unsafe），可以理解为长尾的场景。
有两种思路来应对区域2和区域3的安全问题，一是保守的方法，即通过限定自动驾驶运行设计域ODD，让自动驾驶系统只能在已知和安全的场景才能运行，但这样治标不治本，更不利于自动驾驶的规模商业化落地。
另外一种思路是努力将区域3的范围缩小，但是，由于未知的场景是无穷尽的，无论如何缩小，永远都存在。
进一步来说，区域3理论上可以看作“熵增”运动，要努力减熵，需要保持开放，同时要有外力做功，减少混乱程度，脱离平衡。
映射到自动驾驶，一是让系统本身通过数据闭环，持续地学习和升级；二是通过V2X，增加视距，增强对未知场景的认知程度。
汽车人参考小结
系统内的失效或危险，可以通过功能安全来管控，而针对于系统外的失效或危险，可以通过预期功能安全和网络安全来管控。
但是本质上都没有解决在长尾场景下的安全问题，通过传统预测概率和规避的方式已不适用，通过数据闭环依然还是无法cover到100%，因为AI本身的无法解释特性，会不会导致安全就是一个无解问题，值得行业探讨。
本文为汽车人参考第370篇原创文章，如果您觉得文章不错，“推荐和关注”是对我最大的支持，欢迎随时和我交流。