标签: 场景仿真

汽车行业中，任何一款产品的上线都离不开测试工作，在整个测试 工作 中， 测试人员通过使用不同的测试技术来创建测试用例，保证测试活动的全面性和高效性。 根据ISTQB可以将测试技术分为黑盒、白盒 和 基于经验的测试技术 ： ① 黑盒测试技术（ behavioral or behavior-based techniques ） ：它不依赖于代码的实现细节，而是基于测试依据 （如：正式需求文档、规格说明、用例、用户故事或业务流程） 来测试 被测对象 的正确性和完整性 ， 它 关注 被测对象 的输入和输出，而不考虑其内部结构。 ② 白盒测试技术（ structural or structure-based techniques ） ：主要 通过对架构、详细设计、内部结构或测试对象代码进行分析。与黑盒测试技术不同，白盒测试技术关注 被测对象 的结构和处理过程。 ③ 基于经验的测试技术 ： 利用开发人员、测试员和用户的产品经验来设计、实施和执行测试。这类技术通常与黑盒和白盒测试技术相结合。 以上是较为常用的测试技术分类 ， 测试人员需要结合具体项目需求和测试目标，选取合适的测试技术 来进行测试用例开发 。 目前汽车行业中使用的 V2X（ Vehicle to Everything ）技术是智能交通系统中的核心技术之一，具有广泛的应用前景。V2X技术可以让车辆之间相互通信，实时 获取其他 车辆 的 位置、状态、行驶方向等信息，同时也可以获取周围道路状况、交通信号灯、行人等信息，以此来提高驾驶安全性、舒适性和效率 。 针对 基于场景的V2X功能 测试来说， 测试用例的开发一般是 由 黑盒测试 技术 中的 等价类划分和边界值分析 。等价类划分和边界值分析是测试中常用的两种测试用例设计方法，它们一起使用可以更全面地覆盖输入域，在发现潜在缺陷的同时，也提高了测试的效率。目前，北汇信息在测试用例开发方面有了完整 流程 ，大致总结为以下几个步骤： ①识别输入域：根据需求文档、功能规范或技术协议等资料，确定需要进行测试的输入域。 ②等价类划分：将输入域划分为若干个等价类，每个等价类代表着一组具有相同特征的输入值。 ③边界值分析：对每个等价类，确定其边界取值并分析。 ④组合等价类和边界值：针对测试需求进行功能点整理，主要是提取需求中的等价类，其提取依据是该等价类是否会对被测件的功能产生影响。等价类分为“路网”、“参与者 ” 、“事件板”。其中，路网是指对场景运行道路的说明，包括：车道类型、车道数量、标牌类型、信号灯等；参与者指的是场景参与者，包括：车辆、行人和树木、路灯等物体；事件板是指参与者的行为，包括参与者的初始状态和运行过程中的行为变化。初始状态包括位置、朝向和速度等。然后将不同等价类中的边界值组合起来构造测试用例。 ⑤设计优先级： 优先级需要考虑 ： 功能关键性或重要程度 、 与安全相关的功能 、 功能完成 度、 功能当前验证条件满足性 。根据测试优先级确定测试用例重要程度，并按照优先级顺序进行筛选测试用例。 下面以《 合作式智能运输系统车用通信系统应用层及应用数据交互标准（第一阶段）T/CSAE 53-2020》标准 中的前向碰撞预警 （ FCW ） 场景进行举例，详细介绍测试用例开发方法 ： FCW功能定义：主车（HV）在车道上行驶，与在正前方同一车道的远车（RV）存在追尾碰撞危险时， FCW功能通过HMI对HV驾驶员发出预警 ，帮助驾驶员避免或减轻前向碰撞，提高道路行驶安全。 CSAE 53-2020 中介绍了以下四种FCW的 主要场景。 场景一：HV行驶，RV在HV同一车道正前方停止： 1)HV正常行驶 ， RV在位于HV同一车道的正前方停止； 2)HV和RV需具备短程无线通信能力； 3 ) HV行驶过程中在即将与RV发生碰撞时， FCW功能通过HMI对HV驾驶员发出预警 ，提醒驾驶员与位于正前方的车辆RV存在碰撞危险 ； 4)预警时机需确保HV驾驶员收到预警后，能有足够时间采取措施，避免与RV发生追尾碰撞。 场景二：HV 行驶，RV 在HV相邻车道前方停止： 1) HV 正常行驶，RV 在位于 HV 相邻车道的前方停止； 2) HV 和 RV 需具备短程无线通信能力； 3) HV 行驶过程中不会与 RV 发生碰撞， HV驾驶员不会收到HMI发出的FCW预警信息 。 场景三：HV 行驶，RV 在HV同一车道正前方慢速或减速行驶： 1)HV正常行驶，RV 位于HV同一车道的正前方慢速或减速行驶； 2)HV和RV需具备短程无线通信能力； 3)HV行驶过程中在即将与RV发生碰撞时， FCW功能通过HMI对HV驾驶员发出预警，提醒驾驶员与位于正前方的车辆RV存在碰撞危险 ； 4) 预警时机需确保HV驾驶员收到预警后，能有足够时间采取措施，避免与RV发生追尾碰撞。 场景四：HV行驶，HV视线受阻，RV-1在HV同一车道正前方停止： 1)HV跟随RV-2正常行驶，RV-1在同一车道上RV-2的正前方停止，HV的视线被RV-2所遮挡； 2)HV和 RV-1 需具备短程无线通信能力，RV-2 是否具备短程无线通信能力不影响 功能 场景的有效性； 3)RV-2为了避开RV-1进行变道行驶； 4)HV行驶过程中在即将与RV-1发生碰撞时， FCW功能通过HMI对HV驾驶员发出预警，提醒驾驶员与 位于正前方的RV-1存在碰撞危险 ； 5)预警时机需确保HV驾驶员收到预警后，能有足够时间采取措施，避免与 RV-1发生追尾碰撞。 根据以上场景，将对FCW功能产生影响的因素通过等价类划分和边界值分析方法将其分为路网、参与者、事件板，分类如下图所示。 结合FCW 功能文档 以及测试的优先级对其组合的case进行筛选整理，最后生成完整的测试用例。 根据以上测试用例 开发流程可以提高 被测系统的覆盖面，进而提高测试的有效性和全面性 ，能够更全面地发现潜在的缺陷和问题，保障被测件功能健全。 北汇信息作为蜂窝车联（C-V2X）工作组成员， 持续深耕 V2X 测试领域，测试 方案覆盖终端接入层一致性、协议栈一致性 、 场景功能测试 和信息安全测试等 ，为客户提供专用测试设备、成熟的测试解决方案和测试服务， 让汽车变得更安全、更舒适、更智能 。

