从ISO 26262 到 SOTIF的发展分析和介绍，sotif

描述

自 ISO 26262 2018 版发布后，细心的读者可能会发现在第六章的软件开发部分的措辞有了微妙的变化，从测试（Testing）变成了验证（Verification）。比如软件单元测试变成了软件单元验证，软件集成与测试变成了软件集成与验证。

那么这两者有什么区别？新标准为什么要做这样的变动呢？也许我们可以从 DO178 中找到一些答案，在 DO178 中有如下说明：

图1  DO178 中关于 Verification 的描述

即验证并非简单的测试，因为测试不能展示没有错误。验证的范围大于测试，通常会包括评审、分析和测试；类似的表述在 IEC61508 标准中也能找到。我们来比较一下新旧标准中关于软件集成与测试（验证）的方法：

图2  ISO 26262 2011版(上)和2018版（下）中的软件集成与测试/验证方法

旧版本在软件集成验证阶段以动态测试为主：基于需求的测试、接口测试、故障注入测试、资源使用测试和背靠背测试；而新版本在旧版本的基础上增加了包括静态分析在内的方法：控制流和数据流的验证、静态代码分析和基于抽象解释的静态分析。从中可以看到软件验证环节需要结合包括动态测试、静态分析和人工评审在内的多种手段才能更有效排除错误，确保交付质量。

技术交流

ISO 26262 研讨会（上海/北京）

2019 年 7 月 2 日  950

主要介绍 MathWorks 工具链对于 ISO 26262 和 SOTIF 的支持情况，涵盖满足 ISO 26262 要求的模型验证和代码验证、符合 ISO 26262 软件开发过程中的工具审核问题，以及针对无人驾驶应用的场景建模仿真等方向。 

请扫描二维码完成此次活动注册：

从实施角度看，控制流和数据流可以采用覆盖度识别模型中的不可达逻辑、调用树分析函数关系以及共享变量的读写冲突检查等；静态分析手段则包括了代码（或模型）的合规和缺陷检查、复杂度等数据统计；基于抽象解释的静态分析采用了更为深入的形式化验证方法，对于特定范围内的模型或代码错误进行类穷举分析以确保软件安全（ absence of errors）。

随着自动驾驶等应用的兴起，在确定性的系统故障失效问题之外增加了由于类似于传感器性能受限、人工智能算法功能不足以及驾驶者误操作等不确定因素，需要在功能安全之外有新的安全标准补充，即预期功能安全（SOTIF）。SOTIF 的核心问题是探索发现未知不安全场景（区域 3）并将其转化为已知不安全场景（区域 2），通过风险评估和功能改进迭代最终实现已知安全场景（区域 1）的最大化。

图3  SOTIF 中的场景分类和目标

在这个过程中测试担当了非常大的比重，不管是针对区域2的需求测试还是针对区域 3 的随机测试。一款自动驾驶应用的成熟可能需要数十亿公里的测试，而仿真作为高效率低成本的测试手段，不管从模型在环到硬件在环还是从 NCAP 标准测试场景到随机生成测试场景，都是应对 SOTIF 的利器。

图4  MBD 流程中的 SOTIF 验证和确认

在汽车行业技术剧变前夕，未来新应用的复杂度呈指数级增加，创新点逐渐从机械为主到以软件为主，最终融合为以模型为中心。基于模型的流程和方法更显前所未有的重要，自动化的仿真、测试和验证技术的深入应用可以帮助我们更好地应对这些新的挑战。