使用在环硬件测试车辆设备控制器的系统和方法与流程

1.本公开涉及汽车电子控制器测试自动化领域，特别涉及使用在环硬件(hardware in the loop，简称为hil)测试车辆设备控制器的系统和方法。


背景技术：

2.随着hil硬件在环仿真技术的普及和应用，大批的hil设备供应商涌现。为了统一hil设备标准，方便用户自由选择hil设备，设计针对各个hil设备供应商的统一测试自动化脚本并对这些测试自动化脚本进行重复使用，asam标准组织于2009年6月首次提出了asam hil api标准并持续不断完善。asam xil api是asam hil api标准的升级版本。
3.现有的基于dspace hil设备的测试脚本结构简单，接口固定，不易扩展，仅能监控来自hil设备的信息，不能兼容其他供应商的设备(诸如vector的工具)，导致所提供的测试具有局限性。
4.因此，存在对基于hil设备的车辆设备控制器测试系统和方法进行改进的需求。
5.需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。


技术实现要素：

6.根据本公开的实施例，提出使用hil装置测试车辆设备控制器的系统和方法，旨在采用hil装置测试多种车辆设备控制器，扩展支持更多的符合xil api协议的hil装置，同时在测试中增加测试监测的信息以提供更全面的评估结果，支持更多的测试场景。
7.根据本公开的一方面，提供一种用于使用在环硬件(hil)装置测试车辆设备控制器的系统，包括：
8.用户界面，被配置用于接收测试输入数据集以及提供测试结果；
9.测试框架子系统，所述测试框架子系统进一步包括：
10.测试数据接口，被配置用于从所述测试输入数据集提取测试数据以及向所述用户界面转发来自在环硬件接口的返回数据；
11.测试框架单元，被配置用于执行以下操作中的至少一个：基于来自所述测试数据接口的所述测试输入数据集配置测试框架子系统并且创建测试框架集，基于所述测试框架集向所述在环硬件接口发送测试请求，基于来自所述在环硬件接口的返回数据和来自所述车辆设备控制器监控接口的所述车辆设备控制器的状态中的至少一个评估所述测试以生成所述测试结果，以及重置所述测试框架子系统的至少一部分；
12.所述在环硬件接口，被配置用于将所述测试请求转发到所述在环硬件装置，以及接收来自所述在环硬件装置的所述返回数据；以及
13.车辆设备控制器监控接口，被配置为获取所述车辆设备控制器的状态。
14.根据本公开的实施例，所述测试框架子系统还被配置为将所述车辆设备控制器与所述在环硬件装置进行同步。
15.根据本公开的另一方面，提供一种用于使用在环硬件(hil)装置测试车辆设备控制器的方法，包括：
16.通过用户界面接收测试输入数据集；
17.基于所述测试输入数据集配置测试框架子系统并且创建测试框架集，其中所述测试框架子系统包括测试数据接口，测试框架单元，在环硬件接口以及车辆设备控制器监控接口，所述测试框架单元包括所述测试框架集；
18.基于所述测试框架集经由所述在环硬件接口向所述在环硬件装置发送测试请求；
19.基于来自所述在环硬件装置的返回数据和来自所述车辆设备控制器监控接口的所述车辆设备控制器的状态中的至少一个评估所述测试以生成测试结果；
20.复位所述测试框架单元；以及
21.通过用户界面提供所述测试结果。
22.根据本公开的实施例，配置测试框架子系统还包括将所述车辆设备控制器与所述在环硬件装置进行同步。
23.根据本公开的又一方面，提供一种非暂态计算机可读存储介质，其上存储有包括可执行指令的计算机程序，当所述可执行指令被处理器执行时，实现如上所述的方法。
24.根据本公开的再一方面，提供一种电子设备，包括处理器以及用于存储所述处理器的可执行指令的存储器，所述处理器被配置为执行所述可执行指令以实施如上所述的方法。
25.通过采用本公开的基于asam xil api标准的测试系统和方法，可以适用于多种非dspace hil设备，在监控hil返回的统一诊断服务(uds)信息的同时同步获取车辆设备控制器(诸如变速器控制单元tcu，电子控制单元ecu等)的状态信息，提供更全面的测试评估结果。该测试系统和方法效率更高，不仅适用于包括dcm和dem(diagnostic event management)s的uds测试，还可以应用于其它基于automation desk和canape的车辆设备控制器功能测试，而且适用的车辆设备控制器更多。
26.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
27.通过参照附图详细描述其示例性实施例，本公开的上述和其它特征及优点将变得更加明显。
28.图1示出基于asam xil api标准的示例性测试系统架构的示意图；
29.图2示出根据本公开的实施例的示例性测试系统架构的示意图；
30.图3示出根据本公开的实施例的示例性测试方法的流程图；
31.图4示出根据本公开的实施例的示例性测试系统和方法的测试框架单元的测试框架集的逻辑示意图；
32.图5示出图4中的测试框架集的uds测试框架的逻辑示意图；
33.图6示出根据本公开的实施例的示例性测试方法中关于uds服务任务测试框架的自动化测试报告；以及
34.图7示出根据本公开的实施例的示例性测试方法中关于故障注入及dtc检测故障
码的基本测试报告。
具体实施方式
35.现在将参考附图更全面地描述示例性实施例。然而，示例性实施例能够以多种形式实施，且不应被理解为限于在此阐述的实施方式；相反，提供这些实施方式使得本公开全面和完整，并将示例性实施例的构思全面地传达给本领域的技术人员。在图中，为了清晰，可能会夸大部分元件的尺寸或加以变形。在图中相同的附图标记表示相同或类似的结构，因而将省略它们的详细描述。
36.此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本公开的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而没有所述特定细节中的一个或更多，或者可以采用其它的方法、元件等。在其它情况下，不详细示出或描述公知结构、方法或者操作以避免模糊本公开的各方面。
37.asam xil api是在车辆测试自动化工具与测试台之间的通信标准，它使测试系统的测试台硬件与测试自动化工具软件之间的接口实现标准化，以便于在不同的测试台硬件上重复使用测试案例，并使测试自动化工具软件独立于测试台硬件。例如，用户可以：
38.·
在不同硬件供应商提供的测试台系统上重复进行自动化测试；
39.·
降低员工的培训成本；
40.·
改善不同测试台硬件之间的技术移植。
41.hil设备作为车辆设备控制器测试仿真中的重要测试台硬件，可以模拟诸如真实的被控车辆设备(如发动机、变速箱)或系统的物理实体的电气信息(例如来自发动机或变速箱的传感器信息)，提供与所模拟对象相同或类似的接口和运行方式，使得被测设备控制器不用安装在实际车辆中就可以获得接入模拟的车辆设备控制器使用环境时的测试条件。hil设备需要基于模型控制，配套的测试软件以手动或自动的方式将所模拟对象的运行状态上传到上位机(一般为pc)上。在上位机上运行的测试案例(testcase)在本文中也可以称为测试输入数据集，其主要包括测试框架配置和测试数据等。通过运行测试案例，可以监控所仿真对象的运行过程，同时将所仿真对象的传感器数据等测量信息传输到被测试的对象(例如车辆的变速箱控制单元tcu，电子控制单元ecu等)。在本公开的实施例中，采用hil装置作为asam xil api标准的测试系统中的测试台硬件。
42.图1示出基于asam xil api标准的示例性测试系统架构。
43.asam xil api标准主要包括两大接口标准,即框架应用程序编程接口包(package framework application api，下文简称为框架应用程序接口)和测试台应用程序编程接口包(package testbench application api，下文简称为测试台应用程序接口)。
44.测试系统架构100主要包括测试自动化用户界面层110，框架应用程序接口120，框架(framework，简称fw)层130和测试台应用程序接口140。测试系统架构100通过测试台应用程序接口140与测试台(testbench，简称tb)150进行数据交互。
45.测试自动化用户界面110提供测试自动化系统/工具与用户的交互界面，接收用户的以测试案例testcase形式的测试输入数据集。测试输入数据集包括对测试自动化系统的配置参数以及关于测试任务的测试条件、测试任务项目和测试参数等数据，通过基于多变
量的访问方式经由框架应用程序接口120输入到框架130。测试输入数据集还包括分别用于与框架fw交互的框架访问数据以及与测试台hil硬件交互的测试台端口访问数据。
46.框架应用程序接口120的功能被定义为：变量映射和数据记录，数据类型或者变量识别及基于接口的测试台交互规则，是框架130使用测试台150的有效功能接口。框架应用程序接口120通过框架控制端口fw control将来自用户界面110的框架访问数据传输到框架层130以提供配置框架集的配置数据cfg，以及接收来自框架层130的框架集的框架数据。框架应用接口120还可以分别通过框架变量端口fw variable，框架采集端口fw acquisition，框架启动端口fw stimulation和框架监测端口fw watcher将测试输入数据集中的相应输入数据传输到框架层130。框架应用程序接口120还可以具有测试台端口tb-ports以接收从测试台应用程序接口140发送的源自hil硬件装置的测试返回数据并以测试台端口访问数据的形式向用户提供。
47.框架层130基于测试输入数据集创建和配置实现相应测试任务的框架集，通过例如映射mapping的方式经由测试台应用程序接口140向测试台10的hil硬件装置发送测试请求，并接收来自hil硬件装置的测试返回数据，对返回数据进行评估，以及复位测试框架层140和/或框架应用程序接口120和测试台应用程序接口140的部分或全部参数。映射可以将不同hil硬件设备的特定协议/端口映射为用户使用的用户界面层所使用的通用协议/端口，分别通过框架应用程序接口和测试台应用程序接口完成数据传输和转发。框架层130中的框架(fw)可以是提供与hil设备配合使用的软件的软件供应商提供的模块库。
48.在本公开的实施例中，框架可以涵盖更广泛的内容。框架不仅是函数模块库，而且包括实施测试任务的函数/模块定义和配置数据，测试任务的环境和/或条件数据，执行测试任务的指令(一般通常以测试请求的方式呈现)及其指令参数等。这些函数包和数据可以组成集成化插件或工具包应用于测试系统平台。因此，本公开中的框架可以被认为是与测试任务对应的指令(例如函数集)和参数数据集合，指令可以具有设定的序列。一项或多项测试任务可以构成测试案例中包括的完成测试过程的一系列测试任务集，对应于由至少一项测试框架构成的测试框架集。
49.测试台应用程序接口140的功能被定义为：访问hil硬件仿真模型/离线仿真的仿真端口ma，ecu相关的数据端口(标定ecuc、测量ecum和诊断diag),电气故障注入仿真端口ees port和网络端口network等。图1中的测试台应用程序接口140还可以通过接收从框架应用程序接口120的测试台端口转发的来自测试输入数据集的与测试台hil装置对应的配置数据来配置各个端口的参数cfg。通过测试台应用程序接口140，测试案例的测试输入数据集可以配置和使用测试台10的hil硬件装置进行自动化控制和通信，完成相应的测试任务。
50.图2示出根据本公开的示例实施例的车辆设备控制器自动化测试系统框架，其中基于asam xil api标准协议和canape系统与hil硬件装置和车辆的tcu设备进行控制和数据交互。该测试系统可以在dspace公司的自动化测试软件automation desk的平台上实现。在本公开的实施例中，可以在上位机(例如pc)上通过automation desk自动化测试软件平台结合hil装置的仿真模型和vector公司用于标定和观测车辆设备控制器(例如tcu)的canape软件，进行测试过程的数据输入和状态观测。上位机通过hil装置的仿真模型控制hil装置，canape系统通过相应的canape软件操控canape系统硬件。上位机和hil装置之间
可以采用tcp/ip协议标准进行通信链接，hil装置和车辆设备控制器之间可以通过物理线束链接，车辆设备控制器可以通过can总线接口链接到canape系统硬件，canape系统硬件再通过诸如usb标准的数据端口链接到上位机。
51.在本说明书中，以车辆的变速器控制单元tcu作为车辆设备控制器来介绍车辆设备控制器测试系统和方法。本领域技术人员可以理解，车辆设备控制器还可以包括诸如ecu，vch，hcu等其它各种车辆设备控制器。与车辆设备控制器的交互还可以采用canape系统之外的其它系统，使用诸如xcp协议、vector公司实例化的asap3协议等的多种协议api访问tcu等。在下文中，对图2中与图1类似或相同的部分将不再详述。
52.测试系统200主要包括用户界面210，测试数据接口220，测试框架单元230，在环硬件hil接口240和车辆设备控制器监控接口260。
53.用户界面210类似于图1中的测试自动化用户界面层110，用于接收用户以测试案例testcase形式的测试输入数据集211，以及向用户提供测试结果。用户界面210可以采用图形化界面的形式，也可以采用命令行或其它方式与用户交互。测试输入数据集211包括进行车辆设备控制器测试的所有数据，这些数据包括但不限于测试系统200的架构配置参数、测试任务数据、测试前置和后置条件数据等。
54.测试数据接口220，框架测试框架单元230，在环硬件接口240和车辆设备控制器监控接口260可以组成测试框架子系统。
55.测试数据接口220类似于图1中的框架应用程序接口120，用于从测试输入数据集211提取诸如架构配置参数和测试任务数据的测试数据以及向用户界面210转发从在环硬件接口240接收的来自hil装置250的返回数据。测试数据接口220可以采用框架应用程序接口120的各个端口进行变量映射和数据转发，与测试框架单元230中的测试框架集、在环硬件接口240中的与在环硬件hil装置250对应的端口、车辆设备控制器监控接口260的相应端口交换数据。
56.测试框架单元230类似于图1的框架层130，可以基于来自测试数据接口220的测试输入数据集211配置测试框架子系统并且创建测试框架集，基于创建的测试框架集向在环硬件接口240发送测试请求，基于来自在环硬件接口240的hil装置250所模拟的车辆平台或设备的返回数据和车辆设备控制器270的状态中的至少一个评估测试任务以生成测试结果，以及基于测试结果重置测试框架子系统的至少一部分。
57.基于测试输入数据集配置测试框架子系统并且创建测试框架集可以包括采用测试数据输入集中的架构配置参数来配置测试框架子系统的各个部分的参数，例如配置测试数据接口220、在环硬件接口240和车辆设备控制器监控接口260的操作参数。其中配置车辆设备控制器监控接口260可以包括标定车辆设备控制器tcu 270和/或将其与在环硬件hil装置250进行同步。通过对基于canape系统的车辆设备控制器tcu 270进行时钟标定，将hil装置250和车辆设备控制器tcu 270进行同步，可以在对hil装置进行故障注入的同时同步地观测车辆设备控制器tcu 270对相应故障的响应及其产生的对应故障码。
58.创建测试框架集则包括基于测试任务数据构建框架单元集中的至少一个测试框架，每个测试框架对应于一项或多项测试任务。现有的基于统一诊断服务uds的测试脚本框架结构是由设备供应商提供的标准软件模块，其基于dspace图标化定制的在环硬件仿真端口ma port，局限在于不方便集成其它功能而不能进行灵活扩展，不能兼容诸如vector的其
它工具。而采用基于asam xil api协议标准化的测试系统架构200，可以使用协议提供的函数库，在初始化标准在环硬件仿真端口ma port后通过实施在测试框架集中相应的实施uds读写服务的测试框架来集成该诊断测试服务。这种对应于uds的测试框架可以包括uds基本功能和故障之后的服务读写，通过上文中的同步，还可以在该uds测试服务中自动集成故障注入，从而整合到整个测试框架子系统中。例如，可以通过故障注入仿真端口ees port向hil装置注入故障，然后通过uds的服务指令对故障进行处理。例如，可以通过uds指令0x14读取故障，以及通过uds指令0x19清除故障。这样，测试框架单元中的测试框架集的至少一个测试框架，集成了多个测试任务和/或服务，并在多个测试任务和服务之间提供逻辑和时间同步。根据本公开的实施例，该uds测试框架可以采用与其它测试框架不同的标准。
59.在环硬件接口240类似于图1的测试台应用程序接口140，用于将来自测试框架单元230的测试框架集定义的测试请求转发到hil装置250，以及接收来自hil装置250的测试返回数据。根据实施例，在环硬件接口240可以包括在环硬件仿真端口ma port，故障注入仿真端口ees port和诊断端口diag port。在环硬件仿真端口用于将测试框架单元230中的测试框架集定义的测试请求转换成hil硬件装置250的协议标准可以接受的数据，并将hil硬件装置250针对测试请求的返回数据以测试框架集能够接收的数据。在环硬件仿真端口实现使用hil硬件设备进行车辆仿真测试的大部分数据接口功能。故障注入仿真端口用于对hil装置仿真的整车系统进行故障注入操作，仿真整车系统故障来验证被测试的车辆设备控制器tcu 270的故障检测和响应机制。根据本公开的实施例，在环硬件接口240的在环硬件仿真端口故障注入仿真端口和诊断端口等采用asam xil api协议标准。
60.例如，测量框架集通过故障注入仿真端口将故障注入传感器或者执行器，同时可以通过canape系统的api协议经由车辆设备控制器监控接口260将发送uds请求给tcu，读取tcu的故障诊断状态信息，例如dtc诊断码。tcu的故障诊断状态信息提供给测试框架单元230的测试框架集，然后进行评估并将评估后的测试结果在用户界面210提供给用户。
61.通过同步hil装置260和车辆设备控制器tcu 270的时钟，可以基于本公开的测试系统的测试框架单元230同时监控hil装置250和车辆设备控制器tcu 270的状态并且可通过简单设置自动进行相应返回结果的比较。hil装置250端还可以将仿真故障注入到车辆设备控制器tcu 270端，同时hil装置250端仿真整车发送诊断请求，车辆设备控制器tcu 270端可以及时响应诊断请求并将反馈信息发送到hil装置250。这样，可以提高车辆设备控制器tcu 270的自动测试效率和广泛性。
62.在图2中，车辆设备控制器270即测试任务需要测试的对象。例如，车辆设备控制器270可以是车辆的tcu，ecu，hcu和vcu等。车辆设备控制器监控接口260与在环硬件接口240不同的是，监控接口260用于将来自测试框架单元230的测试框架集定义的测试请求转发到车辆设备控制器270，以及接收来自车辆设备控制器270的状态返回数据。测试请求包括但不限于对车辆设备控制器tcu 270进行时钟标定和提取状态信息，状态返回数据包括但不限于针对hil装置250被注入故障之后的故障响应和故障码。车辆设备控制器监控接口260例如可以采用asap3接口协议与canape系统通信，canape系统用于控制tcu。同样还可以测试使用canape系统的其它车辆设备控制器。
63.图3示出根据本公开的实施例的用于使用在环硬件装置测试车辆设备控制器的方法。下面将基于图3结合图4和图5的逻辑示意图详细介绍该方法。该测试方法包括如下步
270的内部状态，选择开启是否初始化canape系统的接口以及对该接口的配置。在本公开的实施例中，车辆设备控制器监控接口260采用canape系统的标准接口api，在此不再详述。
70.对于测试框架单元的创建和配置，包括创建测试框架集并对其进行结构标准化配置。例如，针对用户界面输入的测试输入数据集，测试案例testcase所定义的测试系统框架，可以根据基础配置选择测试框架单元的基本参数。例如，可以选择自行上电启动kl30/kl15，如图4的f0.1所示的“powertcu”项。同时，可以根据测试目的自由选择启动或不启动tcu标定系统软件canape，例如参照图4的f0.1中的项目“usecanape”。如果需要观测tcu内部状态，还可以选择开启初始化canape接口。测试任务相关变量和参数值的采集也可以包含在测试框架单元的基础框架配置中，例如hil装置的仿真模型中的变量采集和基于canape xcp协议的车辆设备控制器tcu的变量测试值的采集，参见图4的标记f0.1中的measurement部分。
71.对测试框架单元进行基础框架配置后，在步骤s330中基于测试框架集经由在环硬件接口向在环硬件装置发送测试请求，实施测试任务。在发送测试请求之前，可以进行测试初始化。测试初始化包括测试输入变量集定义的整个测试任务集合的测试环境初始化，以及与测试框架集中的至少一个测试框架所对应的当前测试任务的测试任务初始化。
72.参见图4的标记f1 enviroment-initialization，测试环境初始化涉及测试任务集合和/或本次测试任务进行的环境条件配置，如整车上电，钥匙开关开启等。参见图4的f2所标记的test-initialization，测试任务初始化针对当前测试任务，是本次测试的前置条件。测试任务初始化包括测试任务的例如can通讯服务初始化的相关量初始化，例如传感器执行器故障仿真注入等的故障注入初始化，以及其它一些和本次测试任务相关的初始化，这些初始化设置也可以放置到次模块中。例如，f2.1所示的次模块涉及故障注入仿真端口配置的模块库。
73.完成测试环境初始化和测试任务初始化之后，开始执行测试框架集中的至少一个测试框架所定义的测试任务，经由在环硬件接口向hil装置发送测试请求。测试请求包括测试任务的一系列测试指令以及参数。测试指令包括向hil装置和/或车辆设备控制器tcu发送数据处理和获取请求，例如状态和数据读/写操作，也可以包括从hil装置和/或车辆设备控制器tcu接收数据和指令，例如接收返回数据和返回状态。这些测试请求可以包括：电气故障注入的启动或者can通讯故障注入(注入的故障诸如是计数器错误、报文超时、crc错误等)、uds命令请求、监控tcu反馈请求，故障清除、重新发送uds请求、监控tcu无故障时的反馈中的项或多项。
74.根据本公开的实施例，测试框架集中的至少一个测试框架可以包括如上所述的结构化uds测试任务。该uds测试任务集成在测试框架集中，用于实施uds读写服务以集成同步诊断测试服务。这种对应于uds的测试框架可以包括uds基本功能和故障之后的服务读写，通过上文中的同步，还可以在该uds测试服务中自动集成故障注入，从而整合到整个测试框架子系统中。例如，可以通过故障注入仿真端口ees port向hil装置注入故障，然后通过uds指令0x14及0x19等读写清除故障。这样，测试框架单元中的测试框架集的至少一个测试框架，集成了多个测试任务和/或服务，并在多个测试任务和服务之间提供逻辑同步。在上述测试框架中进行的uds服务的请求命令发送和返回服务反馈的功能，可以应用于uds dcm测试和uds dem测试(即存在故障情况下的uds测试)。参见图4的标记f3，udsteststep，示出在
测试框架集中插入的uds测试框架。f3.1则进一步示出uds测试框架中涉及故障注入仿真端口ees port的基本流程设定，例如其中eestrigger是故障注入启动，sleepon是等待时间，eesreset是故障注入清除。uds测试框架可以与f2中的故障注入仿真端口配合使用，通过uds协议读取或清除故障码。f2中的实例化子模块也可以放置到f3的uds测试框架中使用，经由f2的故障注入仿真端口来设置或清除故障。图5则更详细地示出结构化uds测试框架的详细变量和参数。
75.在步骤s340中，测试系统基于来自在环硬件装置的返回数据和车辆设备控制器的状态中的至少一个评估测试以生成测试结果，如图4所示的标记f4 evaluation项目所示。测试框架集中的测试框架不仅包括测试任务的指令和操作参数，还包括测试的评估标准。评估标准例如可以是相关变量值和操作参数的额定范围，预定阈值，也可以是相关事件或标记的状态值(例如，“真”，“假”，“高”，“低”，“可用”，“不可用”等)。将从hil装置和车辆设备控制器tcu返回的针对操作请求和故障注入的反馈信息与测试框架中的评估标准进行对比，可以评估测试过程的响应是否满足预期。对比方式例如可以是相应参数值的比较或更复杂的逻辑运算。评估的测试结果可以采用对比结果是否符合评估标准的指示值，得分，加权得分等方式。
76.在测试方法中，还可以包括测试框架单元的复位，参见步骤s350和图4中的标记f5所示的cleanup项。在完成一项测试任务后，可以对该项测试任务对应的测试框架的测试环境和/或测试条件进行清除或复位以使其回归到初始化状态。对于完成由测试案例testcase所限定的测试输入数据集对应的测试框架集来说，完成整个测试框架集的测试任务集合后，还可以对整个测试框架单元的测试环境、测试条件和配置参数中的至少一项进行清除或复位以使其回归到初始化状态。具体地，可以通过进行kl15/kl30的上下点操作，方便地完成基础测试框架的统一配置执行。测试框架单元的复位之前，还可以根据在测试框架设定的后置条件进一步检验，调整测试框架的运行。这样在整个测试任务过程中，可以通过前置条件约束、测试任务执行和评估、后置条件检验三个层级的架构设计，清楚地构建测试系统的测试框架的逻辑架构。
77.最后，测试系统在步骤s360，通过用户界面向用户提供测试结果。测试结果可以采用图形化的界面、表格等方式呈现，也可以采用可视化的数值、数值表、报告或以存储该信息的文件方式呈现，或者上述方式的结合。用户根据返回的测试结果，可以修改测试案例以输入新的测试输入数据集，或者进行下一项测试案例的操作。
78.图6示出根据本公开的实施例的测试方法中的uds服务任务的测试框架的自动化测试报告，其中包括uds指令0x19和0x14进行dem故障读写及清除的报告内容。而图7则示出测试方法中关于故障注入及dtc检测故障码的基本测试报告，其中可以通过查询故障码确定故障类型。
79.通过使用本公开的实施例的测试系统和测试方法，可以获得以下优点中的至少一项：
80.1)采用基于asam xil api和canape的车辆设备控制器自动测试系统架构，可以将测试系统和方法扩展应用于非dspace设备平台；
81.2)基于使用python的文件管理测试变量和参数，使得测试任务更方便，效率更高；
82.3)在测试的测试框架集和测试框架中前置测试条件和设定，在测试中实施测试架
构所设定的测试任务步骤并在测试请求完成后评估测试结果，在测试任务完成后基于后置条件调整测试框架的三层架构设计，逻辑结构清晰；
83.4)在测试框架中，在监控hil装置端对uds请求的反馈信息的同时，可以使用canape软件系统通过xcp协议读取测试设备tcu端的信息，提高测试效率；
84.5)优化uds dcm的测试框架脚本，在支持故障注入测试的同时监控uds诊断信息，使得测试系统和方法能够支持dem测试；
85.6)在自动化测试系统框架中集成标准化的在环硬件仿真端口maport、故障注入仿真端口ees port、车辆设备控制器监控接口asap3来与被测的车辆设备控制器tcu之间进行交互，可以应用于除了uds测试(包括dcm和dem测试)之外的其它基于automation desk和canape的功能测试；
86.7)将测试系统框架结构扩展应用于更多的车载控制器的测试，如vcu、hcu等。
87.8)完成测试任务的测试系统框架之后的每个版本可以进行高效率的回归测试，根据测试输入数据集的新编辑的需求自动生成测试报告。
88.在本公开的示例性实施例中，还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序包括可执行指令，该可执行指令被例如处理器执行时可以实现上述任意一个实施例中所述的用于测试车辆设备控制器的方法的步骤。在一些可能的实施方式中，本公开的各个方面还可以实现为一种计算机程序产品的形式，其包括可执行代码，当所述计算机程序产品的可执行代码在处理器上运行时，使处理器执行本说明书中的用于测试车辆设备控制器的方法中描述的步骤。
89.本领域技术人员在考虑说明书及实施本公开的内容后，将容易想到本公开的其它实施方案。本技术旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开中未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由所附的权利要求指出。