随着仿真测试的应用范围逐渐扩大,传统的仿真测试标准已经不足以满足自动驾驶汽车的测试需求,因此,各个标准化机构也逐渐开始更新或新设仿真相关标准。图3-6总结了目前世界上相对通用的跨组织的仿真相关标准概览,并根据其在仿真中所属的模块进行了分类,主要分为基础标准、流程标准、方法标准和产品标准四类。需要注意的是,虽然已有大量标准来支持跨仿真工具链的汽车工程应用,但仍有大量需要通过标准来完善的领域急待补充。
图3-6 跨组织的仿真相关标准概览
1.静态特征标准
(1)ASAM OpenDRIVE
ASAM OpenDRIVE定义了一种精确描述道路网的文件格式。ASAM OpenDRIVE描述格式包含道路网络的所有静态对象,可以仿真道路上的车辆行驶,为了完整呈现真实环境,需要额外规定路边静态3D物体(如树木和建筑物)的描述格式。ASAM OpenDRIVE数据采用层级结构,并以XML文件格式进行序列化。
(2)ASAM OpenCRG
ASAM OpenCRG定义了一种描述路面的文件格式,最初开发用于存储路面扫描的高精度高程数据。这些数据主要用于轮胎、振动或驾驶仿真,凭借精确的高程数据,能够实现对车辆部件或整个车辆的真实耐久性仿真。驾驶仿真器可以实现真实的路面3D渲染,文件格式也可用于其他类型的路面特性,例如摩擦系数或灰色值。
(3)Khronos glTF
glTF(图形语言传输格式)是一种3D场景和模型的标准化文件格式。该标准阐明了引擎和应用的高效传输和加载(3D场景和模型)。glTF最小化了3D对象的大小,以及解包和使用它们所需的运行时处理。glTF最大程度地减少了3D资产,并简化了资产解包和使用所需的运行时处理。glTF定义了一种可扩展的发布格式,能够实现整个行业3D内容的互通性,以简化编写工作流程和交互服务。
(4)OGC CityGML
CityGML(城市地理标记语言)是一种用于3D城市和景观模型建模和交互的概念,在国际层面上被迅速采用。CityGML是用于表征城市3D对象的通用信息模型,在几何、拓扑、语义和外观属性方面,定义了城市和区域模型中最相关地形对象的分类和关系,包括专题类之间的泛化层次结构、聚合、对象之间的关系以及空间属性。与其他3D矢量格式相比,CityGML还基于丰富的通用信息模型,并涵盖几何和图形内容,能够在不同应用领域(如仿真、城市数据挖掘、设施管理和主题探究)使用虚拟3D城市模型完成复杂的分析任务。其目标应用领域明确包括:城市规划和景观规划、架构设计、旅游和休闲活动、三维地籍、环境仿真、移动电信、灾害管理、国土安全、车辆和行人导航、训练仿真器、移动机器人。
CityGML是一种开放的数据模型,采用基于XML的格式,可以存储和交换虚拟3D城市模型,将其作为地理标记语言3.1.1版(GML3)的应用模式,此标准为关于空间数据交换的可扩展国际标准,由开放地理空间协会(OGC)和ISO TC211发布。CityGML是OGC的官方标准,可以免费使用。CityGMLWiki是一个开放的门户,用于发布和共享有关CityGML的信息。但是,它不是CityGML的官方网站。
(5)NDS协会
导航数据标准(NDS)协会为导航系统中使用的地图数据提供标准。NDS规范包括数据模型、存储格式、接口和协议。NDS成员还可以使用一系列在线和离线工具,涵盖多个应用领域——从标准定义到NDS地图分析和转换。扩展机制能够实现各种用例的定制,并为各种用例提供支持。大多数NDS工具都与三大主流桌面平台(Windows、macOS、Linux)兼容,因此用户能够自由选择。NDS成员和地图覆盖范围包括北美、欧洲、中东、非洲和亚太地区,其中包括中国、韩国和日本。
2.动态特征标准
(1)ASAM OpenSCENARIO
ASAM OpenSCENARIO定义了一种文件格式,用于描述驾驶和交通模拟器的动态内容。ASAM OpenSCENARIO的主要用例是描述复杂的同步操作,涉及多个实体,如车辆、行人和其他交通参与者。
(2)ASAM OpenODD
ASAM OpenODD是一种标准化的、机器可读的格式,用于定义设计运行范围。
(3)ISO/FDIS 34501 道路车辆—自动驾驶系统测试场景—词汇
该标准规定了自动驾驶系统(ADS)测试场景的术语和定义。这些内容适用于ISO/SAE 22736中规定的3级及以上ADS。术语和定义标准是自动驾驶系统测试场景的基础,制定适当的国际标准将在支持自动驾驶车辆的测试、评估和管理方面发挥关键作用。该标准用于在全球范围内统一和标准化自动驾驶系统测试场景的术语和定义。
(4)ISO/FDIS 34502 道路车辆—自动驾驶系统测试场景—基于场景的安全验证框架
该标准为自动驾驶(AD)系统测试场景和基于场景的安全评估过程提供了指导和最先进的工程框架。工程框架阐明了在产品开发过程中应用的基于场景的总体安全评估过程。本指南和框架适用于ISO/SAE 22736中定义的3级及以上AD系统。
(5)ISO/DIS 34503 道路车辆—自动驾驶系统测试场景—设计运行范围分类方法
该标准规定了用于定义自动驾驶系统(ADS)设计运行范围(ODD)的分层分类法的基本要求。ODD包括静态和动态属性,可以用来开发测试场景,在测试场景中,ADS被设计用来运行。该标准还定义了ODD属性的基本测试程序。该标准适用于ISO/SAE 22736中规定的3级及以上自动驾驶系统。ISO/SAE 22736定义了设计运行范围(ODD)的概念。ODD的定义是确保ADS安全运行的基础,因为它定义了ADS的运行条件。
虽然世界范围内的自动驾驶行业可能会发展出不同的自动驾驶类型,但仍有必要为制造商、运营商和消费者提供关于ODD定义框架的指导,最终用户和监管机构应确保自动驾驶的安全部署。本文件将帮助自动驾驶制造商纳入ODD定义的最低属性,并允许最终用户、运营商和监管机构参考ODD定义的最低属性集。
(6)ISO/CD 34504 道路车辆—自动驾驶系统测试场景—场景分类
该标准定义了一种针对场景的分类方法,可以提供用于描述场景的标签属性信息。该标准适用于ISO/SAE 22736中规定的3级及以上自动驾驶系统。
(7)ISO/WD 34505 道路车辆—自动驾驶系统测试场景—场景评估以及测试场景生成
该标准提供了一种评估测试场景以及基于已知测试功能的、可被追溯测试能力的、从测试场景到测试用例的方法体系。本标准同时明确测试场景中的重要元素属性,包含但不限于测试初始化条件、测试激发条件、测试步骤、通过与不通过条件以及预期测试结果等。该标准同时描述测试用例逻辑关系,例如与真实世界、数据来源及数据库(如出现频率、危险程度、复杂程度)以及被测功能的关联性,又如设计运行范围的覆盖度的评价体系以及条件。该标准适用于ISO/SAE 22736中规定的3级及以上自动驾驶系统。
3.接口标准
(1)ASAM OSI
ASAM OSI是虚拟场景中自动驾驶功能环境感知的通用接口。用户可以将带有标准化接口的任何传感器连接到任何自动驾驶功能模块和任何驾驶模拟器工具上。
(2)AUTOSAR
汽车开放系统架构(AUTOSAR)实现了智能出行软件架构的标准化。该计划的主要目标是能够将软件模块交换为独立于硬件的软件应用程序的集成平台。每个软件应用程序(称为组件)都可以访问标准化的AUTOSAR API/服务,并且可以自由部署到目标车辆内的任何合适的设备上。
AUTOSAR经典平台基于OSEK,针对基于信号的通信进行了优化,可用于实时性和安全性要求较高的ECU;应用程序可以访问分层软件架构的运行时环境;内存服务、通信服务和I/O硬件抽象等都实现了标准化;可交付成果包括涵盖相关功能集的库;软件供应商提供的实施方案可以作为C软件栈使用。AUTOSAR通信服务允许访问CAN、COM、以太网、FlexRay、Lin、SAE J 1939、UDP和XCP,此标准还提供了相应车辆架构中多ECU环境XML系统的描述流程。
AUTOSAR自适应平台基于POSIX,并针对面向服务的通信进行了优化,可用于高性能计算系统。该平台由功能集群的API或服务构成,包括:更新和配置管理(OTA)、REST、身份和权限管理、诊断(UDS、DoIP)、日志和跟踪、通信管理(SOME/IP、DDS)、操作系统等。API和服务允许访问相应的硬件和功能,不同功能集群的API和服务包含C++标准库,应用构建基于此中间件的功能,提供了参考实现,称为演示器。
典型的AUTOSAR用例包括车联网应用和高度自动驾驶(ADAS),它们需要用于车辆网联、远程诊断和动态更新的出行服务。
(3)Modelica协会FMI—功能模型接口
功能模型接口(FMI)是Modelica协会发布的免费标准。此标准规定了一个容器和一个接口,可通过组合使用XML文件、二进制数以及将C代码压缩到单个文件中,完成动态模型交换。FMI规定了语义和应用程序接口(API),用于执行导入应用(如模拟器)的模型。它可支持动态模型的两种运行模式:模型交换(混合ODE系统访问)和协同仿真(求解器是FMU的一部分)。目前,最新发布的标准版本是FMI 2.0.2,当前正在制定的主要版本是3.0。
(4)ISO 23150道路车辆自动驾驶功能传感器和数据融合装置之间的数据通信—逻辑接口
ISO 23150标准属于ISO/TC 22/SC 31工作组,旨在实现车载环境传感器(如雷达、激光雷达、摄像头和超声波传感器)与融合装置之间逻辑接口的标准化,融合装置会基于传感器数据来生成环境模型,并呈现车辆周围场景。该接口采用模块化和语义表示,并提供关于对象级别的信息(如潜在移动对象、道路对象、静态对象等),以及关于特征级和检测级的信息和传感器技术特定信息。该标准未规定电气和机械接口要求,也不包括原始数据接口。
由于ASAM OSI SensorData接口与这些信息的关联性较高,因此在ASAM OSI制定项目期间,也考虑到了这两个标准之间的协调。
(5)Modelica协会SSP—系统结构和参数化
系统结构和参数化(SSP)标准是一种与工具无关的格式,用于系统结构描述、封装和交换,以及系统结构参数化。该标准包括一组基于XML的格式,用于描述组件模型网络及其信号流和参数化,还包括基于ZIP的封装格式,以便确保整个系统的有效分配,包括任何引用的模型和其他资源。该标准由Modelica协会发布,能够为组件的FMI采用提供大力支持,但不仅限于FMI组件。
4.架构标准
SAE J3131规定了自动驾驶参考架构,包含一些功能模块,能够为未来3级至5级(J3016)自动驾驶系统的应用接口提供支持。该架构将模拟以下内容:场景驱动的功能需求和非功能需求、自动驾驶应用、自动驾驶系统的功能分解以及相关功能域(即功能分组)。领域包括但不限于自动驾驶(即取代驾驶员的自动驾驶)、线控和主动安全,以及与故障和系统故障自动恢复相关的领域(例如,确保车辆处于安全状态的系统)。该架构将包含1级和2级功能分组。此文件将提供一个示例(将功能分为两个功能分组的实例),并详细说明各组之间的功能和信息接口。架构和边缘用例参考的SysML模型将解决高速公路上系统回退到最小风险状态的问题。SAE J3131是SAE国际道路自动驾驶(ORAD)计划的一部分。
5.自动化标准
(1)ASAM XIL
ASAM XIL(通用模拟器接口)实现了测试自动化软件以及X在环测试台架之间通信的标准化。该标准定义了测试台API(ECUC、ECUM、MA、网络、EES、诊断端口)和框架API(面向对象的端口、独立访问变量)。模型访问端口是一个中心接口,用于管理XIL模拟器上运行仿真模型的访问。此端口允许对仿真模型进行读写访问、测量(捕获)设置、激励生成、目标脚本执行,以及模型变量和任务的元数据检索。
诊断端口通过诊断系统读取来自ECU的诊断服务数据。ECUM和ECUC端口通过MC服务器访问ECU。ECUM具有测量和捕获功能,ECUC具有校准和CAL页面管理功能。由于ECU通信由相应的MC服务器或D服务器封装,因此XIL API不需要提供任何关于ECU通信的接口信息。
电气错误模拟端口为电气错误模拟硬件提供通用API。API可以隐藏使用过的硬件、驱动软件和通信。EES端口以抽象方式提供了一组已定义的功能,例如不同类型错误的设置。网络端口旨在提供总线通信的标准化访问,以便监测和传输总线数据。此端口具有CAN帧读写访问功能、CAN帧捕获设置以及CAN帧回放功能。
该标准包含C#和Python技术参考文件、XIL支持库、测试套件、模式和通用UML模型。程序集作为安装程序分发。
(2)Modelica协会DCP—分布式协同仿真协议
分布式协同仿真协议(DCP)标准是Modelica协会发布的应用级通信协议,旨在将模型或实时系统集成到仿真环境中,可以利用底层传输协议(如UDP、TCP或CAN)实现模拟相关配置信息和数据的交换。此外,DCP有利于集成不同供应商的工具和实时系统,旨在提高基于仿真的工作流程效率,并减少集成工作量。DCP的设计考虑到了FMI兼容性,但并不局限于FMI或软件模型。
6.领域表达/分类标准
(1)ASAM OpenXOntology
ASAM本体提供了ASAM OpenX标准涉及的上路行驶领域模型,规定了交通基础设施、交通参与者相互作用和环境条件的词汇。这也将促进ASAM OpenX中人工智能的使用。该标准将在以下方面提供指南:
1)可以利用ASAM OpenXOntology的不同工具工作流程。
2)关于如何实现ASAM OpenXOntology的各个ASAM OpenX标准。
3)为应用特定用例扩展本体。
4)每个ASAM OpenX标准的迁移/阶段化示例。
(2)ASAM OpenLABEL
ASAM OpenLABEL是一种通用格式,可用于自动驾驶功能开发期间创建的传感器数据和场景的注解。此格式是机器可处理且人员可读的。它包括一个用户指南,阐释了用户如何使用ASAM OpenLABEL支持的可用标记方法,包括:标记方法、标记结构(包括关系)、文件格式和结构定义、场景标记。
(3)AVSC000022202004
自动驾驶车辆安全联盟(AVSC)制定了描述设计运行范围的最佳实践(SAE工业技术联盟于2020年发布的“AVSC描述设计运行范围的最佳实践:概念框架和词汇”)。这个框架有助于为设计运行范围建立通用分类和描述,以支持设计运行范围开发人员和用户之间的一致性。
AVSC是一个由汽车行业公司组成的联盟,这些公司致力于自动驾驶车辆的测试和路试。该联盟的目标是建立公众和自动驾驶车辆制造商之间的信任,实现目标的特定方式之一是制定开发商需遵循的最佳实践。联盟正在制定一份路线图,该路线图概述了与自动驾驶行业相关的多个主题,以便为行业内的合作提供支持。
(4)SAE J3016/SAE J3164/SAE J3206
这些标准是SAE国际道路自动驾驶(ORAD)计划的一部分。ORAD委员会负责制定并维护关于自动驾驶功能的SAE标准和内容,包括从3级到5级(参见SAE J3016的定义)。该委员会由多个工作组构成。上述标准由以下工作组推动:
1)SAE J3016:分类和定义——道路驾驶相关术语的分类和定义。
2)SAE J3164:操作和行为——道路自动驾驶系统(3~5级)的特性和操作定义、分类和最佳实践。
3)SAE J3206:验证和确认——支持自动驾驶系统验证与确认的定义、信息、最佳实践和测试方法。
7.测试规范
ASAM OTX(开放测试交换格式)是一种独立于平台和测试人员的交换格式,用于ISO 13209(OTX)中标准化可执行测试序列的形式描述,允许跨部门、工具和进程边界进行测试序列的交换。存储在序列中的专有技术不会丢失,即使多年后仍可以重新使用。
OTX是一种基于XML的领域特定编程语言,测试序列是使用编写系统创建的。测试的创建流程不需要编程语言或所用API(封装了从运行时系统到相应硬件的访问信息,例如用于车辆诊断的MVCI服务器API)的知识,开发人员便可着重关注被测进程。对于符号级测试序列的形式描述,可以采用图形、文本表示(伪代码)方式,开发人员也可以采用编程语言(如C#或JAVA)完成描述。此外,OTX还基于测试序列创建、维护和执行的实践经验,规定了各种基本概念。例如,可以在第一步中定义基本测试序列,而不必描述确切的技术细节,然后由相应专家进行补充,以便首先创建可运行的描述。将设计(编写系统)和执行(运行时系统)分离,便可以使用代码生成器转换相应目标平台(Windows、Linus、嵌入式)的测试,且不会丢失任何测试内容。
凭借标准化的扩展机制,可以使用新库来扩展OTX。因此,ASAM OTX扩展还具有其他常规可用的OTX功能,包括:文件的常规读写访问;XML处理;存储当前运行时的任意信息;配置任务;将OTX扩展到封装在外部服务、系统、设备、数据库或简单库中的功能;捕获、评估和保存测试序列的结果;从序列内部向环境传输状态信息;先进的便利功能;在运行时收集通信数据;访问SQL数据库;以结构化方式评估测试序列结果;状态机;压缩数据交换(采用容器格式)。
在车辆生命周期中,OTX在开发、生产和车辆使用(售后和车辆内部)期间得到了成功的应用,从而成功实现了测试序列(已经过验证和实地试验的测试序列)的交换和存档目标。ASAM OTX扩展包含每个OTX扩展的XSD模板和一个公共UML模型。
8.数据处理
(1)ASAM MDF
ASAM MDF(测量数据格式)是一种二进制文件格式,用于存储测量或计算的数据,以便进行测量后处理或长期保存。拟存储数据的常见来源是传感器、ECU或总线监控系统。ASAM MDF能够实现高性能的信号数据读写,可以支持行式存储(非常适合写入)和列式存储(对读取性能进行了优化)。除了简单的测量数据外,ASAM MDF还在同一个文件中存储描述性和可定制的元数据。
信息存储的定义基于以下用例:
1)总线日志:存储公共总线系统的流量。
2)分类结果:以一维或二维方式存储带描述的分类结果。
3)测量环境:描述命名约定,以存储关于如何获得测量结果的信息。
4)通道和通道组命名:描述如何为常见用例设置通道和通道组的不同名称,以向用户提供重要信息并实现通道的唯一标识。该标准包含用于元数据描述的XML模式。
(2)ASAM ODS
ASAM ODS(开放数据服务)定义了通用数据模型(用于测试数据的通用解释)、接口(用于模型管理、数据持久化存储和数据检索)以及数据交换语法和格式。ODS服务器是通过HTTP协议访问的,协议具有Protobuf序列化、CORBA或RPC。
ASAM ODS区分了基础模型(对于所有类型的应用,基础模型是唯一的)和应用模型(仅针对应用)。对于该模型中的所有应用元素,都知道与其相关的基本元素类型。此外,还定义了基本元素的维度和单位、管理、测量、安全性以及描述性数据。针对以下常见用例定义了应用数据模型:
1)总线数据:支持CAN、LIN、FlexRay、MOST和以太网消息。
2)几何构造:例如用于传感器位置的坐标系。
3)噪声、振动和声振粗糙度。
4)工作流:基于Petri网的概念。
5)校准:例如来自传感器和放大器的试验台数据。
此外,该标准还提供了一个大数据连接器,用于描述如何将实例数据和海量数据呈现为ODS数据存储库的导出数据,以用于大数据分析系统(如HADOOP)。导出定义为Avro、JSON和Parquet。ASAM ODS还支持在ASAM MDF中存储二进制测量数据。该标准包含XML模式、Google协议缓冲区、Step-Express文件、IDL描述、RPC接口和xsd文件。ASAM ODS不仅允许存储实际测量数据和描述测量数据,还可描述测试执行所需的参数数据。
1.功能安全标准
(1)AVSC000012011911
自动驾驶车辆安全联盟(AVSC)为车载后备测试驾驶员的选择、培训和监督程序制定了最佳实践(SAE工业技术联盟于2020年发布“被测自动驾驶车辆车载后备测试驾驶员的选择、培训和监督程序的AVSC最佳实践”)。它描述了在公共道路上适当监督4级和5级自动驾驶车辆测试的资格和培训。
(2)ISO 21448:2022 道路车辆—预期功能安全
ISO 21448:2022是由ISO/TC 22/SC 32工作组制定的,目的是为实现预期功能安全(SOTIF)所采用的适用设计、验证和确认措施提供指导,用于证明由于预期功能的功能性不足或人员可合理预见的误用而导致的危害不存在不合理的风险。此标准不适用于ISO 26262系列所涵盖的故障,也不适用于系统技术直接造成的危险(如激光传感器造成的眼睛损伤)。
该标准的目的是应用于预期功能,其中适当的态势感知对安全至关重要,并且态势感知源自复杂的传感器和处理算法。在识别危险事件时,将预期用途和合理可预见的误用与潜在的危险系统行为结合起来考虑。合理可预见的误用可能直接导致潜在的危险系统行为,也被视为可能直接触发预期功能安全相关危险事件的事件。故意更改系统操作被视为功能滥用,功能滥用不在该标准的范围内。
(3)ISO 26262系列
由ISO/TC 22/SC 32工作组制定的ISO 26262系列标准适用于安全相关的汽车电子电气系统,它包括一个或多个电气电子(E/E)系统。该标准涉及安全相关电气电子系统失灵可能造成的危险,包括这些系统的交互作用;不涉及与电击、火灾、烟雾、热量、辐射、毒性、易燃性、反应性、腐蚀、能量释放有关的危险以及类似危险,除非是由安全相关电气电子系统失灵直接造成的危险。
该标准描述了功能安全框架,以协助开发安全相关的电气电子系统,并将功能安全活动整合到公司特定的开发框架中,既包括明确的技术重点,以便在产品中实现功能安全,也涉及企业开发过程,即过程要求,以证明企业在功能安全方面具备相应的能力。
2.信息安全标准
ISO/SAE DIS 21434国际标准是由ISO/TC 22/SC 32工作组制定,旨在解决道路车辆电气电子系统工程中的信息安全问题。使用该标准有助于制造商跟上不断变化的技术步伐,同时应对网络攻击。该标准还可用于实施信息安全管理系统,包括道路车辆信息安全风险管理等。
(1)ISO 11010乘用车—模拟仿真模型分类
ISO 11010是由ISO/TC 22/SC 33制定的,为道路车辆开发和测试模拟仿真中采用的模型分类提供标准。此标准的主要目的是提供一个框架,利用该框架,可以系统地分配某些应用、所需仿真模型的驾驶操作及其元素和特性。该标准将仿真模型分为若干模型类别、名称编号和相关元素、特性和常用建模方法。
(2)SAE J3018/SAE J3092
这些标准是SAE国际道路自动驾驶(ORAD)计划的一部分。ORAD委员会负责制定和维护关于自动驾驶功能的SAE标准和内容,包括从3级到5级(参见SAE J3016的定义)。该委员会由多个工作组构成。上述标准由以下工作组推动:
1)SAE J3018:道路试验指南——车辆配备原型自动驾驶系统(3~5级)时的安全道路测试指南。
2)SAE J3092:验证和确认——支持自动驾驶系统验证和确认的定义、信息、最佳实践和测试方法。
联合国欧洲经济委员会(UNECE)通过了一项关于客车自动车道保持系统(ALKS)的国际法规—UN-ECE第157号法规。自动车道保持系统是一种车辆技术,可以在没有驾驶员进一步指令的情况下长时间控制车辆的横向和纵向运动。在此期间,系统主要控制车辆,代替驾驶员执行驾驶任务。在某些情况下,可以启用自动车道保持系统,如车辆行驶在禁止行人和骑行者的道路上。根据设计,这些道路装有物理隔离装置,以分隔对向行驶的交通工具。目前,该法规将自动车道保持系统的运行速度限制在最高60km/h。这是第一个由50多个成员国商定的自动驾驶功能(SAE 3级)认证法规。它规定了以下方面的安全要求:
1)即将发生碰撞时的紧急机动。
2)当系统要求驾驶员收回控制时的过渡需求。
3)最低风险策略:当驾驶员未响应过渡需求时,在所有情况下,系统应将车辆乘员和其他道路使用者的安全风险降至最低。
为建立此法规的基础,联合国欧洲经济委员会还通过了网络安全和软件更新法规。
如今,汽车行业已经就场景四层抽象分级模型(功能场景-抽象场景-逻辑场景-具体场景)达成了共识,同时也开展了大量的基于此分级模型的仿真应用研究。本章系统介绍了符合自动驾驶系统DevOps周期的场景仿真环境抽象架构,并从基础标准、流程标准、方法标准和产品标准四个层面总结归纳了当前国内外相对使用广泛的场景仿真工具链标准。可以看到,作为一个新兴的领域,尽管已经有大量已发布或正在制定/修订中的标准可以用于场景仿真工具链的集成,但这中间仍然存在一个较大的空白,基于场景的仿真测试方法想要满足当前世界上对于自动驾驶功能的测试需求,不论是在开发阶段还是验证阶段,不论是用于政府监管还是企业研发,都还有相对较长的路要走。