目的是确定所有相关的标准、潜在的工作流程及其变体,并了解这些部分之间的整体相互作用,形成一个有凝聚力的整体。这种分析最终应形成一套基于场景测试的总体用例文件,一套实现这些用例的潜在工作流程,以及确定的角色、标准及其应用。任何已确定的工作流程中的差距都应被描述出来,从而确定现有标准可能需要增加的内容,甚至需要全新的标准。
·汽车行业中非盈利的标准制定组织
·注重执行层面的标准(而不是ISO/SAE等流程层面的标准)
·ASAM标准是建议,对监管框架没有影响。
·开放的、非竞争性的标准制定小组
·成员推动的标准化项目
在自动驾驶行业,对于基于场景的测试中场景和测试之间的互动,以及如何与其他既定的测试工作流程(许多是独立于场景的)相关联,明显缺乏明确性。
有潜在的信息重叠,例如测量/成功标准和场景测试。与DUT参数化,更不用说多样化的工具环境了。
这导致了标准化环境的混乱,直接阻碍了标准的制定。采用,从而在行业内进行合作
为了建立明确的工具链和标准化的情景/测试描述交流,需要明确:
ASAM计划从现阶段到明年四月,制定标准,收集标准,定义用户、用户案例、用户工作并定期评估。
以场景为基准的测试可以分为以下步骤:
管理/设计逻辑性场景
在这一步骤中,场景开发者负责:定义和配置道路、主车、对手车、传感器、交通流、天气状况等场景元素。并保证场景重复利用度高。创建好的场景放置在场景库数据库中。
创建逻辑性测试
测试开发人员,选择要测试的场景,然后定义V-ECU,不同的可调节参数,观测设备,数据分析
选择逻辑性测试
变量控制逻辑测试
执行测试
测试执行人员 根据仿真参数进行具体的测试,分配/监管/监测计算资源,
协调数据传输,监测测试执行情况。
分析测试结果
测试后,生成报告, 供开发人员和决策人员分析。
整车测试包含了动力总成测试、底盘测试、信息娱乐系统测试、ADAS功能测试。这些测试都可以通过SIL,MiL,HiL,ViL进行。
·需求、测试、平台之间的框架:
在获取了逻辑场景、测试案例具体规范和需求后,即可实施测试案例。通过对测试的变量控制、执行测试得到测试结果。可视化地分析测试结果。
需求:主动紧急制动辅助
测试案例:首先根据需求,定义先决条件,要准备好初始化的模型,并连接模型和功能相关代码。其次,配置好测试内容,时刻检查AEB是否处于激活状态,包括引擎运转前中后。最后,保持监测系统是否运转正常。
需求:ADAS/AD功能检测到传感器的故障。没有发生碰撞,TTC也不是很严重。
测试案例:首先根据需求,初始化系统,并配置好系统。然后将系统接入不同的测试场景,对传感器进行控制变量,找出问题。
SiL中场景部分按OpenSCENARIO和OpenDrive标准进行定义,然后场景进行联合仿真,完成SiL仿真。
·举例:HiL的需求和测试案例
需求:解决高速公路巡航系统在常规场景不能替代驾驶员工作的问题。
测试案例:域控制器连接各个传感器,输入到仿真环境中。核对在不同场景工作下域控制器报错状态,确认功能是否完善运转。
·举例:ViL的需求和测试案例
需求:解决高速公路巡航系统在常规场景不能替代驾驶员工作的问题
测试案例:准备测试的高速场景,启动高速巡航系统,核对错误信息。
Scenario-Based Testing 需要能够管理测试流程的平台。
具有发布需求、测试条件、测试场景、测试案例、被测软件并能兼容不同平台的需求。能够管理,监测仿真和在环测试。最终,输出测试结果,以报告、日志、视频等方式可视化分析结果。
测试管理系统的特点:
·能分析测试结果数据、
·监管虚拟测试完成度
·回放测试
·覆盖率导向来验证功能
·输出报告
·规划下次测试内容
BMW在会议中主要讨论了一种关于软件接口分层的方法。即场景部分采用ASAM标准下的OpenSCENARIO标准,由场景仿真软件和环境仿真软件调用;测试案例由测试软件调用;整个测试流程由测试管理软件和需求管理软件调用。
文件格式也需分层
场景部分:虚拟世界生成脚本;不同视角可视化脚本;地图环境模型
测试案例部分:
(初始化部分)需求和测试安利的可追溯性关联文件;建立正确的仿真场景;仿真执行命令
(执行部分)错误提示,错误记录,运行时间评估,运行后评估
(完成部分)存储结果,清空准备下一次案例
测试总览部分:列出测试案例清单,测试用例分发给测试人员,导出测试结果,宏观调控SIL/HiL/ViL
分层方法的优点