随着智能驾驶领域的快速发展与普及 ，激光雷达的轻量化、电子化和芯片化也逐渐成为趋势。由于激光雷达不受光线影响、分辨力高、支持3D立体，点云还支持AI算法训练等优点，一些主流车型在L3级别的智驾功能应用上搭载了激光雷达，从而完成更可靠和准确的目标探测。 在L2+或L3级以上的智驾功能应用中 ，激光雷达可提供更高精度的融合定位和目标识别能力，也可基于丰富的点云信息完成高精地图的绘制。激光雷达发送和反射的追踪光线可通过不同材质的反射率可以识别到更加丰富的目标类型。 但是，在实验室环境下的智能驾驶HiL仿真测试阶段 ，采用真实激光雷达无法获取动态的环境信息，需要通过场景软件来进行动态场景仿真，从而完成周边感知环境信息的构建，此时需要进行激光雷达模型搭建和点云仿真。本文将介绍激光雷达的基础原理及仿真测试流程，希望能帮助应用者更好的理解激光点云的仿真过程。 01 什么是激光雷达 在讨论所有问题之前 ，需先了解激光雷达的基本组成结构，激光雷达主要由激光发射器、激光接收器以及激光计算单元组成。激光雷达的分类很多。常见的有机械旋转式、MEMS、转镜式、Flash等等。 以机械式激光雷达来简要说明其工作原理 。激光雷达通过激光发射器将生成的激光光束向外发出，通过伺服电机与反光镜后，激光光束将被反射到各个方向，反射到周围环境中的激光会一直往前飞行，当激光在飞行途中与障碍物相交时，会触发激光产生折射或反射等现象，而反射的部分激光会原路返回至雷达的激光接收模块，最后通过计算单元解析生成点云数据。 图 1激光雷达工作基本原理图 在智能驾驶辅助车辆广泛应用毫米波和超声波雷达等传感器进行目标感知的前提下， 为什么还要使用激光雷达呢？ 激光雷达的广泛应用 （1）对于其他传感器来说，由于激光的传播速度为光速，因此这让 激光雷达有很好的静态和动态探测能力 。 （2）其丰富的点云信息可勾勒出目标轮廓，也可用于目标距离、方位、高度、速度和姿态信息的探测。相比于其他传感器， 激光雷达探测精度和抗干扰能力更好，且能够比传统毫米波多探测一个高度的信息 。 （3）在日益复杂和多元化的交通环境下，需要用到多传感器融合来感知自驾车辆周边环境， 激光雷达可与其他传感器（如摄像头、毫米波雷达等）进行融合定位以提供更精确的环境感知 。 （4）在一些L3级智驾功能策略及应用场景上， 激光雷达目标设备优先级比较高 ，如Camera识别到目标但Lidar没识别到，感知算法融合后会判定没有目标，此时会极大影响后续的规划控制算法，从而影响智驾功能。 所以 ，在车辆高速环境下对静态物体的识别、远距离场景对行人及其他交通环境目标的识别，需要更加准确和类别化，激光雷达在高级智能驾驶的应用变得尤为重要。 在当前L2+ 和L3及以上智驾场景中 ，激光雷达由于产品芯片量产和技术的提高，价格也逐渐亲民化，因此在一些典型的中高端车型中逐渐趋向量产化。 02 激光雷达如何仿真 了解了激光雷达的基本工作原理后 ，可按照此原理来对激光雷达进行仿真，真实的激光雷达光线其实是从传感器发出到最后返回到传感器。那么在实际工程实践中，有没有一种方法来实现光线发射及反射来回过程的仿真呢？其实是有的——光线追踪（Optix）。 光线追踪 什么是光线追踪？在现实生活中，看到物体的完整光路历程如下图2所示。首先光源发出光线，光线在飞行过程中遇到障碍物后发生反射，反射的部分光线被人眼接收，最后在视网膜上生成图像。而光线追踪就是将这个过程反过来， 光线由眼睛发出，最后通过复杂的光路历程回到光源处 ，这就是光线追踪。 光线追踪步骤 1、创建从环境到传感器光路的相反路径。 2、光线击中目标对象。 3、计算光线属性。 4、将光线属性写入缓存。 图 2光线追踪原理图 使用NVIDIA的OptiX API来完成上述工作 ，OptiX是一个在GPU上实现高性能光线追踪的应用程序框架，它提供了一套完整灵活的光线追踪算法。 图 3 Optix处理的基本逻辑 如图3 ，在知道基本的仿真逻辑以及明确了仿真数据之后，就可以编译相应的激光雷达模型了，编写完之后的激光雷达模型将会同仿真一起完成一系列复杂的计算过程，经过创建及配置光线、运算光线追踪算法和数据处理，最终输出需要的点云数据。 点云数据 想要知道点云数据具体包含的内容，首先需要解释一下点云是什么。 点云就是某个坐标系下所有点的数据集群。而点云数据就是表示包含三维坐标XYZ、颜色、强度值等的数据集群 。既然点云数据包含的点是三维坐标，然么激光雷达光线的出射方向该如何实现仿真呢？ 为了使仿真的激光雷达光线的出射方向与真实激光雷达保持一致 ，需要将真实的激光雷达光线的出射角度转换成三维方向坐标后打包生成dat数据文件，在编译激光雷达模型时引入此dat文件作为入参，即可实现非均匀打点方式的仿真了。 图 4非均布打点激光雷达扫描场景 通过对OptiX过程以及点云数据的理解 ，可以根据实际需求来仿真激光雷达，编辑相关的激光雷达仿真模型。最后，通过Optix支持对光线缓存结构的数据写入与传出支持。在激光点云仿真过程中，可以编辑光线缓存结构来定义需要的点云数据。 03 点云数据处理 了解了点云数据之后 ，通过搭建仿真场景以及加载编译好的激光雷达模型，就可以进行点云数据的处理了。 点云数据的处理是根据不同激光雷达产品的通信协议来说的，如图5为一个简单的示例。 图 5简易的雷达协议结构 不同的激光雷达产品可能在通信协议或组包结构上都各不相同 ，需要依据实际情况对点云数据进行重构组包。为了更方便的处理这些点云数据以及后期整体工程的管理，在后续工作中使用CANoe来完成组包的工作。 激光雷达的雷达协议大致包含包头信息、设备信息、时间戳 ，测距信息等等。有关包头、设备信息等信息，可通过产品说明书对其进行确定。而测距信息里面存放的就是仿真的点云数据，一般激光雷达协议中的点云数据有固定的排列方式，这部分就需要按照不同激光雷达产品的通信协议来确定。 由于点云数据量庞大 ，对点云数据的处理组包，可以通过CANoe的总线仿真功能来完成这部分工作。CANoe支持多种数据的解析，可以使用其内置的函数对来完成点云数据组包工作。 CANoe提供了良好的管理平台和丰富的内置函数来辅助完成这部分工作： 1.首先，在CANoe中建立接收的套接字和发送的套接字，此时可以拿到仿真的点云数据，并对数据进行解析以进一步进行后处理。 2.在解析完点云数据之后，可按照真实激光雷达的UDP组包协议来将解析完成的点云数据填充至相应的UDP结构内，同时将部分信息保存至系统变量，以便后期实现传感器数据相关的故障仿真等等。 3.最后，在将一帧的完整点云数据组包完成之后，通过建立的套接字来将数据发送至目标IP或激光雷达的上位机进行验证。 至此，即可完成激光雷达的基本仿真流程。 图 6仿真环境（上图）仿真激光雷达（下图） 在智驾HiL应用阶段 ，激光点云数据在实现L2+或L3级功能测试的过程中尤为重要，在获取到激光雷达仿真的点云数据后，可使用CANoe进行智驾域控制器的闭环验证。 1.比如获取仿真的激光雷达点云数据、毫米波数据和视频流数据等，验证域控制器的感知融合算法； 2.使用激光雷达点云数据与其他仿真数据，通过CANoe将不同的总线协议信号一起注入给智驾域控制器，实现ACC、AEB等规控功能的验证； 3.通过CANoe直接处理的点云数据，也可实现对激光雷达进行通道故障、点云丢失、帧数据不同步等仿真，从而验证域控制器的功能安全机制。 04 总结 至此 ，激光雷达基础介绍与仿真测试流程到这里就正式结束了。北汇信息作为Vector的技术合作伙伴，覆盖智能驾驶系统MiL/HiL/ViL测试、车联网测试，传感感知测试等，为客户提供优质的智驾测试解决方案、测试集成系统和服务，助力智能驾驶仿真测试系统的快速验证和测试。 如果您有这方面的需求 ，可以直接关注北汇公众号，期待您的持续关注。

随着汽车行业的蓬勃发展，与之相关的自动驾驶功能越来越受到人们的关注。 自动驾驶给人们带来方便的同时，也带来了某些安全隐患。为了最大程度的确保安全，除了要进行功能逻辑测试外，也需要进行功能 场景测试 （比如鬼探头、多岔路上坡等场景）。 目前主流的场景测试工具有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 进行可视化测试: