标签: 实车测试

引言 往期内容里为大家介绍了OTA技术、OTA后续的发展趋势预测及OTA自动化测试解决方案。本文是OTA系列的第三篇文章，今天主要向大家介绍实车级OTA自动化测试的实现手段，并简单介绍北汇信息的实车级OTA自动化测试解决方案—— PAVELINK.OTABOX。 实车级OTA自动化系统 目前，OTA自动化测试系统的落地方式主要包含以下三种： 系统级OTA通道测试系统 覆盖的测试范围：覆盖刷写前的准入条件验证，刷写中的诊断交互过程监测、系统刷写响应异常、系统故障（被刷写节点丢失），刷写后的刷写时间、版本信息读取及收集、ECU状态确认等各种正向和逆向场景，这种OTA自动化测试系统的灵活性较高，具有很强的二次开发潜力 优点：测试需求覆盖度广、不依赖实车环境进行测试 缺点：该测试系统成本较高、开发周期较长 系统级OTA压力测试系统 覆盖的测试范围：覆盖包括用户车内触发/手机APP触发、预约安装/直接安装、同基线版本/高版本退低版本/低版本升高版本的各种压力测试场景 优点：可24小时不间断运行、不依赖实车环境进行测试 缺点： 测试需求覆盖度较小，只能覆盖压力测试场景 实车级OTA压力测试系统 覆盖的测试范围：可覆盖上述系统级OTA压力测试的全部测试内容，且具有在高温高寒环境（-20-+40℃）下执行测试的能力 优点：可24小时不间断自动化运行、落地周期短、价格较低、可批量复制性强、测试人员需求较少 缺点：依赖实车环境进行测试，测试需求覆盖度较小， 只能覆盖压力测试场景 上述三种OTA自动化测试系统分别有各自的优劣势和特点，因此OEM可根据测试需求进行灵活的选择最适合的方案。 今天介绍的实车级OTA自动化测试系统主要适用于以下场景： 期望在实车环境下验证车辆OTA链路的稳定性 只需覆盖压力测试场景：因为实车环境进行测试的限制，因此实车级OTA自动化测试系统无法覆盖通道测试内容，只能覆盖压力测试场景，进行24小时不间断运行测试 测试成本及落地周期较低：相比较于系统级OTA测试系统，实车级OTA自动化测试系统具有价格低、落地周期短的优势，因此适合预算较低及需要快速投入使用的OEM 需要进行批量复制：相比较于系统级OTA测试系统，实车级OTA自动化测试系统具有可批量复制性强的优势，因此适合需要批量使用测试系统的OEM 需要在恶劣环境下进行测试：相比较于系统级OTA测试系统，实车级OTA自动化测试系统具有在高温高寒环境（-20-+40℃）下执行测试的能力，因此适合需要在恶劣环境下进行测试的OEM PAVELINK.OTABOX解决方案 鉴于以上实车级OTA自动化测试的特点，北汇信息在对各主流OEM的OTA流程做了深入分析后，推出了通用化的实车级OTA自动化测试解决方案——PAVELINK.OTABOX，在此基础上，再针对不同OTA流程的进行定制开发，从而实现实车级OTA的自动化测试。下面就给大家介绍一下PAVELINK.OTABOX的整体方案构成。 硬件层面，PAVELINK.OTABOX测试方案包括户外电源和OTA测试机箱两部分组成，其中户外电源是为OTA测试机箱进行供电，主要针对燃油车和混动车进行配置，而针对具有自动补电功能的电车，可以考虑由车辆12V蓄电池为OTA测试机箱进行供电。OTA测试机箱作为解决方案中的测试执行核心工具，通过总线仿真及采集接口卡进行总线报文的监控和仿真，工控机进行测试工程配置及执行，测试接口与车辆进行连接。 在软件层面，PAVELINK.OTABOX解决方案由三大部分组成，分别是： 逻辑定义模块（Test Center）——负责用例可视化搭建、测试任务安排以及测试任务执行等工作，逻辑的具体执行也由Test Center进行主控 逻辑转发模块（Test Agent）——作为逻辑转发端，负责转发由上方Test Center下发的逻辑执行请求，包括工程调用，控制CANoe测试工程的自动运行，停止；OTA Server服务调用；向UE发送控制指令，收取执行结果等 逻辑执行模块 ——用于执行测试工程、OTA服务器调用及UIUE识别与采集等操作 CANoe工程——实现基础功能实现，包含报文仿真、电源控制、信号仿真、以及BOB控制等 UI/UE工程——通过触控屏幕确认升级条件的操作由ADB指令实现，ADB指令需依赖车机打开ADB权限，点击屏幕指令封装在UE.exe模块内 OTA Server调用——实现与OTA Server的控制，包含任务推送以及执行记录查询等 在整个解决方案中，测试执行核心成员为CANoe软件，通过CANoe软件进行测试工程的执行、测试环境的仿真，辅以测试机柜硬件及UI/UE工程进行测试执行操作；测试管理核心成员为Test Center软件，通过单个测试管理软件可以对多套测试系统进行测试管理，辅以CANoe Agent软件，可以做到测试工程的启停控制及测试报告管理功能。 接下来，我们将为您介绍 PAVELINK.OTABOX机箱： PAVELINK.OTABOX机箱是北汇信息针对客户实车级OTA自动化测试需求量身打造的便携式机箱测试系统，机箱内部集成了小型工控机、总线接口卡及电源管理模块等测试硬件，在满足客户测试需求的情况下，尽可能地减轻测试系统的体积及重量，方便测试人员对测试系统进行移动或安置在实车环境中，极大的提升了测试系统的灵活性。 总结 总的来说，整个实车级OTA自动化测试解决方案，以北汇研发的PAVELINK.OTABOX测试机箱为硬件基础，以CANoe软件为核心测试执行工具，以北汇信息自主开发的测试管理软件TestCenter为核心测试管理软件，辅以CANoe Agent代理软件，具备了实车级OTA自动化测试的能力，并支持在短时间内以较低的成本进行批量化生产。 通过PAVELINK.OTABOX的24小时自动化运行，可提高测试样本量；测试过程中可实时抓取下载和安装数据，能避免人工操作的不可控性。相比较于人工测试，使用PAVELINK.OTABOX进行自动化测试可以至少提升2倍的效率、人力成本可以至少降低50%且拥有更高的可靠性和稳定性。 近年以来，北汇信息已经与国内多家主流OEM合作完成了实车级PAVELINK.OTABOX自动化测试系统开发项目，积累了很多实践经验，通过不断的迭代，进行了一系列优化和改进。欢迎有意向的同仁与我们交流沟通，共同进步。

引言 往期内容里为大家介绍了OTA技术、OTA后续的发展趋势预测及OTA自动化测试解决方案。本文是OTA系列的第三篇文章，今天主要向大家介绍实车级OTA自动化测试的实现手段，并简单介绍北汇信息的实车级OTA自动化测试解决方案—— PAVELINK.OTABOX。 实车级OTA自动化系统 目前，OTA自动化测试系统的落地方式主要包含以下三种： 系统级OTA通道测试系统 覆盖的测试范围：覆盖刷写前的准入条件验证，刷写中的诊断交互过程监测、系统刷写响应异常、系统故障（被刷写节点丢失），刷写后的刷写时间、版本信息读取及收集、ECU状态确认等各种正向和逆向场景，这种OTA自动化测试系统的灵活性较高，具有很强的二次开发潜力 优点：测试需求覆盖度广、不依赖实车环境进行测试 缺点：该测试系统成本较高、开发周期较长 系统级OTA压力测试系统 覆盖的测试范围：覆盖包括用户车内触发/手机APP触发、预约安装/直接安装、同基线版本/高版本退低版本/低版本升高版本的各种压力测试场景 优点：可24小时不间断运行、不依赖实车环境进行测试 缺点： 测试需求覆盖度较小，只能覆盖压力测试场景 实车级OTA压力测试系统 覆盖的测试范围：可覆盖上述系统级OTA压力测试的全部测试内容，且具有在高温高寒环境（-20-+40℃）下执行测试的能力 优点：可24小时不间断自动化运行、落地周期短、价格较低、可批量复制性强、测试人员需求较少 缺点：依赖实车环境进行测试，测试需求覆盖度较小， 只能覆盖压力测试场景 上述三种OTA自动化测试系统分别有各自的优劣势和特点，因此OEM可根据测试需求进行灵活的选择最适合的方案。 今天介绍的实车级OTA自动化测试系统主要适用于以下场景： 期望在实车环境下验证车辆OTA链路的稳定性 只需覆盖压力测试场景：因为实车环境进行测试的限制，因此实车级OTA自动化测试系统无法覆盖通道测试内容，只能覆盖压力测试场景，进行24小时不间断运行测试 测试成本及落地周期较低：相比较于系统级OTA测试系统，实车级OTA自动化测试系统具有价格低、落地周期短的优势，因此适合预算较低及需要快速投入使用的OEM 需要进行批量复制：相比较于系统级OTA测试系统，实车级OTA自动化测试系统具有可批量复制性强的优势，因此适合需要批量使用测试系统的OEM 需要在恶劣环境下进行测试：相比较于系统级OTA测试系统，实车级OTA自动化测试系统具有在高温高寒环境（-20-+40℃）下执行测试的能力，因此适合需要在恶劣环境下进行测试的OEM PAVELINK.OTABOX解决方案 鉴于以上实车级OTA自动化测试的特点，北汇信息在对各主流OEM的OTA流程做了深入分析后，推出了通用化的实车级OTA自动化测试解决方案——PAVELINK.OTABOX，在此基础上，再针对不同OTA流程的进行定制开发，从而实现实车级OTA的自动化测试。下面就给大家介绍一下PAVELINK.OTABOX的整体方案构成。 硬件层面，PAVELINK.OTABOX测试方案包括户外电源和OTA测试机箱两部分组成，其中户外电源是为OTA测试机箱进行供电，主要针对燃油车和混动车进行配置，而针对具有自动补电功能的电车，可以考虑由车辆12V蓄电池为OTA测试机箱进行供电。OTA测试机箱作为解决方案中的测试执行核心工具，通过总线仿真及采集接口卡进行总线报文的监控和仿真，工控机进行测试工程配置及执行，测试接口与车辆进行连接。 在软件层面，PAVELINK.OTABOX解决方案由三大部分组成，分别是： 逻辑定义模块（Test Center）——负责用例可视化搭建、测试任务安排以及测试任务执行等工作，逻辑的具体执行也由Test Center进行主控 逻辑转发模块（Test Agent）——作为逻辑转发端，负责转发由上方Test Center下发的逻辑执行请求，包括工程调用，控制CANoe测试工程的自动运行，停止；OTA Server服务调用；向UE发送控制指令，收取执行结果等 逻辑执行模块 ——用于执行测试工程、OTA服务器调用及UIUE识别与采集等操作 CANoe工程——实现基础功能实现，包含报文仿真、电源控制、信号仿真、以及BOB控制等 UI/UE工程——通过触控屏幕确认升级条件的操作由ADB指令实现，ADB指令需依赖车机打开ADB权限，点击屏幕指令封装在UE.exe模块内 OTA Server调用——实现与OTA Server的控制，包含任务推送以及执行记录查询等 在整个解决方案中，测试执行核心成员为CANoe软件，通过CANoe软件进行测试工程的执行、测试环境的仿真，辅以测试机柜硬件及UI/UE工程进行测试执行操作；测试管理核心成员为Test Center软件，通过单个测试管理软件可以对多套测试系统进行测试管理，辅以CANoe Agent软件，可以做到测试工程的启停控制及测试报告管理功能。 接下来，我们将为您介绍 PAVELINK.OTABOX机箱： PAVELINK.OTABOX机箱是北汇信息针对客户实车级OTA自动化测试需求量身打造的便携式机箱测试系统，机箱内部集成了小型工控机、总线接口卡及电源管理模块等测试硬件，在满足客户测试需求的情况下，尽可能地减轻测试系统的体积及重量，方便测试人员对测试系统进行移动或安置在实车环境中，极大的提升了测试系统的灵活性。 总结 总的来说，整个实车级OTA自动化测试解决方案，以北汇研发的PAVELINK.OTABOX测试机箱为硬件基础，以CANoe软件为核心测试执行工具，以北汇信息自主开发的测试管理软件TestCenter为核心测试管理软件，辅以CANoe Agent代理软件，具备了实车级OTA自动化测试的能力，并支持在短时间内以较低的成本进行批量化生产。 通过PAVELINK.OTABOX的24小时自动化运行，可提高测试样本量；测试过程中可实时抓取下载和安装数据，能避免人工操作的不可控性。相比较于人工测试，使用PAVELINK.OTABOX进行自动化测试可以至少提升2倍的效率、人力成本可以至少降低50%且拥有更高的可靠性和稳定性。 近年以来，北汇信息已经与国内多家主流OEM合作完成了实车级PAVELINK.OTABOX自动化测试系统开发项目，积累了很多实践经验，通过不断的迭代，进行了一系列优化和改进。欢迎有意向的同仁与我们交流沟通，共同进步。

一、引言 作为实现高阶自动驾驶的方式之一，V2X（vehicle-to-everything）包含车辆与车辆V2V(Vehicle-to-Vehicle)、车辆与基础设施V2I（Vehicle-to-Infrastructure）、车辆与行人V2P(Vehicle-to-Pedestrian)、车辆与外部网络V2N（Vehicle-to-Network）等各种应用通信应用场景，通过现代通信与网络技术，实现车与外界的信息交换共享（实时路况、道路信息、行人信息等一系列交通信息），从而提高驾驶安全性、降低交通拥堵、提高交通效率。 目前C-V2X功能的验证主要采用台架仿真和实车测试两种方式，台架仿真测试基于模拟真实道路环境中的道路场景、机动车、行人、道路事件、标牌、信号灯等信息还实现V2X应用场景，即仿真远车与路侧设备发出的BSM、RSM、RSI、SPAT、MAP消息；在实际的仿真测试系统开发中只能做到尽量高的道路状况信息还原度，无法完全还原真实道路场景与车辆状态。实车测试则是在真实道路环境场景下,采用试验假车、假人及路侧设备发出真实V2X消息实现，优势是车路环境真实，但同时存在安全性无法保证、车辆协调效率低的缺点。 二、C-V2X数字孪生测试方法介绍 基于实车在环的C-V2X数字孪生测试方法采用“虚实结合”的方式，其“实”是指采用真实车辆：车辆状态、运动学及行为决策都是真实的；而“虚”则是指所有除道路和试验车辆外的所有交通参与者（背景车、行人 、路侧设备）都是通过仿真实现，其框架如下图所示： 图1 基于实车在环的C-V2X数字孪生测试方法框架 该方法结合台架仿真和实车测试，具有以下优势： 安全性高 提升测试效率，节省研发费用 不受场地限制：在城市道路及封闭道路皆可进行试验 三、车载测试台架 基于实车在环的C-V2X数字孪生测试方法中，背景车辆、行人、路边单元的V2X信号（BSM、RSM、SPAT、RSI、MAP）的仿真主要通过搭载在试验车辆中的测试台架实现。车载测试台架主要由测试车辆、高精度定位系统、总线通信接口卡、V2X模拟器、CANoe等组成，功能如下： 可进行V2X测试场景搭建，定义仿真背景车辆的运行轨迹； 支持不同国家ITS协议栈仿真，满足欧洲标准EU ITS-G5，美国标准U.S.WAVE和中国标准GB/T 31024-3 / CSAE-53/CSAE-157测试需求； 可显示试验车辆及仿真的所有交通参与者的V2X数据，并可进行集中化的解析显示和测试管理执行。 支持云控管理平台连接，实现远程监控测试执行。 运行自动化测试，支持测试报告自动生成。 图3 车载测试台架框架 测试场景 测试场景覆盖T/CSAE 53标准中除近场支付外的16种典型应用场景测试，如下表所示： 典型测试场景 四、试验过程 试验车辆接收V2X模拟器仿真发送的路测单元消息（RSM、SPAT、RSI、MAP消息），以及仿真背景车辆的BSM消息，仿真的各种V2X消息如图5所示，结合试验车辆OBU内的算法逻辑，完成各测试场景中的V2X功能预警，总线通信接口卡采集车辆总线上的V2X功能预警信号发送给CANoe中，完成功能测试验证。 图4 CANoe接收到的V2X消息 测试过程如下： 结语 北汇信息基于C-V2X数字孪生测试方案，提供V2X试验场地建设、车载仿真测试系统集成、V2X实车功能测试等服务，支持在真实道路环境下完成应用场景仿真和通信环境仿真测试，已在国内实现多套方案落地，极大的帮助客户加速V2X研发验证过程。 北汇信息作为IMT-2020（5G）推进组蜂窝车联（C-V2X）工作组成员，我们致力于在V2X领域积极开展LTE-V2X和5G-V2X的测试验证技术研究等工作，积极推动中国V2X的产业落地，为客户提供V2X成套测试系统及服务。

前言 对 于 汽车电子测试工程师来说 ， 实车级网络 及 诊断测试 是项 繁琐 却 又必 要 的工作 。 风吹日晒，寒来暑往，固然挡不住测试人奋斗的脚步。但是手提示波器 、 身背测试仪 、 一个个，一路 路 地 去 手动 测试 车辆 上几十个甚至上百个E CU ，是不是太繁琐了？能不能更加自动化、高效化呢？ 北汇信息 在与国内多家O EM 进行 实车级网络 及诊断 测试 的 合作 过程中 ，始终在思考这个问题。 基于对 实车 级网络 及诊断 测试需求的准确把握、 V ector 测试工具链的 丰富 应用经验 ， 北汇信息 开发了一套 使用方便、测试可靠、运行稳定的 实车级网络 及诊断自动化测试系统，下面就让我们一睹为快吧 ！ 图1：测试系统实物 背景 实车级网络 及诊断测试的必要性 从 完整的 车辆开发角度而言 ， 实车级网络 及诊断 测试是 真正的“大考” ， 其重要性 和必要性 不言而喻 。 首先， 保证控制器的通信稳定是实车功能正常的前提基础。但 在有限的整车空间内集成大量传感器 、 控制器 、 大功率 执行器 ， 实车电气 环境 复杂且使用场景组合 比较复杂， 这可能会 对控制器间的通信行为带来 一定 影响 ； 部分测试场景需要在实 车 环境 下测试更为有意义 ， 如整车电源模式 变化 对 E CU 通信 诊断的影响 ； 在实车上会 偶发 一些 问题 ， 如车辆启动后丢帧的情况 ， 通过手动或者 传统 单节点自动化测试脚本难以测试或分析出问题 。 传统 实车级网络 及诊断 测试方法 及缺点 通过手动方式对整车上所有 E CU 进行 逐个测试 ，记录及分析结果，时间长且效率低 ； 测试系统 供电 来自实车 ， 采集到的整车电流等信息有误 ， 对实车数据分析结果带来偏差 。 北汇信息 的创新 针对 实车网络 及诊断 测试必要性以及 传统 测试方法 不足 ， 北汇信息 基于 Vector 的 V N89 00 (具备Standalone功能 ) 、 C ANoe 、 Pico S cope 以及电池 模块 、 自 研 设备路由 板卡 D RB 实现 实车级网络 及诊断 自动化测试， 并对采集的实 车数据 进行 分析， 定位实车可能的问题 点 。 测试方案 测试系统框图 图 2 ：测试 方案 设备 功能简介 锂电池 ： 测试系统 供电 ，可支持系统独立运行 ； V N89 00 ： 测试脚本独立运行设备 ， 需要 结合 CANoe /CANalyzer Standalone basic/extended License 使用 ； 图 3： V N89 00 的实物图 V N8972 ：C AN/CANFD/LIN总线报文收发设备 ， 安装在 V N89 00 中 ； I O Piggy8642 ： 用于 实车电压采集 ， 安装在 V N89 00 中 ； Pico S cope ：C AN/CANFD/LIN 物理电平 信息 采集 设备 ， 包含协议解析功能 ； 图 4： Pico Scope 实物图 自 研 设备路由 板卡 D RB ： 实现多网段 总线自动化测试 ； 上位机P C ： 编辑和 下载 测试脚本 、 导出测试报告和数据 、 运行 部分 测试脚本 ； 显示屏 ： 显示当前系统电池输出电压和电量 。 测试范畴 的示例 物理层测试： 包括 输出电压、共模电压、上升/ 下降 沿时间 测试 等 ； 通信测试： 包括 报文周期、 总线负载等； 网络管理测试：验证实车上E CU 的休眠、唤醒模式是否符合设计要求 ； 网关测试： 如 所有网段间路由报文的路由时间 等 ； 诊断测试：读取不同场景下所有E CU 的诊断故障码，并判断是否错误记录了D TC 。 测试 过程 使用 上位机 P C 将测试工程下载到 V N8900中 ； 图5 ：V N8900工程配置 将实车OBD等接口与测试系统连接 ； 使能 V N8900的 Start， 运行测试工程 ； 测试完成后， 将上位机 P C 和 V N8900连接 ， 导出测试报告和数据 ； 图 6 ： 导出测试报告和数据 将采集 的 实 车数据 进行 分析 ，定位车辆可能存在的问题 。 内容如 下 ： DTC的分析统计（DTC统计，DTC关联，DTC恢复等） 刷写的分析统计（刷写流程分析， Hex文件还原） 通讯的分析统计 -协议层（周期，丢帧，超警戒负载，信号范围，转发延时，异常数据，校验及安全机制） 网络逻辑分析（ 上下电过程 ，休眠过程，网络状态） 功能逻辑分析（互斥信号，备份信号，无效信号，默认信号，其他逻辑类） 对于实车上出现的问题 ， 在网络及诊断测试系统上 进一步 复现问题并排查原因 。 自动化 测试报告 示例 网络测试报告 图 7 ：网络测试报告 物理层 测试报告 图 8 ：物理层测试报告 诊断 D TC 测试报告 图 9 ：诊断D TC测试报告 总结 对整车开发而言 ， 实 车 阶段 的 网络 及诊断 测试是必经之路 。 虽 O EM的 E CU部件级 和系统级 测试 规范 中包含丰富的测试用例 ， 但复杂 的 实 车环境 带来 影响以及车 辆偶发问题 的 困扰 ， 使 实车级 网络 及诊断 测试 越来越受重视 。 传统 实车级网络 及诊断 测试 方法强依赖于人工 ， 随着车型开发周期逐渐缩短 ， 测试效率和准确性均受到严重的挑战 。 北汇信息 专注于测试 ， 着眼于 客户 需求 ， 开发出 实车级网络 及诊断 自动化测试系统 方案 。 对于实车测试问题，还需要在 网络 及 诊断 测试系统 上 进一步 复现问题并排查原因。 北汇信息 提供相应成熟的技术解决方案， 欢迎各位 行业 同仁 垂询 和指导 ！ 参考文献 VN8900_Manual_EN .pdf S cope _Manual_EN .pdf

前言 汽车ECU（动力域、底盘域、ADAS、电子电器等）的研发最后一个阶段测试往往为ViL（车辆在环）测试，为确保产品的功能和性能正常，通常需要大量的测试。 一般的ViL测试过程 在涉及到发动机、变速箱、底盘等需要特殊场地和驾驶要求的控制器测试时，往往我们需要专业试车员和测试人员一同配合完成。 测试人员整理测试用例（excel、word），使用总线监控设备（如Vector公司的CANoe和VN1640A）连接整车，由试车员按照编写好的测试用例执行，采集整车报文数据，测试人员在测试完成后进行评估。 整个测试过程主要存在如下不足： 编辑的测试用例可能需要翻译成中文，影响测试效率 测试用例不能实现语音输出及可视化 试车员忘记了下一步测试步骤是什么 测试人员需要编辑大量测试用例，所需时间较长 人工判断和评估效率不高 整理报告时间太长 …… TPT Autotester-ViL测试过程 测试人员在TPT中编写状态机测试用例和Assesslets评估，通过FUSION平台的CAN接口访问其他的CAN通信及标定软件（如Vector公司的CANoe、CANape或ETAS公司的INCA）来实现与实车的通信 。 在测试过程中，试车员根据中文语音提示进行操作，通过Autotester界面获取测试信息，软件自动检测车辆状态是否达到预期，并在测试完成后，根据Assesslets进行评估，并且自动生成测试报告。 图 1 TPT Autotester-ViL测试过程示意图 我们来具体了解一下TPT Autotester的特性和功能： 高效且 灵活多样的状态机测试用例 无论多复杂的测试用例都是按照先后顺序执行的，状态机测试用例可以清晰的将测试的各个阶段及转移条件展现出来。 下图中，状态机表示测试的各个阶段，状态转移线表示各个阶段的转移条件，只有满足线上的条件时，才能进入下一个测试阶段。 80%），才能进入阶段3。 状态机表示当前测试进行到的阶段在测试的某一阶段，判断信号是否达到期望值。比如，阶段3到阶段4，发动引擎，使用Compare判断转速（也可使用 Assesslets评估） 状态转移线上可以编辑一个或多个条件，编辑其他测试用例时选择不同状态即可状态转移线上的名称能够语音输出，提示试车员操作转移线上的条件支持自定义图形化显示 图 2 状态机测试用例 测试用例支持 简体 中文显示及中文播报 Autotester测试用例中的状态机和转换条件名称均能支持简体中文显示，并且，转换条件名称支持中/英文语音输出。试车员只需按照中文语音提示操作即可，无需查看测试用例。 图 3 切换中文（简体）/英语（美式）语音输出 图 4 状态机测试用例测试过程 注：状态转移线名称用以语音提示 支持信号名称及图像自定义 TPT Autotester支持信号名称和图像自定义功能。 Auto Tester Setup中： “Name”指Autotester界面中的信号名称 “Channel”对应的是导入TPT中的信号名称（dbc中的信号名称） 每个信号右侧对应的“Icon Path”可以为每个信号自定义图像。 图 5 Autotester中定义的信号 图 6 信号对应的图像 支持设置 测试开始前的 初始条件 在Auto Tester Setup中，可以设置测试开始的初始条件（Option），Precondition test case中选择的测试用例会被首先执行并评估，只有当Precondition中的测试用例通过时，才能执行其他测试用例。 比如，工程中选择Precondition test cases测试用例为Precondition， 测试用例含义为检测钥匙状态是否为Power On档位，只有当钥匙在Power On档，测试用例才能从“初始化”到“阶段1”，并且评估引擎转速是否<900rpm/min。只有Precondition测试用例通过，才能执行其他测试用例。 规避偶然因素 在实际ViL测试过程中，经常会受到环境的影响，为了避免偶然因素，可以设置测试用例忽略或者重复的次数。 比如： 设置MaxIgnoreConsecutiveFails的数值为2，含义为最大忽略连续失败的次数为2次 如果测试用例执行了3次，前2次失败，但第3次通过，则最终结果为通过。 设置MinConsecutivePassed的数值为2，含义为最小连续通过次数 如果测试用例共执行3次，第1次失败，后2次通过，则最终结果为通过。 MaxTestRun，含义为最大测试用例执行次数 一般情况下：MaxTestRun=MaxIgnoreConsecutiveFails+MinConsecutivePassed。 例如： 测试用例Shift Gear 3 to 4，为了避免然因素，需执行5次后才能判定最终结果，图中只执行了1次。 测试数据自动保存，报告自动生成 测试完成后，数据会以blf格式保存在zip文件中 评估完成后，右键打开测试报告（报告支持自定义） 通过以上步骤，进行ViL测试时，试车员根据语言提示操作即可，测试完成后当场即可进行评估，并自动化生成报告，提高车辆在环测试效率。 Piketec 公司简介 PikeTec公司是全球知名的基于模型的嵌入式系统测试工具TPT的软件供应商，总部位于德国柏林，其创始人均在戴姆勒公司拥有十多年的软件测试经验。TPT作为针对嵌入式系统的基于模型的动态测试工具，支持众多业内主流的工具平台和测试环境，可应用于整个嵌入式软件开发周期，实现各种异构环境下的自动化测试。无论是在测试建模，测试环境还是测试评估，测试报告方面，都占据强大优势。 北汇信息作为PikeTec的中国合作伙伴，将帮助中国客户借助TPT提升嵌入式控制系统的开发效率。