0


在TPT中创建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的CarMaker进行可视化测试:

在TPT中创建SOTIF场景

喜欢本篇文章的话记得💬评论💖点赞⭐收藏 ➕更多技术文章直播课程,敬请持续关注北汇信息➕ ⬇️业务咨询请私信北汇信息或在官网留言⬇️
📩📩📩


本文转载自: https://blog.csdn.net/weixin_51954443/article/details/127749282
版权归原作者 Polelink北汇信息 所有, 如有侵权,请联系我们删除。

“在TPT中创建SOTIF场景”的评论:

还没有评论