浅析 | 智驾仿真测试在功能安全和预期功能安全上的应用现状
作者 | 村子里的莱恩
编辑 | 李慢慢
出品 | 车路漫漫
大家好，我是村子里的莱恩。
之前在群里聊起“自动驾驶仿真是不是功能安全的刚需”的话题，受邀写一篇关于功能安全的应用现状的文章。如有错漏，还请诸位同道留言，我将不胜感激。
本文将从智驾系统研发角度阐述，不包含管理、生产、运营、服务等方面。
本文先介绍功能安全再介绍预期功能安全。
一、功能安全的定义
术语解释
ISO 26262： 是以IEC 61508为基础，为满足道路车辆上电气/电子系统的特定需求而编写的国际标准。
IEC 61508：是电气/电子/可编程电子安全相关系统的行业标准。
功能安全：整车内任一控制单元或传感器产生故障时（不合理风险、危害、功能异常表现时）需要触发对应的策略保障安全。
1、策略：指发生不同安全等级的故障时要功能降级、功能退出或减速的方案。
2、关键指标：故障容错时间间隔。见下图。
ISO26262功能安全测试明确要求对软硬件进行错误/故障注入测试。如下图所示。
注入故障类型
二、系统设计
功能安全产品经理根据需求设计安全策略，不同故障严重程度对应不同的策略等级，不同的故障会映射成内部的事件名称。运行在车规级MCU或SoC上的safety模块，检测到事件后通过声光提示和触发对应智驾功能降级策略或者退出策略。例如车内"滴滴“声音提示，中控屏闪烁黄色红色灯光，智驾系统控制紧急刹车或者靠边停车等。
具体链路如下：底盘的横向电子助力控制单元CAN总线信号丢失，MCU-Safety模块检测到故障（中断失联）并触发AEB下发紧急制动控制命令。当有更复杂的检测逻辑和策略需要执行，会由SoC-Safety模块检测并通过PNC规划更合适的控制命令。SoC的状态机的作用还涉及到控制车内声光警报。
三、测试方案
主流
实车测试：实车测试执行器类的故障，采用外设总线网 关篡改信号注入故障。传感器故障采取吸光吸波遮挡、拔插信号线等手工制造故障。实车测试方式对道路场地要求很高，需要在封闭路段测试，第三方认证和demo演示一般会要求实车测试。
仿真测试：仿真环境不仅可以注入外部故障模拟总线信号，或者域控内部MCU/SoC内部故障，也可以注入所有传感器的内部故障。要求全链路覆盖验证功能安全设计则需要基于HIL的仿真。
趋势
智驾域控制器集成度越来越高，从最开始只需要集成MCU和SoC芯片，外挂超声波、毫米波和组合导航。到现在行业上开始将超声波、毫米波和组合导航等传感器数据处理芯片集成贴片到域控制器主板上。这样对于HIL仿真环境要求更高，涉及到飞线处理。
高端车型或更高级的智驾系统，采用双域控制器和双底盘执行器实现冗余/备份安全机制，但这类测试对于仿真测试方案影响较小，只是HIL对应成本会增加。
四、功能安全测试用例
1、泊车过程中EPS执行器E2E校验结果异常触发安全策略。
2、FTTI故障容错时间间隔分析
备注：关于测试用例的数量，实际项目中，测试用例按照行车、泊车和主动安全各种子功能划分，小功能多的比如主动安全20+，少的比如行车10+。仅HIL测试仿真测试的内容来讲，子功能数量乘以200+故障点。主动安全就有5K+测试用例，三个大智驾功能总数接近1W条测试用例。
五、仿真测试类型
目前行业流行的闭环测试方式：通过仿真场景、动力学和被测对象（算法模型或域控制器）形成闭环仿真测试-worldsim。
1、SIL：构造模拟智驾系统内部驱动层数据消息给上层算法和系统状态机，接收PNC输出的控制命令反馈给动力学，仿真场景根据动力学生成新的传感器数据给算法，形成闭环。优点是不依赖域控硬件环境，可以编译X86版本，在高性能服务器上多容器并行测试。
基于SIL测试功能安全，一般是构造内部故障消息，比如上层应用模块的自检错误或运行过程中的错误，观察safety模块发出的策略是否符合设计？系统状态机是否正常跳转？PNC模块是否发出减速度控制命令？
2、HIL：构造模拟智驾系统外部硬件信号给域控制器作为输入，接收智驾域控发出的CAN总线底盘控制命令给动力学，仿真场景根据动力学生成新的传感器数据，通过各种硬件板卡生成硬件信号给智驾域控制器，形成闭环。优点是验证了智驾域控的底软、片间通信、中间件和智驾算法完整链路。
上述讨论的是worldsim，数据都来自动画效果的仿真场景，可能存在置信度疑虑。所以在实际应用中也有logsim方式，数据来自实车采集的传感器数据，可以类似SIL那样回灌给上层算法，也可以类似HIL硬件回灌给域控制器。
3、SIL和HIL的对比示意图：
4、VIL车辆在环
当HIL仿真的实时机体积足够小，我们可以把主机部署到实车上，将仿真的传感器数据接入智驾域控制器，监听底盘总线控制命令代替动力学给仿真场景生成新的传感器数据，这样结合实车的动力控制性能，测试验证效果更加具有信服力。这种方案类似于给实车戴上了VR眼镜，而智驾域控收到的传感器数据则由软件生成或者实车案例的数据回灌。
六、预期功能安全的应用
预期功能安全的来源
国际标准ISO 21448：确保智能驾驶系统在不存在故障时，因传感器局限、算法不足或环境干扰等因素，仍能避免不合理的安全风险。
预期功能安全的定义
预期功能安全（Safety of the Intended Functionality, SOTIF）：避免由于预期功能或其实现的功能不足引发危害所产生的不合理风险。 预期功能：客户需求/产品文档里设计的运行的特定条件和环境范围的智驾功能。换句话说，定义智驾系统“在哪些情况下可以工作”。
预期功能安全的目标
相较于功能安全（FUSA）是在明确发生故障时我们要执行的对应策略，预期功能安全（SOTIF）则是为了在系统无软硬件故障时，避免系统本身中功能不足（也可以理解为性能不足）引起的危险。
预期功能安全的案例分析
案例1：
Uber自动驾驶测试车撞上横穿马路的行人（2018年） SOTIF问题：系统算法未将夜间推自行车行人识别为危险目标。
案例2：
某车型AEB在隧道口误触发 SOTIF问题：摄像头因光线突变误判前方障碍物。
预期功能安全的应用流程
1.需求举例
2.测试目的
综合各类技术手段，在有限的测试中证明被测系统风险满足接受准则，并进一步说明被测系统SOTIF性能水平。
3.测试方案
SIL/HIL/实车测试：发现性能边界与功能不足
泛化测试：评估残余风险。
4.测试方式
构建许多小概率交通场景，保证可接受风险水平内的场景完全通过测试。
基础工况叠加极端场景
5.测试用例
6.选择测试方式
实际项目中，预期功能安全的验证工作量十分巨大（数据饥渴）需海量极端场景数据训练。建议挑选少量场景选择HIL执行，更多的是基于SIL并行自动化测试验证。
七、展望
即使用了不同的仿真手段，但面对每个交付节点的巨量验证项，手工测试还是难以应对。如上述提到的功能安全1万条测试用例，小交付节点可以只做增量测试，但大的交付节点要求全量测试，手工测试需要约30人天、自动化则可以减少到3天。
所以从效率质量角度出发，要引入尽快自动化测试，通过封装和调用故障注入接口，自动读取规范化的文字版测试用例，套用自动化测试基础模板，批量执行测试用例。
以上，本文完。
