CN113495545A

CN113495545A - System and method for testing vehicle equipment controller using in-loop hardware

Info

Publication number: CN113495545A
Application number: CN202010191829.XA
Authority: CN
Inventors: 韩颖
Original assignee: Vitesco Technologies Holding China Co Ltd
Current assignee: Vitesco Technologies Holding China Co Ltd
Priority date: 2020-03-18
Filing date: 2020-03-18
Publication date: 2021-10-12

Abstract

The present disclosure relates to a system and method for testing a vehicle equipment controller using a hardware-in-loop (HIL) device. The system comprises a user interface and a test frame subsystem, wherein the test frame subsystem comprises a test data interface, a test frame unit, an on-loop hardware interface and a vehicle equipment controller monitoring interface. The system and the method can synchronously acquire the state information of the vehicle equipment controller while monitoring the unified diagnosis service information returned by the HIL, and provide a more comprehensive test evaluation result.

Description

System and method for testing vehicle equipment controller using in-loop hardware

Technical Field

The present disclosure relates to the field of automation of testing of automotive electronic controllers, and more particularly to a system and method for testing a vehicle equipment controller using Hardware in the Loop (HIL for short).

Background

With the popularization and application of the HIL hardware in the ring simulation technology, a large number of HIL equipment suppliers emerge. In order to unify the standards of the HIL equipment and facilitate users to freely select the HIL equipment, unified test automation scripts for various HIL equipment suppliers are designed and reused, and the ASAM standard is organized to firstly provide the ASAM HIL API standard in 6 months in 2009 and is continuously improved. The ASAM XIL API is an upgraded version of the ASAM HIL API standard.

The existing testing script based on the dSPACE HIL equipment is simple in structure, fixed in interface and not easy to expand, only can monitor information from the HIL equipment, and cannot be compatible with equipment of other suppliers (such as a Vector tool), so that the provided test has limitation.

Accordingly, there is a need for an improved HIL-based vehicle equipment controller testing system and method.

It is to be noted that the information disclosed in the above background section is only for enhancement of understanding of the background of the present disclosure, and thus may include information that does not constitute prior art known to those of ordinary skill in the art.

Disclosure of Invention

According to the embodiment of the disclosure, a system and a method for testing a vehicle equipment controller by using an HIL device are provided, which aim to test various vehicle equipment controllers by using the HIL device, expand and support more HIL devices conforming to an XIL API protocol, and simultaneously increase test monitoring information in the test to provide more comprehensive evaluation results and support more test scenes.

According to an aspect of the present disclosure, there is provided a system for testing a vehicle equipment controller using a hardware-in-loop (HIL) device, including:

a user interface configured to receive a test input data set and to provide test results;

a test frame subsystem, the test frame subsystem further comprising:

a test data interface configured to extract test data from the test input data set and forward return data from a ring hardware interface to the user interface;

a test framework unit configured to perform at least one of the following operations: configuring a test framework subsystem based on the test input dataset from the test data interface and creating a test framework set, sending a test request to the on-loop hardware interface based on the test framework set, evaluating the test to generate the test result based on at least one of return data from the on-loop hardware interface and a status of the vehicle equipment controller from the vehicle equipment controller monitoring interface, and resetting at least a portion of the test framework subsystem;

the on-ring hardware interface configured to forward the test request to the on-ring hardware device and receive the return data from the on-ring hardware device; and

a vehicle equipment controller monitoring interface configured to acquire a status of the vehicle equipment controller.

According to an embodiment of the present disclosure, the test frame subsystem is further configured to synchronize the vehicle equipment controller with the on-loop hardware device.

According to another aspect of the present disclosure, there is provided a method for testing a vehicle equipment controller using a hardware-in-loop (HIL) device, including:

receiving a test input data set through a user interface;

configuring a test framework subsystem and creating a test framework set based on the test input dataset, wherein the test framework subsystem comprises a test data interface, a test framework unit, an on-loop hardware interface and a vehicle equipment controller monitoring interface, the test framework unit comprising the test framework set;

sending a test request to the in-loop hardware device via the in-loop hardware interface based on the test frameset;

evaluating the test based on at least one of return data from the on-loop hardware device and a status of the vehicle equipment controller from the vehicle equipment controller monitoring interface to generate a test result;

resetting the test frame unit; and

providing the test result through a user interface.

According to an embodiment of the present disclosure, configuring the test frame subsystem further comprises synchronizing the vehicle equipment controller with the on-loop hardware device.

According to yet another aspect of the present disclosure, there is provided a non-transitory computer readable storage medium having stored thereon a computer program comprising executable instructions which, when executed by a processor, implement the method as described above.

