标签: 预期功能安全

在无人驾驶汽车的研发过程中，人工智能 (AI)和机器学习起着重要作用。相应的，无人驾驶（和半无人驾驶）汽车的软件开发团队又要面临新的安全挑战：如何在故障未发生时保证预期功能安全？为了解决这一问题，新的ISO标准ISO/PAS 21448应运而生。 什么是 SOTIF SOTIF即道路车辆预期功能安全，它是ISO/PAS 21448: Road Vehicles —Safety of the Intended Functionality的简称。 ISO/PAS 21448适用于需要适当环境感知的功能，该标准关注的是在没有故障的情况下如何确保目标功能的安全性。 SOTIF与传统的功能安全形成了鲜明的对比，传统的功能安全关注的是如何降低由于系统故障而带来的安全风险，而SOTIF关注的是如何在没有系统故障的情况下确保安全。 SOTIF提供设计、验证和确认阶段的指导，通过这些指导，帮助您在没有错误的情况下达到预期安全的要求。 SOTIF示例如下： 设计阶段的测量示例：提供传感器性能的需求 验证阶段的测量示例：提供具有高覆盖度场景的测试用例 确认阶段的测量示例：提供模拟仿真 ISO/PAS 21448与ISO 26262的关系 ISO 26262能够覆盖系统失效的功能安全，但它没有覆盖到在系统失效未出现的情况下的安全隐患，这就是ISO/PAS 21448存在的必要性。 事实上，最初ISO/PAS 21448本来是要成为ISO 26262的第14章节。但是因为在没有系统失效的情况下保证安全这个概念非常复杂，SOTIF便成为了一个独立的标准。 2018年末，ISO/TC22/SC32/WG8功能安全工作组在意大利比萨召开会议，讨论了国际标准ISO21448的范围、对象、主要内容及框架等，中国代表团就“车辆运动控制系统功能安全可控性研究项目”进行了主旨发言，提出关于自动驾驶车辆的5项提案。 在无人驾驶的开发热潮中，功能安全ISO26262获得越来越多的关注和重视，与此同时，预期功能安全ISO/PAS 21448无疑将会成为汽车行业的另一大焦点。 ISO 26262与ISO/PAS 21448 ISO 26262仍然适用于现存的和已建立的系统，例如：动态稳定性控制（DSC）系统或者气囊系统。在这些系统中，可以通过降低系统的失效风险来保证安全。 ISO/PAS 21448适用于没有系统故障但是存在安全隐患的系统，例如：紧急干预系统和高级驾驶辅助系统。 ISO/PAS 21448是ISO 26262的补充。 为什么SOTIF 很重要 因为对自动系统进行验证是非常困难的。 为了避免潜在的安全隐患，需要自动系统具备情景感知能力，这样自动系统才能根据环境做出决策。 前文说到，人工智能和机器学习是开发自动系统的关键，而这些自动化系统拥有庞大的数据量（这些数据被输入到复杂的算法中），验证这些自动系统是否安全是复杂并且困难的，所以应用SOTIF是保证人工智能做出规避安全隐患决策的关键。 应用SOTIF 的 实例 SOTIF适用于没有系统故障的情况下存在安全隐患的系统。 例如： 路面结冰，人工智能系统可能无法感知到结冰路况，从而不能做出正确地反应，这种情况下就会存在安全隐患。由于不能感知结冰路况，无人驾驶车辆的行驶速度可能会超过此时应有的安全车速。实施SOTIF就意味着需要考虑这样的情况，并且基于可能性来进行相应的决策。 SOTIF的目标是减少潜在和未知的不安全的状况。然而，这样定义是很宽泛的，因为很难证明你已经考虑到所有的潜在的边界情况。 如 何确保无人驾驶的功能安全 安全性一直是汽车行业软件开发的关键。确保功能安全对无人驾驶至关重要。为了保证编写的软件是安全的，研发团队需要这样做： 使用信息安全的研发流程 人工智能和机器学习的最大挑战之一是其信息安全性，网络安全和人工智能本身都有大量需要考虑的地方。 关键的信息安全开发流程有如下三个示例： 为了消除安全漏洞，良好的编程实践和周密的 的 测试工作至关重要，可以通过使用信息安全编码标准来实现 开发安全模块的关键是对信息威胁建模和降低风险，可以通过进行危害和风险分析来实现 控制构建/发布环境是防止黑客入侵的关键，也能确保构建的安全。这可以通过在CI/CD环境中进行访问控制来实现 将设计、验证和确认变得自动化 在人工智能，机器学习和无人驾驶汽车领域，为保证软件的安全性，软件开发人员有很多需要考虑的风险。将设计、验证和确认过程变得自动化，可以提高研发效率。 SOTIF示例： 设计阶段的测量示例 使用需求管理工具，帮助 您满足 传感器性能的需求，这有助于设计更安全的软件。 验证阶段的测量示例 使用测试用例管理工具，帮助 您确保 不同场景的高覆盖率，这有助于软件验证。 确认阶段的测量示例 有一半的信息安全缺陷是在源代码级引入的。所以代码一旦完成，立即发现和修复BUG就是至关重要的。 但是很多开发者缺乏信息安全方面的培训，在进行代码审查时就很难识别出信息安全方面的问题。即使是训练有素的开发者，也很可能会犯不易察觉的错误。所以，开发人员需要通过遵循信息安全编码规范来查找和避免这类缺陷的产生。 静态代码分析工具可以帮助开发工程师快速遵循编码规范。它们可以标识信息安全方面的漏洞，加速代码审查的过程。能识别的错误包括内存泄露、非法访问、算法错误、数组和字符串溢出等。 使用专业的静态测试工具，如Perforce公司的Helix QAC代码静态测试分析软件，可以帮助您模拟潜在的运行场景，这有助于软件确认。 符合功能安全标准 SOTIF虽然对无人驾驶的功能安全非常重要，但是，不要忘记ISO 26262，遵守已确立的功能性安全标准仍然重要。 对于无人驾驶汽车来说，最好是遵循基于ISO 26262 ASIL的建议。 Perforce公司的Helix QAC得到SGS-TÜV SAAR认证，可用于安全相关软件的开发，可达ISO 26262 ASIL D的要求。 赶快上车，了解更多满足汽车功能安全的要求吧！ 参考文献 Richard Bellairs .Why SOTIF(ISO/PAS 21448) is Key For Safety in Autonomous Driving 《ISO/TC22/SC32/WG8功能安全工作组ISO21448预期功能安全（SOTIF）会议在意大利召开》-汽车标准化研究所

SOTIF(预期功能安全)是技术产品安全的一个子领域，处理技术系统的危险 。目前正在专门为汽车行业制定 的 “ ISO 21448 -道路车辆-预期功能安全性”标准， 是 便 于 将 对 产品和产品开发过程的要求提高到统一标准。 因此， SOTIF是产品安全的一部分， 并且 在许多国家 都是合法的 ，如德国和中国。 该标准的范围确定为新的、创新的和复杂的功能，并定义了由于功能限制而导致的错误的处理程序。 SOTIF旨在填补现有安全和安全标准的空白。一个著名的安全标准代表是ISO 26262，它处理由随机硬件故障或系统错误引起的错误的概念、程序和措施。 作为补充， SOTIF因此概述了避免任何不合理风险的目标，这些风险是由预期功能的不足、其实现和合理可预见的个人滥用所导致的危险。 该标准的核心是在安全和意识两个维度上对场景的风险评估，我们称其为场景矩阵。因此，该标准划分了以下四个 方面 ： 场景矩阵模型 该标准的目的是确定未知和危险的情况，并防止它们的发生。在我们看来，识别和消除所谓的边缘情况对高度自动化驾驶功能的成功 实现 非常重要。 该 规范基本上使用了场景这个术语。 情景是一种具有可能的变化组合的情况。一个例子是“路边的孩子”。这种情况的变化如下 : 孩子在路边停了下来 孩子穿过马路 在任何情况下，系统都不应该为驾驶员和他的环境造成危险。 问题是你不可能从一开始就知道所有可能的情况。新开发的正常情况是逐步获取信息和数据。这种迭代的方法导致了场景的持续扩展。 这 需要一个技术解决方案来处理扩展。 我们的案例研究可能扩展如下 : 有 /没有迎面而来的车辆 天气 (雨、雪、晴、阴) 其他人在路边 传感器脏 / 干净 一个垃圾袋 飘 在空中 每个场景可以有任何额外数量的安全相关方面。重要的是要知道，一个情况的扩展可以是相互依赖的，但不是必须的。这有时会使描述变得非常复杂和困难。根据我们的经验，了解依赖性和独立性使得创建测试用例更加容易。 不幸的是， 我们也无法 从一开始就知道所有这些依赖项。你必须准备好增加和改变 不同方面 。 测试用例定义将进一步复杂化，因为它们将确认 大量 为测试场景建模 创建的 测试用例。 因此，我们建议尽早开始使用系统的结构化方法进行 V &V 验证，因为预期会发生频繁的更改。 从我们的角度来看，您已经可以通过虚拟测试在软件级别开始 V &V 验证，从而在早期阶段获得知识。 最后的验证必须在车辆上进行，所有测试的基础可以在所有测试级别上复用。 我们问自己 ， TPT——我们的测试自动化 工具 ——今天是如何支持这个标准的。 简而言之， TPT提供了以下可能性: 拥有用于创建任何复杂性场景的测试建模语言和用于所有变量处理的结构化方法 背对背测试，在模型、软件、硬件和网络之间进行可 复 用的测试，从单元级到完整的集成 /产品级 在 CI/CT/CD环境和云(Windows/Linux)中快速执行测试 预期结果的可重用定义，独立于测试用例 仿真环境 集成 ，如 CarMaker 和 VTD ，以及提供 设置 个人清晰 模型 的选项 在 TPT中，有一种测试建模语言可用于场景描述。因此，基于模型开发的优 点，例如上下文分离、分层和清晰性，也可以用于测试。 测试用例的实现直接来源于测试模型。 从我们和众多客户的角度来看，几乎没有比开发基于场景的测试更简单的方法了。在任何时候，测试人员都对所有创建的场景有一个很好的 概览 。用户可以轻松地展开它们并添加变量。 单一数据 源的方法也使它们非常容易维护。 由于 结构和系统化 前所未有 的清晰，所有测试用例的创建和维护活动以及所有测试的评审都 将加速进行 。 在下面的视频中，你可以看到一个非常简单的 TPT测试场景示例，使用了IPG Automotive的 C arMaker 进行可视化测试: