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