1
简单来说,ISO26262针对:
SOTIF针对以下两个场景:
系统或组件的性能受限,导致预期功能不可达
2
Safety Of The Intended Functionality,即预期功能安全。
大家可以思考一下,淘宝上买的帮人握住方向盘,骗系统的行为,属于什么?
Triggering Event,驱动事件,指的是特定驾驶条件下,触发输入系统,可能导致危害事件。
直接拿标准的例子说明:如在高速路上,系统的AEB功能开启,此处误识别一个道路标志,导致车辆以-0.5g的减速度刹车5s。
这样的一个场景条件,就是所谓的驱动事件。
Validation,确认,指一系列增加系统符合预期功能的活动,这里主要和Verification进行区分说明,Verification主要针对Area2场景,Validation活动主要针对Area 3场景。其中verification 主要侧重于已知场景的测试,如边界测试-需求测试-注入测试-MIL-SIL-HIL测试等。Validation,则注重于未知场景的测试,如随机测试用例测试-长时间测试-根据经验测试-分析最坏场景测试等。
Area1:known safe scenarios 已知安全场景
Area2:known unsafe scenarios 已知非安全场景
Area3:unknown unsafe scenarios 未知的非安全场景
Area4:unknown safe scenarios 未知的安全场景
其中SOTIF则主要针对Area2 和Area3对症下药。
3
4
定义系统架构,描述系统的功能,确定系统的边界,此处类似于ISO26262中 相关项的定义。包括系统对外功能的交互的描述,系统内部的描述,尤其涉及到HMI,传感器-算法-执行器等相关描述,用于启动SOTIF。
识别危害场景,识别场景的触发条件,确定验收条件。此处主要进行由于功能受限引起的危害事件,分析危害事件的严重度和可控度,确定验证和确认标准。
根据上文识别的危害事件,识别触发潜在危害的事件,此处主要是找出触发危害事件的原因。
设计相应的措施,分配到系统功能,以减轻SOTIF风险,进一步评估所采取的的措施,对预期功能的影响。
一般改善措施包括,系统性能提升,如选用性能更好的传感器;限制场景的功能使用,如识别到车道线不清晰-大雨天气等,禁止使用自动驾驶功能或者限制使用某些自动驾驶功能;降低系统和误用,如设计更好的交互或HMI。
识别危害事件所在的区域(Area2/Area3),选取SOTIF推荐的验证或确认策略,这里核心是识别出相应的test case,并确定哪些适应于Area2,哪些适应于Area3.
对系统的传感器-算法-执行器等,进行重复覆盖测试验证,以证明修改的系统和组件,符合预期的功能,同时已知不安全(Area2)场景下,功能符合预期(危害风险足够小)。
对系统的传感器-算法-执行器等,进行实际场景验证,以证明修改后的系统或组件,符合预期功能,在未知不安全(Area3)场景下,功能符合预期(证明实际场景风险足够低)。
主要是评估残余风险是否可接受,是否符合发布准则。
5
SOTIF和ISO26262功能安全一样,也是定义了一套方法论,而SOTIF这套方法论最关键的是,尽可能识别出相应的场景-对应措施-以及验证策略。本文结合自身对行业理解,简要谈谈如何去搜索SOTIF场景。
主要将场景分为两个大类,分别为系统的功能限制,以及系统的预期合理误用。
a.列出系统所有的功能,并根据功能进一步细分传感器-算法-处理器-执行器,一步一步细分到组件。
b.罗列出系统各个功能的限制,这里需要按照一定的规则,罗列场景,并结合场景,找出功能边界值,极限值等。如考虑道路结构-天气状况-功能逻辑场景等,罗列传感器的极限值,算法的准确性,执行器相应的精确性等。这里场景应将性能限制Mapping到一张表,并评估组合在一起的可能性,将不可能出现的情况可以排除掉。此处可以借鉴HARA分析方法。
a.首先识别出干系人(Stakeholders)(如驾驶员-乘客等)
b.采用引导词识别误用原因
过程 | 引导词 |
认知 | 不理解 |
错误识别 | |
判断 | 错误判断 |
行动 | 失误(注意力不集中导致) |
故意 | |
不能(难以操作) |
c.考虑驾驶员与系统之间的交互(如一些操作,警告,指示,车辆行为等)
d.考虑用例场景的环境,如道路条件-天气等
e.通过以上来组合生成误用场景表
6
工作流 | 案例(AEB,紧急制动) |
系统功能规范 | 本功能使用雷达扫描前方障碍物距离,如果检测到近处的障碍物,AEB将会触发 |
SOTIF相关的危害识别和风险评估 | 交通场景:驾驶在交通繁忙地段 潜在危害:非预期的紧急刹车,可能导致后方车辆追尾 |
风险可接受? | No!驾驶员无法控制该危害,危害取决于两车间的间距 |
识别和评估驱动事件 | 道路上有易拉罐-或雪糕筒等异物,雷达可能识别为潜在障碍物 |
识别到的驱动事件可接受? | No!由于AEB导致的追尾事故必须减轻 |
修改功能以降低SOTIF风险 | 限制AEB的制动持续时间或制动力度 |
修改功能和系统规范 | 增加功能:限制刹车介入,以最小化减小或阻止由于非预期紧急刹车导致的伤害 |
识别驱动事件可接受? | Yes!无需进一步改进 |
定义验证和确认策略 | 选择设计相关的测试用例,以应对AEB相关的已知或未知非安全场景 |
验证SOTIF | 针对已知AEB场景,进行跟踪测试-仿真测试-以及耐久测试。 |
已知场景足够覆盖? 系统和组件表现符合预期? | Yes,认为所做措施,或相应场景概率足够低,风险可接受 |
确认SOTIF | 选择测试用例,进行整车层级测试,长久测试进行统计 |
系统和组件在真实场景中不会造成不合理风险 | Yes,长久测试参考GAMAB规则 |
发布SOTIF方法和准则 | 获得测试和验证的结果, 证明残余风险可接受。 |
已完成
数据加载中