标签: 场景仿真

随着汽车行业的蓬勃发展，与之相关的自动驾驶功能越来越受到人们的关注。 自动驾驶给人们带来方便的同时，也带来了某些安全隐患。为了最大程度的确保安全，除了要进行功能逻辑测试外，也需要进行功能 场景测试 （比如鬼探头、多岔路上坡等场景）。 目前主流的场景测试工具有Carmaker、VTD、DYNA4 、 CarSim 和 PreScan 。 为了使场景测试的测试用例可读性更强，对复杂功能的评估更高效，北汇信息提出基于TPT的测试解决方案。 接下来，以 TPT+Carmaker 为例，介绍如何实现自动化的场景测试。 TPT和场景仿真软件集成 TPT提供以上场景测试工具的集成平台和接口。TPT中的FUSION平台存在 CarMaker FMU Node、VTD Client Node、FMI Fusion Node和Custom Node Dll ，能够实现与场景测试软件的集成，感兴趣的小伙伴可以查看北汇公众号前期文章《震惊！虚拟场景仿真测试还能这么玩》。 下面，我们以Carmaker FMU Node为例，介绍配置过程。 在TPT中新建Carmaker platform，配置如下：加载Carmaker工程 和Test run，导入信号即可完成配置，非常简单。 场景测试用例编写 TPT中支持测试步骤列表和状态机测试用例，测试步骤列表简单快捷，状态机图形化便于理解。 例如AEB（自动紧急刹车）功能，测试场景为主车逐渐靠近目标，当距离小于阈值时，刹车确保安全。 根据如上场景，搭建状态机测试用例。根据状态机及转移线显示的内容，能够很快了解到测试场景内容，例如：整车上电，开启AEB功能，油门为30， 整车加速至50km/h，持续15s。 另外，通过改变状态机变种或跳转条件，可以很方便的实现其他 测试场景。 测试评估多样化编写 TPT支持在测试用例中编写评估，也有独立于测试用例的GUI和脚本评估。 自动驾驶逻辑往往非常复杂，评估需要多个条件，TPT评估语法为Python语法， 方便快捷，另外，TPT内置了很多函数，例如：上升沿、下降沿、积分、微分等等，编写评估时直接使用即可。 =0.7，降低车速，避免与目标碰撞。GUI和脚本评估会自动寻找满足condition的区间开启评估，并判断是否满足期望结果。 如下为Trigger Rule评估的Trigger Condition形式，当满足Start Condition条件时，开启评估并检查是否符合期望，满足Stop Condition条件时，关闭 评 估 。 Tips ： TPT.risingEdge () 用法为，当 () 里的条件由不满足到满足时触发，由于主车与目标距离逐渐降低，则应为 :TPT.risingEdge(Sensor::Object::Camera::relvTgt::NearPnt::ds_p<10) 。同理，如果为 TPT.fallingEdge () ，则条件为 Sensor::Object::Camera:: relvTgt :: NearPnt :: ds_p 10 。 上述评估也可以基于Script评估实现，示例如下： 我们也可以将脚本评估作为库，方便其他同事使用。 测试运行 可以在TPT当中新建 TestSet ，对测试用例进行分组，运行指定的测试集。当然了，最方便的方法是直接选中想要执行的测试用例，直接运行。 测试用例执行完成后可以在Build Progress中查看结果，在Signals中查看测试数据，在Overview Report中查看测试报告。 说了那么多，来看一下TPT是如何执行场景测试的吧。 TPT的功能不仅限于上述内容，TPT可以通过集成不同平台实现所有的产品研发阶段测试（ MiL 、 SiL 、PiL、 HiL 、 ViL ），更多精彩等您来探索。

背景介绍 随着ADAS技术日趋成熟，ADAS市场迅速增长。AEB (Autonomous Emergency Braking)作为ADAS的一项重要主动安全功能，如今已纳入全球主要汽车市场的碰撞安全评分体系。面对汽车功能安全标准不断提高，如何在系统开发早期对系统功能进行满足安全标准的测试，以降低后期维护成本、避免安全功能缺陷成为了诸多整车厂与供应商的重点关注问题。 AEB系统的测试场景 为应对汽车科技不断革新，世界各国成立了各自的NCAP（NEW CAR ASSESSMENT PROGRAMME）认证机构。目前的新车安全评价项目中，以E-NCAP测试规程所涵盖的范围最为广泛，而国标C-NCAP也是以E-NCAP为基础制定修改的 。 表1 E-NCAP评估项目 以E-NCAP测试协议中关于AEB系统功能的测试项目AEB CCR (car-to-car Rear)及AEB VRU（ Vulnerable Road Users ）为例，首先我们来了解一下具体的测试场景。 CCRs（Car-to-Car Rear Stationary）测试车追撞前方静止目标车 测试车沿测试路径（即碰撞车道中心线）向目标车行驶，测试车速度 10-50km/h，且测试车与目标车重叠范围-50%-50%，如图1所示。 CCRm（Car-to-Car Rear Moving）测试车追撞前方低速目标车 测试车沿测试路径向目标车行驶，测试车速度30-80km/h，目标车速度20km/h测试车与目标车重叠范围-50%-50%，如图1所示。 图1 CCRs、CCRm测试场景 CCRb（Car-to-Car Rear Braking）测试车追撞前方减速目标车 测试车和目标车速度均以50km/h速度沿测试路径同向行驶，车距分别为12m（或40m），目标车分别以加速度-2m/s 2 （或-6m/s 2 ）刹停，如图2所示。 图2 CCRb测试场景50km/h 50km/h (-2 or -6m/s2) VRU-CPFA（Car-to-Pedestrian Farside Adult）测试车碰撞远侧成人 行人距离测试车中心线6m,在1.5m内加速至8km/h速度，沿与车辆行驶方向垂直的方向向测试车移动，测试车速度为10-60km/h，碰撞位置为50%重 叠处即图3中L点。 图3 CPFA测试场景 根据AEB测试场景搭建测试用例 在搭建测试用例过程中，如何逻辑清晰地把握场景中信号间的相互关系和激励时段往往是复杂模型的测试难点所在。TPT作为PikeTec公司研发的嵌入式系统模型动态测试验证工具，针对场景测试采用 分时段逻辑路径、参数variants、测试用例并行执行 、 图形化 的方式搭建测试用例，使得场景构建灵活便捷，下面我们将结合AEB场景对这些搭建特点进行说明。 测试车坐标系按照 ISO 8855 ： 1991 中所指定的惯性坐标系，如图6所示： 以测试车与目标车100%重叠时的初始位置为场景坐标系原点，X轴指向车辆前方，Y轴指向驾驶员左侧。本文仅以100%重叠率为例介绍搭建测试用例。 图 4 测试用例坐标系 测试用例结构说明 【特点1 分时段的逻辑路径】 TPT将测试场景的变化以时段划分，场景顺序定义清晰。测试用例每个区域都包含一条分时段的逻辑路径。其中，转移线定义了当前时段结束进入下一个时段的跳转条件；Local型状态块用于定义当前时段的激励信号；Reference状态块的信号定义直接参考相应Local状态块，避免重复性定义。 图 5 测试用例结构 CCRs测试用例 【特点2 多个用例并行执行】 当同一场景中场景目标较多时，一条测试逻辑路径难以清晰高效地控制多个目标时段。TPT支持对同一场景用例进行分区，搭建多条测试用例以控制不同的测试对象，同时支持多个用例并行执行，严格控制同一场景不同信号的时段关系。 如图 6 中将测试用例区域分成两个区域，分别用于分配场景中测试车控制信号与目标控制信号。测试用例的分时段信号说明如下： 测试车控制： 测试用例开始执行Ego init初始化测试车位置与速度；之后Ego action1测试车加速到40km/h；达到目标速度后进入Ego action2，测试车保持速度行驶；判断测试车速度是否符合测试结束条件，满足条件则延时2s测试用例结束。 目标控制： 测试用例开始Object init初始化目标位置（距离测试车300m）、速度、加速度、目标类型（CAR）等；当测试车执行Ego action2匀速行驶时，目标执行Object action1测试车感知到目标。 图 6 CCRs测试用例 【特点3参数variants】 将不同场景相同时段的信号参数以variants定义，通过组合variants和场景的逻辑路径，快速搭建测试用例。 CCRs场景中需要对测试车速度10-50km/h进行测试，当前测试用例测试车目标速度为40km/h。如图 6 所示，在Ego action1中针对测试车的不同速度要求定义了不同的variants，搭建用例时只需在状态块上右键切换即可调用不同的速度取值，避免重复定义提升用例搭建效率。 【特点4图形化】 通过将逻辑路径图形化，结合variants与转移线文字标注使得场景逻辑一目了然，易于阅读与后期维护。 CCRm测试用例 CCRm测试场景与CCRs相比：目标类型不变仍然为CAR、目标速度要求为20km/h匀速运动；测试车测试速度范围发生变化。因而与上图CCRs的测试用例相比只需进行如下改动： 测试车控制：Ego action 1选择目标速度30-80km/h的variants。 目标控制：Object action 1调用加速到20km/h后保持匀速的variants。 图 7 CCRm测试用例 CCRb测试用例 目标起始位置距离测试车12m（或40m），因而Object init初始化目标位置沿X轴方向12m； 测试车与目标以50km/h速度行驶，在Ego action 1 与Object action 1 定义两车加速到50km/h； 目标刹停且减速度为2m/s 2 ，对应定义Ego action 2 测试车保持匀速及Object action 2目标车以2m/s 2 减速。 图 8 CCRb测试用例 CPFA测试用例 Object init 初始化目标假人起始位置（300m,6m）、目标假人类型（EPTa）；Object action1目标出发，1.5m内加速到8km/h之后保持匀速并被测试车感知到。 图 9 CFPA测试用例 最后我们对以上测试过程进行分析总结，进一步明确采用TPT模型动态测试工具对场景测试的思路。如表2所示，根据场景描述我们可以对场景要素分类（测试车状态、目标属性、目标状态），对应测试用例的不同时段的状态块（Ego action、Object init、Object action），在每个状态块为不同场景需要的参数定义variants（如Ego action包括10-80km/h的variants）。定义了variants之后，搭建逻辑路径并编写时段结束条件，根据测试场景选取variants进行组合即可完成用例搭建。 表2 测试场景要素与测试用例variants分析 图 10 测试用例的variants分类 测试执行与评估 ISO26262明确要求要在模型开发阶段对模型进行基于需求的测试，功能安全系统是否能实现预期的功能，对测试用例执行数据进行评估是不可或缺的。 AEB自动紧急制动是如何实现的？ 被测AEB模型需要从传感器模型获取感知信息（测试车与目标的相对距离、相对速度、相对加速度、目标类型等），以计算预期的碰撞距离、碰撞时间等参数并及时进行制动干预。此外，在FCW（Forward Collision Warning 前防碰撞预警）系统开启的基础上，开启AEB模式，AEB系统才可生效，也就是说AEB系统运行离不开FCW功能。 AEB场景测试执行条件 NCAP测试规程对FCW及AEB系统测试场景的执行条件有具体要求。 表3 测试场景执行要求 T FCW ： 指FCW声音警报开始的时间。 T AEB ： 指 AEB系统激活 的时间。 TTC：Time To Collision 指测试车碰撞目标之前的剩余时间。 其中，VRU场景目标假人碰撞判定方式为：以目标假人的髋部点为参考点，高度为（ 923 ± 20 ） mm ，在周围定义了一个虚拟区域尺寸如图 11 所示，测试车的虚拟轮廓线与目标假人的虚拟区域接触时判定碰撞发生如图 12 所示。 图 11 目标假人（成人/儿童）周围虚拟区域尺 图 12 远端目标行人碰撞结束场景 TPT-闭环测试及自动评估 通过以上介绍我们可以知道，AEB的评估是基于闭环测试，特别是AEB及FCW触发后需要结合特定指标（相对速度、相对距离、TTC、T FCW 等）进行评估 。 根据执行条件编写评估脚本并对部分指标进行说明如图 13 所示。 图 13 评估脚本 TPT支持对被测模型一键生成闭环测试环境，具有丰富的内建函数以编写GUI评估或脚本评估，自动调用测试执行数据进行评估、生成定制化测试报告。Signal Viewer界面可对测试执行数据及评估结果观察调试，以CCRs执行数据为例如图 14 所示。测试用例评估结果及报告如图 15 所示。 图1 4 CCRs执行数据及评估：（a）测试车与目标数据；（b）感知信息及评估 图1 5 CCRs用例评估结果及报告：（a）测试用例评估结果；（b）测试用例报告 测试用例渲染展示 TPT支持与主流的智能驾驶场景工具（VTD、DYNA4、CarMaker等）进行集成。为了对搭建的测试用例进行更直观的理解，我们使用TPT调用场景工具进行渲染。 小结 TPT作为PikeTec公司研发的嵌入式系统模型动态测试验证工具，其图形化的测试用例搭建方式使得场景构建清晰快捷。TPT支持需求跟踪及自动化测试评估，可集成众多业内主流的工具平台和测试环境并实现测试用例复用，满足ISO2626对功能安全相关系统的生命周期所要求的所有测试活动，提高项目测试效率。 注：部分图片来源于E-NCAP

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 进行可视化测试: