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