According to yet another aspect of the present disclosure, there is provided an electronic device comprising a processor and a memory for storing executable instructions of the processor, the processor being configured to execute the executable instructions to implement the method as described above.

By adopting the test system and method based on the ASAM XIL API standard, the test system and method can be applied to various non-dSPACE HIL equipment, and can synchronously acquire the state information of vehicle equipment controllers (such as a Transmission Control Unit (TCU), an Electronic Control Unit (ECU) and the like) while monitoring Unified Diagnostic Service (UDS) information returned by the HIL, thereby providing more comprehensive test evaluation results. The test system and the test method are higher in efficiency, not only suitable for UDS tests including DCM and DEM (diagnostic Event management) S, but also applicable to other vehicle equipment controller function tests based on Automation Desk and CANape, and more applicable vehicle equipment controllers.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The above and other features and advantages of the present disclosure will become more apparent by describing in detail exemplary embodiments thereof with reference to the attached drawings.

FIG. 1 shows a schematic diagram of an exemplary test system architecture based on the ASAM XIL API standard;

FIG. 2 shows a schematic diagram of an exemplary test system architecture, according to an embodiment of the present disclosure;

FIG. 3 shows a flow diagram of an exemplary testing method according to an embodiment of the present disclosure;

FIG. 4 illustrates a logical schematic of a test framework set of test framework units of an exemplary test system and method in accordance with embodiments of the present disclosure;

FIG. 5 illustrates a logical schematic diagram of the UDS test framework of the test framework set in FIG. 4;

FIG. 6 illustrates an automated test report on a UDS service task testing framework in an exemplary testing method according to an embodiment of the present disclosure; and

fig. 7 illustrates a basic test report on fault injection and DTC detection fault codes in an exemplary test method according to an embodiment of the present disclosure.

Detailed Description

Exemplary embodiments will now be described more fully with reference to the accompanying drawings. The exemplary embodiments, however, may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art. In the drawings, the size of some of the elements may be exaggerated or distorted for clarity. The same reference numerals denote the same or similar structures in the drawings, and thus detailed descriptions thereof will be omitted.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the disclosure. One skilled in the relevant art will recognize, however, that the subject matter of the present disclosure can be practiced without one or more of the specific details, or with other methods, components, etc. In other instances, well-known structures, methods, or operations are not shown or described in detail to avoid obscuring aspects of the disclosure.

The ASAM XIL API is a communications standard between a vehicle test automation tool and a test station that standardizes the interface between the test station hardware of the test system and the test automation tool software to facilitate reuse of test cases on different test station hardware and to make the test automation tool software independent of the test station hardware. For example, the user may:

repeat automated testing on test bench systems provided by different hardware vendors;

reduce training costs for employees;

improve the technology migration between different testbench hardware.

The HIL device, as an important test bench hardware in the test simulation of the vehicle device controller, can simulate electrical information (e.g., sensor information from an engine or a transmission) of a physical entity such as a real controlled vehicle device (e.g., an engine or a transmission) or a system, and provide the same or similar interface and operation mode as a simulated object, so that the tested device controller can obtain a test condition when accessing a simulated vehicle device controller use environment without being installed in an actual vehicle. The HIL equipment needs to be controlled based on a model, and the running state of a simulated object is uploaded to an upper computer (generally a PC) by matched test software in a manual or automatic mode. A test case (Testcase) running on an upper computer may also be referred to herein as a test input data set, which mainly includes test framework configuration and test data, among other things. By running the test case, it is possible to monitor the running process of the simulated object while transmitting measurement information such as sensor data of the simulated object to the object under test (e.g. a transmission control unit TCU, an electronic control unit ECU, etc. of the vehicle). In an embodiment of the present disclosure, the HIL device is employed as test bench hardware in a test system of the ASAM XIL API standard.

FIG. 1 illustrates an exemplary test system architecture based on the ASAM XIL API standard.

The ASAM xl API standard mainly includes two major interface standards, namely, a Package frame Application programming interface (Package frame Application API, hereinafter, simply referred to as a frame Application interface) and a test bench Application programming interface (Package test bench Application API, hereinafter, simply referred to as a test bench Application interface).

The test system architecture 100 mainly includes a test automation user interface layer 110, a Framework application program interface 120, a Framework (FW) layer 130, and a test bench application program interface 140. The test system architecture 100 performs data interaction with a test bench (TestBench, TB)150 through a test bench application program interface 140.

The test automation user interface 110 provides an interactive interface for the test automation system/tool with the user, receiving the user's test input data set in the form of a test case Testcase. The test input data set, which includes configuration parameters for the test automation system and data regarding test conditions, test task items, and test parameters for the test task, is input to the framework 130 via the framework application interface 120 via a multivariate-based access. The test input data set further comprises framework access data for interaction with the framework FW and test floor port access data for interaction with the test floor HIL hardware, respectively.

The functionality of the framework application interface 120 is defined as: variable mapping and data logging, data type or variable identification, and interface-based test station interaction rules are valid functional interfaces that the framework 130 uses for the test station 150. The framework application interface 120 transmits framework access data from the user interface 110 to the framework layer 130 via a framework control port FW control to provide configuration data Cfg configuring the set of frameworks, and receives framework data from the set of frameworks of the framework layer 130. The framework application interface 120 can also transmit corresponding input data in the test input data set to the framework layer 130 through a framework variable port FW variable, a framework acquisition port FW acquisition, a framework startup port FW simulation, and a framework monitor port FW checker, respectively. Framework application interface 120 may also have test floor Ports TB-Ports to receive test return data sent from test floor application interface 140 that originated from HIL hardware devices and provide to users in the form of test floor port access data.

Framework layer 130 creates and configures a framework set implementing the corresponding test tasks based on the test input data set, sends test requests to the HIL hardware devices of test floor 10 via test floor application program interface 140 by, for example, mapping, receives test return data from the HIL hardware devices, evaluates the return data, and resets some or all parameters of test framework layer 140 and/or framework application program interface 120 and test floor application program interface 140. The mapping may map specific protocols/ports of different HIL hardware devices to common protocols/ports used by a user interface layer used by a user, and complete data transmission and forwarding through the framework application program interface and the test bench application program interface, respectively. The Framework (FW) in framework layer 130 may be a library of modules provided by a software vendor that provides software for use with HIL devices.

In embodiments of the present disclosure, the framework may encompass a wider range of content. The framework is not only a library of function modules, but also includes function/module definition and configuration data for implementing test tasks, environment and/or condition data for test tasks, instructions for executing test tasks (typically presented in the form of test requests) and instruction parameters thereof, and the like. The function packages and data can be combined into an integrated plug-in or tool package to be applied to a test system platform. Thus, the framework in this disclosure may be thought of as instructions (e.g., a set of functions) and a set of parameter data corresponding to a test task, the instructions may have a set sequence. The one or more test tasks may constitute a series of test task sets included in the test case that complete the test procedure, corresponding to a test framework set constituted by at least one test framework.

The functionality of the test floor application interface 140 is defined as: an emulation Port MA for accessing the HIL hardware emulation model/offline emulation, data ports related to the ECU (calibration ECUC, measurement ECUM and diagnostic DIAG), an electrical fault injection emulation Port EES Port and a Network Port Network, etc. Test floor application interface 140 in FIG. 1 may also configure parameters Cfg for each port by receiving configuration data corresponding to a test floor HIL device from a test floor input data set forwarded from a test floor port of framework application interface 120. Through the testbench api 140, the test input data set of the test case may be configured and communicated to and from the HIL hardware device of the testbench 10 to perform the corresponding test tasks.

Fig. 2 illustrates a vehicle equipment controller automated testing system framework in which control and data interaction is performed with HIL hardware devices and TCU equipment of a vehicle based on the ASAM xl API standard protocol and the CANape system, according to an example embodiment of the present disclosure. The test system can be realized on a platform of automated test software Automation Desk of dSPACE company. In the embodiment of the disclosure, data input and state observation of the test process can be performed on an upper computer (such as a PC) through an Automation Desk automated test software platform in combination with a simulation model of an HIL device and CANape software used by a Vector company for calibrating and observing a vehicle equipment controller (such as a TCU). The host computer passes through the simulation model control HIL device of HIL device, and the CANape system controls CANape system hardware through corresponding CANape software. The communication link CAN be carried out to the adoption TCP/IP agreement standard between host computer and the HIL device, CAN link through the physics pencil between HIL device and the vehicle equipment controller, and the vehicle equipment controller CAN link to CANape system hardware through CAN bus interface, and CANape system hardware rethread links to the host computer through data port such as the USB standard.

In this specification, a vehicle equipment controller test system and method are described with a transmission control unit TCU of a vehicle as a vehicle equipment controller. Those skilled in the art will appreciate that the vehicular equipment controllers may also include other various vehicular equipment controllers such as an ECU, VCH, HCU, and the like. Interaction with the vehicle equipment controller may also employ systems other than the CANape system, access the TCU using various protocol APIs such as the XCP protocol, ASAP3 protocol instantiated by Vector corporation, and the like. Hereinafter, portions of fig. 2 similar or identical to those of fig. 1 will not be described in detail.

The test system 200 generally includes a user interface 210, a test data interface 220, a test framework unit 230, a hardware-in-the-loop HIL interface 240 and a vehicle equipment controller monitoring interface 260.

The user interface 210 is similar to the test automation user interface layer 110 in fig. 1 for receiving a user test input data set 211 in the form of a test case Testcase and providing test results to the user. The user interface 210 may take the form of a graphical interface, or may take the form of a command line or otherwise interact with the user. The test input data set 211 includes all data for performing vehicle equipment controller tests including, but not limited to, configuration parameters of the architecture of the test system 200, test mission data, test pre-and post-condition data, and the like.

Test data interface 220, frame test framework unit 230, in-loop hardware interface 240 and vehicle equipment controller monitor interface 260 may constitute a test framework subsystem.

The test data interface 220 is similar to the framework application interface 120 of FIG. 1 for extracting test data, such as architecture configuration parameters and test task data, from the test input data set 211 and forwarding return data from the HIL device 250 received at the ring hardware interface 240 to the user interface 210. The test data interface 220 may employ various ports of the framework application program interface 120 for variable mapping and data forwarding, exchanging data with the test framework set in the test framework unit 230, the port in the ring hardware interface 240 corresponding to the ring hardware HIL device 250, and the corresponding port of the vehicle equipment controller monitoring interface 260.

Similar to the framework layer 130 of fig. 1, the test framework unit 230 may configure a test framework subsystem based on the test input dataset 211 from the test data interface 220 and create the test framework set, send a test request to the on-ring hardware interface 240 based on the created test framework set, evaluate a test task based on at least one of return data from a vehicle platform or device simulated by the HIL apparatus 250 of the ring hardware interface 240 and a state of the vehicle device controller 270 to generate a test result, and reset at least a portion of the test framework subsystem based on the test result.

Configuring the test framework subsystem based on the test input dataset and creating the test framework set may include configuring parameters of various portions of the test framework subsystem with the architecture configuration parameters in the test input dataset, such as configuring operating parameters of test data interface 220, ring hardware interface 240, and vehicle equipment controller monitoring interface 260. Wherein configuring the vehicle equipment controller monitoring interface 260 may include calibrating and/or synchronizing the vehicle equipment controller TCU 270 with the on-loop hardware HIL apparatus 250. By carrying out clock calibration on the vehicle equipment controller TCU 270 based on the CANape system and synchronizing the HIL device 250 and the vehicle equipment controller TCU 270, the response of the vehicle equipment controller TCU 270 to the corresponding fault and the generated corresponding fault code can be synchronously observed while fault injection is carried out on the HIL device.

Creating the set of test frames includes constructing at least one test frame in the set of frame elements based on the test task data, each test frame corresponding to one or more test tasks. The existing test script framework structure based on the unified diagnostic service UDS is a standard software module provided by a device vendor, and the existing test script framework structure is based on a customized in-loop hardware simulation Port MA Port based on dSPACE iconization, and is limited in that other functions are not conveniently integrated, flexible expansion cannot be carried out, and other tools such as Vector cannot be compatible. By using the test system architecture 200 standardized based on the ASAM XIL API protocol, the diagnostic test service can be integrated by implementing a corresponding test framework for implementing the UDS read-write service in the test framework set after initializing the standard on the ring hardware emulation Port MA Port using the function library provided by the protocol. Such a test framework corresponding to UDS may include UDS basic functions and service read-write after failure, and through the above synchronization, failure injection may also be automatically integrated in the UDS test service and thus integrated into the entire test framework subsystem. For example, a fault may be injected into the HIL device through the fault injection emulation Port EES Port and then handled through the UDS' service instructions. For example, a fault may be read by UDS instruction 0x14, and cleared by UDS instruction 0x 19. In this way, at least one test framework of the set of test frameworks in the test framework unit integrates multiple test tasks and/or services and provides logical and temporal synchronization between the multiple test tasks and services. According to embodiments of the present disclosure, the UDS test framework may employ a different standard than other test frameworks.

The in-loop hardware interface 240 is similar to the test floor application program interface 140 of FIG. 1 for forwarding test requests defined by the test framework set from the test framework unit 230 to the HIL device 250 and receiving test return data from the HIL device 250. According to an embodiment, the on-ring hardware interface 240 may include on-ring hardware emulation ports MA Port, fault injection emulation ports EES Port, and diagnostic ports DIAG Port. The ring hardware emulation port is used for converting the test request defined by the test frameset in the test frameunit 230 into data acceptable by the protocol standard of the HIL hardware device 250, and returning the data of the HIL hardware device 250 for the test request to test the data which the frameset can receive. And most data interface functions of vehicle simulation test by using HIL hardware equipment are realized at the ring hardware simulation port. The fault injection simulation port is used for performing fault injection operation on the whole vehicle system simulated by the HIL device, and simulating the faults of the whole vehicle system to verify the fault detection and response mechanism of the tested vehicle equipment controller TCU 270. According to an embodiment of the present disclosure, the on-ring hardware emulation port fault injection emulation port and the diagnostic port of the on-ring hardware interface 240, etc. employ the ASAM xl API protocol standard.

For example, the measurement framework set may inject a fault into a sensor or an actuator through the fault injection simulation port, and may send a UDS request to the TCU through the API protocol of the CANape system via the vehicle equipment controller monitoring interface 260 to read fault diagnosis status information of the TCU, such as a DTC diagnostic code. The fault diagnosis status information of the TCU is provided to the test framework set of the test framework unit 230, which then performs evaluation and provides the evaluated test results to the user at the user interface 210.

By synchronizing the clocks of the HIL device 260 and the vehicle equipment controller TCU 270, the states of the HIL device 250 and the vehicle equipment controller TCU 270 can be simultaneously monitored based on the test framework unit 230 of the test system of the present disclosure and comparison of the respective returned results can be automatically performed by a simple setting. The HIL device 250 end can also inject simulation faults into the vehicle equipment controller TCU 270 end, meanwhile, the HIL device 250 end simulates the whole vehicle to send a diagnosis request, and the vehicle equipment controller TCU 270 end can timely respond to the diagnosis request and send feedback information to the HIL device 250. In this way, the automatic test efficiency and the universality of the vehicle equipment controller TCU 270 can be improved.

In fig. 2, the vehicle equipment controller 270 is the object to be tested for the test task. For example, the vehicular apparatus controller 270 may be a TCU, an ECU, an HCU, a VCU, and the like of the vehicle. The vehicle equipment controller monitoring interface 260 differs from the on-loop hardware interface 240 in that the monitoring interface 260 is used to forward test requests defined from the test framework set of the test framework unit 230 to the vehicle equipment controller 270 and to receive status return data from the vehicle equipment controller 270. The test requests include, but are not limited to, clock calibration of the vehicle equipment controller TCU 270 and extraction of status information, and the status return data includes, but is not limited to, fault responses and fault codes after a fault is injected for the HIL apparatus 250. The vehicle equipment controller monitoring interface 260 may, for example, employ an ASAP3 interface protocol to communicate with a CANape system, which is used to control the TCU. Other vehicle equipment controllers using the CANape system may also be tested as well.

FIG. 3 illustrates a method for testing a vehicle equipment controller using on-loop hardware devices according to an embodiment of the present disclosure. The method will be described in detail below with reference to the logic diagrams of fig. 4 and 5 based on fig. 3. The test method comprises the following steps.

S310: a test input data set is received through a user interface. The test input data set includes architecture configuration data and test task related data for configuring the test system (primarily the test framework subsystem).

Then, in step S320, the test framework subsystem is configured based on the test input data set and a test framework set is created.

The basic configuration of the test framework subsystem is first standardized. The UDSNewFrameWork framework is used to create a test framework subsystem, as indicated by F0 in the logical part of fig. 4, where F0.1 in the left part of the logical diagram is used to configure the various interfaces in the test framework subsystem. For example, for the test data interface 220 shown in fig. 2, the data interaction ports between the test data interface and the test framework unit are respectively configured using the architecture configuration data, including but not limited to the variable definition and initial value of the framework, the collection port setting, the start port setting, the monitoring port setting, the framework control instruction parameter, and the HIL device setting. Test conditions from a preceding test input data set may be used in the normalization to constrain the test system and method.

For the on-ring hardware interface 240, the on-ring hardware emulation ports MA Port and the fault injection emulation ports EES Port can be configuration standardized based on the standard library functions of the XIL API standard, respectively. After the loop hardware simulation port is configured to complete initialization of a simulation model interface of the test system and the HIL device, read-write operation can be further performed on variables in a real-time simulation model of the HIL device. The HIL real-time model simulates a whole vehicle system interacted with a vehicle equipment controller TCU, and the HIL device simulation model comprises CAN communication, a UDS request, simulation of a sensor, signal acquisition of a TCU actuator and the like. And configuring a fault injection simulation Port EES Port to complete fault injection interface configuration initialization. After the configuration of the fault injection simulation port is initialized, fault injection operation can be further performed on the whole vehicle system simulated by the simulation model of the HIL device to simulate the fault of the whole vehicle system, so that the fault detection mechanism of the tested vehicle equipment controller TCU is verified. The synchronization procedure between fault injection operation and response of the HIL device and the synchronous sending of a request to the vehicle equipment controller TCU via the UDS service to read the response of the TCU to the fault detection has been described above.

The test variables and the configuration data are managed based on the python file, so that the method is more convenient to modify compared with an interface input mode and is not limited to the automatic test software. The variable list is independent, if the model is changed, the python file can be directly modified without opening automatic test software Automation Desk to modify the variables one by one, and the automatic test efficiency is high and the maintainability is strong. In addition, the python-based library file may extend the testing system to platforms other than dSPACE's Automation Desk. According to an embodiment, the data of the test input data set may also be managed in a file format of a structured language other than python. The documentation management includes two main variable lists, which are respectively: defining variables in the model using a model variable description mapping table of the HIL device interacting between the ring hardware interface 240 and the HIL device, provided in the form of a python library file "hilsignallsmap.py" shown in C2; and a variable description mapping table of the vehicle equipment controller TCU using the vehicle equipment controller monitoring interface 260 to define TCU variables to be used during the TCU test, provided using a python library file "tcusignallsmap. The configuration data of the ring hardware interface 240 is given in a python library file "globalconfig. py" shown in C1 in fig. 4, which includes, for example, configuration information of a test procedure applied by the test system framework architecture, such as an item applied by the HIL hardware device, a model of the TCU to be tested, and the like. The file may include a large library of functions. Similarly, the python library file "Stimulation sequence. py" shown as C3 in FIG. 4 gives information on the start sequence of the test framesets in the various interface and test frameunits. Through the user library configuration and data defined based on the dsace underlying function library stored in these files, the framework architecture of the automatic test system required for completing the task set of the test process in the embodiment of the present disclosure can be established and configured.

For the vehicle equipment controller monitoring interface 260, it is possible to select whether to start an interface for initializing the CANape system and configuration thereof, for example, according to whether to observe the internal state of the vehicle equipment controller TCU 270. In the embodiment of the present disclosure, the vehicle equipment controller monitoring interface 260 employs a standard interface API of the CANape system, which is not described in detail herein.

The creation and configuration of the test framework unit comprises the steps of creating a test framework set and carrying out structural standardized configuration on the test framework set. For example, for a test input data set entered by a user interface, the test system framework defined by the test case Testcase may select the basic parameters of the test framework elements according to the underlying configuration. For example, the "PowerTCU" entry shown in F0.1 of fig. 4 may be selected to power up KL30/KL15 by itself. Meanwhile, the TCU calibration system software CANape can be freely selected to be started or not started according to the test purpose, for example, refer to the item "UseCANape" in F0.1 of fig. 4. If the internal state of the TCU needs to be observed, the initialization CANape interface can be started optionally. The collection of test task related variables and parameter values may also be included in the basic framework configuration of the test framework unit, such as the collection of variables in the simulation model of the HIL device and the collection of variable test values of the vehicle equipment controller TCU based on the CANape XCP protocol, see the measurement section in reference F0.1 of fig. 4.

After the basic frame configuration is performed on the test frame unit, in step S330, a test request is sent to the on-ring hardware device via the on-ring hardware interface based on the test frame set, and a test task is performed. Test initialization may be performed before sending a test request. The test initialization includes test environment initialization of an entire set of test tasks defined by the set of test input variables, and test task initialization of a current test task corresponding to at least one test framework in the set of test frameworks.

Referring to the label F1 environment-initialization of fig. 4, the test environment initialization relates to the test task set and/or the configuration of the environmental conditions performed by the current test task, such as powering on the entire vehicle, turning on the key switch, and the like. Referring to Test-initialization labeled F2 of FIG. 4, Test task initialization is a precondition for this Test for the current Test task. The test task initialization comprises initialization of relevant quantities of the test task, such as initialization of a CAN communication service, initialization of fault injection, such as fault simulation injection of a sensor actuator, and the like, and other initialization relevant to the test task, and the initialization settings CAN also be placed in the secondary module. For example, the sub-module shown in F2.1 relates to a library of modules of fault injection emulation port configurations.

After the test environment initialization and the test task initialization are completed, the test task defined by at least one test framework in the test framework set is started to be executed, and a test request is sent to the HIL device through the in-loop hardware interface. The test request includes a series of test instructions and parameters for the test task. The test instructions include sending data processing and acquisition requests, such as status and data read/write operations, to the HIL device and/or the vehicle equipment controller TCU, and may also include receiving data and instructions, such as return data and return status, from the HIL device and/or the vehicle equipment controller TCU. These test requests may include: initiation of electrical fault injection or CAN communication fault injection (injected faults such as counter error, message timeout, CRC error, etc.), UDS command request, monitoring TCU feedback request, fault clearance, resending UDS request, monitoring feedback when TCU is faultless.

According to embodiments of the present disclosure, at least one test framework of a set of test frameworks may include a structured UDS test task as described above. The UDS test tasks are integrated in a test framework set and used for implementing UDS read-write services to integrate synchronous diagnostic test services. Such a test framework corresponding to UDS may include UDS basic functions and service read-write after failure, and through the above synchronization, failure injection may also be automatically integrated in the UDS test service and thus integrated into the entire test framework subsystem. For example, a fault may be injected into the HIL device through the fault injection emulation Port EES Port, and then cleared by reading and writing UDS instructions 0x14 and 0x19, etc. In this way, at least one test framework of the set of test frameworks in the test framework unit integrates multiple test tasks and/or services and provides logical synchronization between the multiple test tasks and services. The functions of request command sending and return service feedback for UDS services performed in the above test framework can be applied to UDS DCM testing and UDS DEM testing (i.e. UDS testing in the presence of faults). See FIG. 4 labeled F3, UDSTeststep, showing a UDS test frame inserted in the test frame set. F3.1 further shows the basic flow settings in the UDS test framework involving the fault injection simulation Port EES Port, e.g. where EEStrigger is fault injection start, SleepOn is latency, and EESReset is fault injection clear. The UDS test framework can be used with the fault injection emulation port in F2 to read or clear fault codes via the UDS protocol. The instantiation sub-module in F2 may also be placed into the UDS test framework of F3 for use, setting or clearing faults via the fault injection simulation port of F2. FIG. 5 shows in more detail the detailed variables and parameters of the structured UDS test framework.

In step S340, the test system evaluates the test based on at least one of the return data from the ring hardware devices and the status of the vehicle equipment controller to generate a test result, as indicated by the Evaluation item labeled F4 shown in fig. 4. The test framework in the test framework set includes not only the instructions and operating parameters of the test tasks, but also the evaluation criteria of the test. The evaluation criteria can be, for example, the value of the relevant variable and the nominal range of the operating parameter, a predetermined threshold, or the status value of the relevant event or flag (e.g., "true", "false", "high", "low", "available", "unavailable", etc.). Comparing feedback information for operation requests and fault injection returned from the HIL device and the vehicle equipment controller TCU with evaluation criteria in the test framework, it can be evaluated whether the response of the test procedure meets expectations. The way of comparison may be, for example, a comparison of the respective parameter values or a more complex logical operation. The test result of the evaluation can adopt the modes of indicating value, score, weighted score and the like for comparing whether the result meets the evaluation standard.

In the test method, resetting of the test frame unit may also be included, see step S350 and the clearup entry shown by the label F5 in fig. 4. After a test task is completed, the test environment and/or test conditions of the test framework corresponding to the test task may be cleared or reset to return to the initialization state. For the test frame set corresponding to the test input data set defined by the test case testcase, after the test task set of the whole test frame set is completed, at least one of the test environment, the test condition and the configuration parameter of the whole test frame unit can be cleared or reset to return to the initialization state. Specifically, unified configuration execution of the basic test framework can be conveniently completed by performing upper and lower point operations of KL15/KL 30. Before the resetting of the test frame unit, the operation of the test frame can be further checked according to the post condition set in the test frame unit, and the operation of the test frame unit can be adjusted. Therefore, in the whole test task process, the architecture design of three levels can be checked through precondition constraint, test task execution and evaluation and postcondition, and the logic architecture of the test framework of the test system can be clearly constructed.

Finally, the test system provides the test results to the user through the user interface at step S360. The test result can be presented in the form of graphical interface, table, etc., or in the form of visual numerical value, numerical value table, report, or file storing the information, or in combination of the above. The user can modify the test case to input a new test input data set or perform the next test case operation according to the returned test result.

Fig. 6 illustrates an automated test report of a test framework of a UDS service task in a test method according to an embodiment of the present disclosure, wherein the report includes report contents of UDS instructions 0x19 and 0x14 for DEM fault reading, writing and clearing. Fig. 7 shows a basic test report of fault injection and DTC detection fault codes in the test method, wherein the fault type can be determined by querying the fault codes.

By using the test system and the test method of the embodiments of the present disclosure, at least one of the following advantages can be obtained:

1) by adopting an automatic test system architecture of the vehicle equipment controller based on ASAM XIL API and CANape, the test system and method can be expanded and applied to a non-dSPACE equipment platform;

2) the testing variables and parameters are managed based on the file using python, so that the testing task is more convenient and the efficiency is higher;

3) test conditions and settings are preset in the test framework set and the test framework, the test task step set by the test framework is implemented in the test, the test result is evaluated after the test request is completed, the three-layer framework design of the test framework is adjusted based on the postposition conditions after the test task is completed, and the logic structure is clear;

4) in a testing framework, when feedback information of an HIL device end to a UDS request is monitored, a CANape software system can be used for reading information of a TCU end of testing equipment through an XCP protocol, so that the testing efficiency is improved;

5) optimizing a test framework script of the UDS DCM, and monitoring UDS diagnostic information while supporting fault injection test, so that the test system and the method can support DEM test;

6) the method is characterized in that a standardized in-loop hardware simulation Port MAPort, a fault injection simulation Port EES Port and a vehicle equipment controller monitoring interface ASAP3 are integrated in an automatic test system framework to interact with a tested vehicle equipment controller TCU, and the method can be applied to other function tests based on Automation Desk and CANape except UDS tests (including DCM and DEM tests);

7) the test system framework structure is expanded to be applied to the test of more vehicle-mounted controllers, such as VCUs, HCUs and the like.

8) Each version after the testing system framework of the testing task is completed can be subjected to high-efficiency regression testing, and a testing report is automatically generated according to the newly edited requirement of the testing input data set.

In an exemplary embodiment of the disclosure, there is also provided a computer readable storage medium having stored thereon a computer program comprising executable instructions which, when executed by, for example, a processor, may implement the steps of the method for testing a vehicle equipment controller described in any one of the above embodiments. In some possible embodiments, the various aspects of the disclosure may also be embodied in the form of a computer program product comprising executable code which, when run on a processor, causes the processor to perform the steps described in the method for testing a vehicle equipment controller in the present description.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure. This application is intended to cover any variations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

Claims

1. A system for testing a vehicle equipment controller using a hardware-in-loop (HIL) installation, comprising:

a test frame subsystem, the test frame subsystem further comprising:

2. The system of claim 1, wherein the test framework subsystem is further configured to synchronize the vehicle equipment controller with the on-loop hardware device.

3. The system of claim 1 or 2, wherein configuring a test framework subsystem based on the test input dataset from the test data interface and creating a test framework set further comprises:

configuring the test data interface;

configuring the on-ring hardware interface, the on-ring hardware interface including at least one of an on-ring hardware emulation port, a fault injection emulation port, and a diagnostic port;

configuring a monitoring interface of the vehicle equipment controller; and

creating at least one test frame in the set of frame elements.

4. The system of claim 3, wherein the at least one test framework comprises a vehicle Universal Diagnostic Service (UDS) test framework.

5. A system as claimed in claim 1 or 2, wherein the test input data set is in the form of a library file.

6. The system of claim 1 or 2, wherein the vehicle equipment controller monitoring interface is connected to a CANape system.

7. The system of claim 1 or 2, wherein the in-loop hardware interface employs the ASAM XIL API standard.

8. A method for testing a vehicle equipment controller using a ring Hardware (HIL) installation, comprising:

receiving a test input data set through a user interface;

resetting the test frame unit; and

providing the test result through a user interface.

9. The method of claim 8, wherein configuring a test framework subsystem further comprises synchronizing the vehicle equipment controller with the on-loop hardware device.

10. The method of claim 8 or 9, wherein configuring a test framework subsystem based on the test input dataset and creating a test framework set further comprises:

configuring the test data interface;

configuring a monitoring interface of the vehicle equipment controller; and

creating at least one test frame in the set of frame elements.

11. The method of claim 10, wherein the at least one test framework comprises a vehicle Universal Diagnostic Service (UDS) test framework.

12. A method as claimed in claim 8 or 9, wherein the test input data set is in the form of a library file.

13. The method of claim 8 or 9, wherein the vehicle equipment controller monitoring interface is connected to a CANape system.

14. The method of claim 8 or 9, wherein the in-loop hardware interface employs the ASAM xl API standard.

15. A non-transitory computer readable storage medium having stored thereon a computer program comprising executable instructions which, when executed by a processor, implement the method of any one of claims 8 to 14.

16. An electronic device, comprising:

a processor; and

a memory for storing executable instructions of the processor;

wherein the processor is configured to execute the executable instructions to implement the method of any of claims 8 to 14.