?本文约2700字，大约需要9分钟阅读
导语:
SASETECH，Safety and Security Technology，是国内首个由汽车功能安全汽车专家发起组建的技术社区，致力于为汽车安全的从业者提供交流、学习、合作的中立性平台。安全是汽车的基石，安全从业者是人们生命及财产的守护者。我们希望SASETECH 打破高大上的壁垒，让更多工程师参与讨论、共同成长；让安全成为一个话题，是一个让大家讨论和思考的技术方向；让安全成为一种文化，是一个让企业和监管机构愈发重视的领域；建立安全的生态，让企业/从业者都能够有所收获、有所思考。
欢迎关注：SASETECH
前言
2016年，美国佛州的一辆特斯拉Model S在Autolipot状态下与正在转弯的白色半挂卡车发生碰撞，钻进了卡车货柜下方，特斯拉驾驶员不幸身亡。
图1：特斯拉事故
直到近几年陆续发生的事故，都指向特斯拉由于视觉感知的缺陷，无法有效识别静止的白色车辆。对静态车辆的检测，属于当下以“摄像头+毫米波雷达”作为主传感器的L2级自动驾驶方案的一个世界性难题。
传统的功能安全已经无法覆盖此类”失效”。2018年以来预期功能安全(sotif,iso21448)持续发展，解决的正是系统性能局限以及驾驶员误用引发的整车层面危害。
SOTIF
工作流
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策略制定与实施。
图2:SOTIF开发流程（融合功能安全）
可以看出SOTIF内容覆盖面同样很广，本文主要就validation target如何制定，给出对于标准的解读和自己的思考。
Validation Target
初步探索
Validation是解决L2+以上智驾的重要一环，是证明智驾产品安全可靠的关键指标，同时也各家主机厂比较头疼的问题，究竟validation target 该如何定义，比如：
-
如何证明经过validation之后风险降低到可接受水平？
-
需要验证多少里程，多长时间？
-
选择哪些场景路试？
-
仿真和实车的时长如何分配
本文将对前两个topic进行初步探索：
先聊聊路试时长的定义，标准里给出这样一个公式：
STEP1
识别事故导致伤害H的原因，比如非期望制动导致后碰的风险。这里比较关键，涉及到step2事故接受指标的定义，因为横向控制导致出车道的风险与纵向控制导致的追尾或后碰指标是不一样的。
STEP2
识别step1中发生事故的可接受准则AH，需要查询事故数据库，比如德国GIDAS数据库，经历较多年的发展已经较为完善，国内CIDAS数据库统计正在建立过程中，目前数据还不全。典型的指标如（有些是里程指标/km，有些是时间指标/h，可以结合车速进行换算）：
图3：AH示例
STEP3
识别危害行为可能发生的潜在危险场景（比如高速行驶后方有近距离车辆跟随），假设危害行为发生在该场景下的条件概率为PE|HB。这里引入了ISO26262里的exposure概念，同样frequency&duration的理论也适用，在最新一版的ISO21448中增加了此参数，之前标准中未考虑exposure。为什么在定义validation target要引入此概念，而在SOTIF HARA分析时只考虑了S，C，各位可以深入思考下。
STEP4
识别危害行为在危险场景不可控的概率PC|E，假设暴露在该场景下。
STEP5
从危害事件中识别严重度的分布，假设驾驶员不可控，这个分布描述发生事故中各严重程度的概率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，可能有些观点有失偏颇。这里只是抛砖引玉，可能以上的问题各位心中已有答案。
SOFIT
分解
最后介绍下如果计算出来validation target时间很长，是否可以通过类似ASIL分解的方法对路试时长进行裁剪。举个例子，假设我们通过上述公式整个系统的Rhb=10^-9,同时系统内有两条独立的路径实现同一个功能（如前视摄像头，环视摄像头均可检测车道线），我们是否可以对两条路径单独验证，这样每条路径的验证时长可以缩短（可能缩短至10^-3 OR 10^ 4），因为任一通道的潜在功能缺陷可以被视为“多点功能缺陷”。如下图所示，假设channel fusion模块没有功能缺陷,且能够比较来自两个通道的信息,若发现不一致，则输出不一致信息。
图4：Two channel system architecture
如果上述“SOTIF分解”可行，则如何进行指标分解？
这是个挺有意思的话题,比如“多点功能缺陷”是否可以类比ISO26262中“多点故障”，进而参考Part10中的多点故障计算公式进行推导？留给各位思考。
还有问题没有解决,如何保证两个通道的独立性呢？标准给出了几种量化的指导意见↓
1.分析
a.关联失效分析
b.各通道采用不同传感器组
c.各通道采用不同传感器算法
2.专用测试与确认
a.测试表明系统能够应对假设的共因或关联失效
b.系统性设计确认测试,充分测试已知或假设的传感器、组件和通道缺陷
3.专用措施
a.措施可以覆盖由理论分析(如DFA)出的共因失效或观测到的关联失效
b.使用类似传感器或功能对其他系统中观察到的功能不足进行分析
c.对开发过程中观察到的单通道功能不足进行分析或通过现场监测,提供证据证明其他通道不受此问题影响。
图5：System behaviour modelling
总结
本文先简要分析特斯拉事故原因—即视觉缺陷,引入SOTIF流程介绍,重点描述了SOTF工作流与FUSA相似点,之后就SOTIF validation target如何导入给出公式详解。最后对如何减少路试时长进行了初步的探索(“SOTIF分解”)。同时留下了很多问题,一些观点带有主观的想法,仅作为各位理解标准过程中的参考。
智驾安全道阻且长，未完待续……
作者简介
小南郭
某OEM 智驾功能安全工程师，负责高低速智驾功能安全开发与流程管理。4年系统功能安全开发经验，熟悉ACC/AEB/RPA/HWA/TJP等产品功能安全方案。
往期精选
SASETECH专家申请（请扫右侧二维码提交）
微信交流群入群
（添加管理员微信，备注公司+姓名+研究领域）
SASETECH组织致力于推动功能安全、系统安全、网络安全、预期功能安全的业内交流和技术进步，打造全新智能网联汽车安全生态圈。欢迎加入！
原文始发于微信公众号（SASETECH）：特约专栏 | 浅谈SOTIF validation
