浅谈SOTIF validation
来源 | SASETECH
2016年，美国佛州的一辆特斯拉Model S在Autolipot状态下与正在转弯的白色半挂卡车发生碰撞，钻进了卡车货柜下方，特斯拉驾驶员不幸身亡。
直到近几年陆续发生的事故，都指向特斯拉由于视觉感知的缺陷，无法有效识别静止的白色车辆。对静态车辆的检测，属于当下以“摄像头+毫米波雷达”作为主传感器的L2级自动驾驶方案的一个世界性难题。
传统的功能安全已经无法覆盖此类"失效"。2018年以来预期功能安全(sotif,iso21448)持续发展，解决的正是系统性能局限以及驾驶员误用引发的整车层面危害。
SOTIF主要工作内容是Clause6-Clause12，6-7进行SOTIF HARA分析，识别system limitation和triggering event，与ISO26262中Part3处于同一阶段。
功能安全Part3包括相关项定义、危害分析和风险评估等活动，输出功能安全概念。功能安全概念描述了分配给实施安全措施的架构元素。SOTIF包括功能更改，是为避免、减少或缓解导致 SOTIF风险的 system limitation而制定的措施。
ISO26262第4部分是系统级产品开发，将功能安全概念分解为技术安全概念，同时还定义确认测试策略。SOTIF V&V与Part4可在同一阶段开发，包括V&V策略制定与实施。
可以看出SOTIF内容覆盖面同样很广，本文主要就validation target如何制定，给出对于标准的解读和自己的思考。
Validation是解决L2+以上智驾的重要一环，是证明智驾产品安全可靠的关键指标，同时也各家主机厂比较头疼的问题，究竟validation target 该如何定义，比如：
-
如何证明经过validation之后风险降低到可接受水平？
-
-
-
识别事故导致伤害H的原因，比如非期望制动导致后碰的风险。这里比较关键，涉及到step2事故接受指标的定义，因为横向控制导致出车道的风险与纵向控制导致的追尾或后碰指标是不一样的。
识别step1中发生事故的可接受准则AH，需要查询事故数据库，比如德国GIDAS数据库，经历较多年的发展已经较为完善，国内CIDAS数据库统计正在建立过程中，目前数据还不全。典型的指标如（有些是里程指标/km，有些是时间指标/h，可以结合车速进行换算）：
识别危害行为可能发生的潜在危险场景（比如高速行驶后方有近距离车辆跟随），假设危害行为发生在该场景下的条件概率为PE|HB。这里引入了ISO26262里的exposure概念，同样frequency&duration的理论也适用，在最新一版的ISO21448中增加了此参数，之前标准中未考虑exposure。为什么在定义validation target要引入此概念，而在SOTIF HARA分析时只考虑了S，C，各位可以深入思考下。
识别危害行为在危险场景不可控的概率PC|E，假设暴露在该场景下。
从危害事件中识别严重度的分布，假设驾驶员不可控，这个分布描述发生事故中各严重程度的概率PS|C。比如X%交通参与者发生严重的伤害，或至少X%交通参与者发生轻微伤害。按标准的意思，笔者认为这里也存在条件概率，即C3的情况下对应各s等级的分布。
在ISO26262中S与C耦合较深，E相对独立，而在SOTIF中是否同样适用？标准中没有给出答案，个人理解SOTIF中E S C三者是深度融合的， 而不仅仅是S与C关联，此处后续可以展开聊聊。
咱们继续往下，假设一个危险行为不总是导致伤害发生，可接受准则可以分解为：
危害行为Rhb是可以被容忍的比率，作为一段时间内危害行为发生的概率。危害行为直接由trigger event结合功能缺陷导致，因此可以被当作validation target。
在风险识别和评估中，假设伤害H识别后，对应的可接受准则为AH=10^-8/h,从实际数据中得知危害行为导致不可控的百分比为PC|E=10%。达到可接受标准的严重度对应的为PS|C=10%。驾驶员在该场景下（危害行为导致伤害）暴露概率预估为PE|HB=5% driving time。因此可以计算target value如下：
因为满足泊松分布，如果5000h测试周期内没有发生危害行为即有63%置信度认为风险可控。不同的功能以及危害行为需要取不同的置信度。
这里标准只给出简单的示例，仍然有很多问题值得探索：
1.SOTIF中S E C是如何关联？条件概率如何计算? 标准未给出答案。
2.S如何评估，根据碰撞前后的速度？ΔV>50KPH一定会达到S3等级么？
3.为什么定义validation target时可以引入暴露度的概念，和之前的标准是否冲突？
4.为什么满足泊松分布，以及如何结合不同的危害行为定义不同泊松分布置信度？
5.测试时长确定后，如何合理分配仿真测试时长，实车道路测试时长？
6.如何结合功能选择哪些场景validation？
笔者也是初识SOTIF，可能有些观点有失偏颇。这里只是抛砖引玉，可能以上的问题各位心中已有答案。
最后介绍下如果计算出来validation target时间很长，是否可以通过类似ASIL分解的方法对路试时长进行裁剪。举个例子，假设我们通过上述公式整个系统的Rhb=10^-9,同时系统内有两条独立的路径实现同一个功能（如前视摄像头，环视摄像头均可检测车道线），我们是否可以对两条路径单独验证，这样每条路径的验证时长可以缩短（可能缩短至10^-3 OR 10^ 4），因为任一通道的潜在功能缺陷可以被视为“多点功能缺陷”。如下图所示，假设channel fusion模块没有功能缺陷,且能够比较来自两个通道的信息,若发现不一致，则输出不一致信息。
图4：Two channel system architecture
如果上述“SOTIF分解”可行，则如何进行指标分解？
这是个挺有意思的话题,比如“多点功能缺陷”是否可以类比ISO26262中“多点故障”，进而参考Part10中的多点故障计算公式进行推导？留给各位思考。
还有问题没有解决,如何保证两个通道的独立性呢？标准给出了几种量化的指导意见↓
b.系统性设计确认测试,充分测试已知或假设的传感器、组件和通道缺陷
a.措施可以覆盖由理论分析(如DFA)出的共因失效或观测到的关联失效
b.使用类似传感器或功能对其他系统中观察到的功能不足进行分析
c.对开发过程中观察到的单通道功能不足进行分析或通过现场监测,提供证据证明其他通道不受此问题影响。
图5：System behaviour modelling
本文先简要分析特斯拉事故原因—即视觉缺陷,引入SOTIF流程介绍,重点描述了SOTF工作流与FUSA相似点,之后就SOTIF validation target如何导入给出公式详解。最后对如何减少路试时长进行了初步的探索(“SOTIF分解”)。同时留下了很多问题,一些观点带有主观的想法,仅作为各位理解标准过程中的参考。
当前暂无评论，小编等你评论哦！
