Hardware-in-the-loop simulation method for body domain controller under autosar architecture

Abstract

The application discloses a hardware-in-loop simulation method of a vehicle body domain controller under an AUTOSAR architecture, and the main idea of the application is that a standardized mapping relationship database of a HIL cabinet hardware channel is established based on standardized interface definition of an AUTOSAR basic software layer, and a hardware corresponding relationship configuration file template is constructed; in combination with different function specifications, a subsystem simulation model is built for each function module, a three-layer decoupling architecture is constructed, and dynamic binding of test software and the hardware channel is realized; then, based on actual hardware interfaces and software function definitions, a simulation test bench is built and verification is completed; finally, automatic test cases are generated based on the function specifications, and each subsystem function test of the vehicle body domain controller is carried out in the current test environment. The application significantly shortens the development cycle of the test bench, improves the flexibility and expandability of the test environment, and optimizes the whole life cycle test verification capability.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of automobile electronic and electrical test, and particularly relates to a hardware-in-the-loop simulation method for a body domain controller under an AUTOSAR architecture. BACKGROUND

[0002] With the development of the automobile electronic and electrical architecture to the domain centralized type, a body domain controller (VIU: one of the core control modules in the automobile electronic and electrical architecture, a domain controller integrating the body electronic functions such as light, door lock and window, and developed according to the AUTOSAR architecture) needs to integrate dozens of traditional ECU functions.

[0003] In the development process of the body domain controller, the functional reliability of the body domain controller in the real hardware environment needs to be verified, and the current test scheme at least has the following defects:

[0004] 1) Real loads need to be connected in addition to the controller, the test bench is complex, the maintenance cost is high, and the expandability is poor;

[0005] 2) The test bench hardware is highly bound to the test environment and the simulation model, and has poor reusability and high migration cost;

[0006] 3) The development of the test bench must wait until the controller product development is completed, and the timeliness is poor. SUMMARY

[0007] In view of the above, the present application aims to provide a hardware-in-the-loop simulation method for a body domain controller under an AUTOSAR architecture to solve the aforementioned technical problems.

[0008] The technical scheme adopted by the present application is as follows:

[0009] The present application provides a hardware-in-the-loop simulation method for a body domain controller under an AUTOSAR architecture, which comprises:

[0010] Based on the standardized interface definition of the AUTOSAR basic software layer, a standardized mapping relationship library of the HIL cabinet hardware channel is established;

[0011] A configuration file for establishing the correspondence between the physical interface of the controller and the HIL cabinet channel is constructed in combination with the mapping relationship library;

[0012] According to different functional specifications, subsystem closed-loop simulation models are built for each functional module controlled by the body domain controller;

[0013] A three-layer decoupling architecture is constructed to realize the dynamic binding of the test software logic and the hardware channel; the three-layer decoupling architecture comprises an application layer, an interface mapping layer and a hardware execution layer;

[0014] Based on the actual hardware interface and software function definition of the body domain controller, the HIL cabinet hardware channel and each subsystem model in the model library are configured, and a simulation test bench is built;

[0015] The body domain controller is verified by using the simulation test bench;

[0016] After verification, the automatic test case is generated based on the function specification, and the function test of each subsystem of the body domain controller is carried out in the test environment of the current simulation test bench.

[0017] In at least one possible implementation, the subsystem closed-loop simulation model built for each function module controlled by the body domain controller includes at least a load characteristic model, a sensor simulation model, and a vehicle network model, and forms a parameterizable Simulink subsystem model library.

[0018] In at least one possible implementation, the verification of the body domain controller by using the simulation test bench includes real-time closed-loop verification based on a real hardware-in-the-loop simulation test environment, and monitoring whether the state machine transition of the body domain controller meets the preset function specification.

[0019] In at least one possible implementation, the simulation method further includes: according to the change of the software version of the body domain controller, maintaining the simulation test bench: adjusting the hardware channel and the selected subsystem simulation model, and carrying out multiple rounds of regression testing after adjustment.

[0020] In at least one possible implementation, the establishment of the HIL cabinet hardware channel standardized mapping relationship library at least includes:

[0021] The CAN / LIN communication interface is configured with a fixed cabinet channel;

[0022] The power drive interface adopts a unified hardware board card;

[0023] The sensor input interface is configured with a standardized signal conditioning unit.

[0024] In at least one possible implementation, the configuration file for establishing the corresponding relationship between the controller physical interface and the HIL cabinet channel in combination with the mapping relationship library includes: the mapping relationship between the controller pin and the HIL cabinet channel is established through a hardware abstraction layer configuration file to form a reusable hardware interface configuration template.

[0025] In at least one possible implementation, the complete simulation test bench comprises a vehicle body domain controller, a HIL cabinet comprising at least an I / O and communication board and a real-time machine, and a host computer; the vehicle body domain controller is connected to the HIL cabinet through a hard line, and the HIL cabinet is connected to the host computer through an Ethernet line.

[0026] Compared with the prior art, the main design concept of the application is to construct a modular and reusable HIL simulation test system based on the software and hardware layering characteristics of the AUTOSAR architecture, and to develop a test process simultaneously to realize early development of the test bench: according to the AUTOSAR interface definition, the fixed HIL cabinet hardware channel resources are configured according to the standardized hardware interface and load of the vehicle body domain controller; and for different functional modules, a subsystem closed-loop simulation model is built using the functional specification and a model library is established; in the actual test stage, the HIL test bench is quickly built based on the standardized hardware interface pool and the subsystem simulation model library, and the test activities are carried out; then in the maintenance stage, an association matrix of the model version and the vehicle body domain controller software version is established to support the selection of accurate hardware interfaces and simulation models for regression testing.

[0027] It can be seen that the technical solution of the application realizes the following beneficial effects based on the standardized interface and model decoupling design of the AUTOSAR architecture, combined with the modular simulation model library and the automated test process:

[0028] 1) The test bench development efficiency is significantly improved: by constructing a standardized hardware interface resource pool (such as a fixed configuration CAN / LIN channel group and a unified power drive module), the cross-project reuse of hardware channel resources is realized, and the repeated development workload is reduced; based on the AUTOSAR interface definition and the hardware abstraction layer configuration file, the HIL cabinet hardware channel resource pool is configured simultaneously during the controller development demand stage, so that the test bench development cycle is shortened.

[0029] 2) The flexibility and scalability of the test environment are enhanced: a three-layer decoupling architecture (application layer, interface mapping layer, and hardware execution layer) is adopted to realize the dynamic binding of test software logic and hardware channels; based on the parameterized Simulink subsystem model library, the configuration requirements of different versions of software can be quickly adapted.

[0030] 3) The full life cycle test verification capability is optimized, and the test environment can be quickly switched in different test stages to meet the closed-loop verification requirements of different subsystems of the controller software. DETAILED DESCRIPTION

[0031] In order to make the purpose, technical scheme and advantages of the application clearer, the application will be further described below with reference to the drawings, in which:

[0032] Figure 1A flow chart of a hardware-in-loop simulation method of a body domain controller under an AUTOSAR architecture is provided for an embodiment of the present application.

[0033] Figure 2 A frame diagram of hardware-in-loop simulation of the body domain controller under the AUTOSAR architecture is provided for an embodiment of the present application. DETAILED DESCRIPTION

[0034] Embodiments of the present application are described in detail below with reference to examples shown in the drawings, in which the same or similar numerals represent the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the drawings are exemplary and are only used to explain the present application, and cannot be interpreted as a limitation on the present application.

[0035] An embodiment of a hardware-in-loop simulation method of a body domain controller under an AUTOSAR architecture is provided by the present application, specifically as shown in Figure 1 and Figure 2 which includes:

[0036] Step S1, based on the standardized interface definition of the AUTOSAR basic software layer, a hardware-in-loop (HIL) cabinet hardware channel standardized mapping relationship library is established.

[0037] For reference, the CAN / LIN communication interface is configured with a fixed cabinet channel (such as CAN1-channel group A, LIN1-channel group B); the power drive interface (PWM / HSD) uses a unified hardware board card (such as the power drive module of dSPACE SCALEXIO); the sensor input interface (ADC / DIG) is configured with a standardized signal conditioning unit.

[0038] Step S2, a configuration file of the corresponding relationship between the controller physical interface and the HIL cabinet channel is constructed in combination with the mapping relationship library;

[0039] Specifically, the mapping relationship between the controller pin and the HIL cabinet channel is established through the hardware abstraction layer configuration file, and a hardware interface configuration template that can be cross-project reused is formed;

[0040] Step S3, according to different functional specifications, a subsystem closed-loop simulation model is built for each functional module controlled by the body domain controller;

[0041] For example, load characteristic models such as vehicle lamp (incandescent lamp / LED different impedance models), vehicle window motor (including modeling of stall characteristics), door lock actuator, etc. can be established respectively;

[0042] In addition, sensor simulation models such as a rain sensor (based on PWM duty cycle modeling), a seat pressure sensor (multi-region pressure distribution model), etc. can also be established;

[0043] And, the vehicle network model of CAN bus load simulation, LIN master node simulation, etc.

[0044] The establishment of the subsystem model also includes forming a parameterizable Simulink subsystem model library.

[0045] Step S4, a three-layer decoupling architecture is constructed to realize dynamic binding of test software logic and hardware channels; wherein the three-layer decoupling architecture includes an application layer, an interface mapping layer, and a hardware execution layer.

[0046] To be specific, the test key logic (such as light fade control logic) of the application layer is written by MATLAB and is independent of hardware; the interface mapping layer realizes dynamic binding of model output signals and HIL cabinet channels (such as window position signal→HIL cabinet AI channel 1) through the aforementioned configuration file; and the HIL cabinet as the hardware execution layer automatically allocates physical channel resources according to the mapping relationship.

[0047] Step S5, based on the actual hardware interface and software function definition of the vehicle body domain controller, the HIL cabinet hardware channels and each subsystem model in the model library are configured to build a simulation test bench.

[0048] After the standardized hardware interface resource pool and the closed-loop simulation model library are respectively provided from the hardware and software perspectives by the above steps, the simulation test integrated development link can be entered, that is, a corresponding function module (node) to be controlled is selected, the hardware interface and the subsystem simulation model are selected, and the test environment is built in combination with the hardware-in-the-loop test system architecture.

[0049] It can be supplemented here that other system nodes except the vehicle body domain controller can be simulated by the HIL cabinet, and in some preferable embodiments, the complete hardware-in-the-loop test bench of the application includes a vehicle body domain controller, an HIL cabinet (I / O and communication board card, real-time machine), and a host computer, wherein the vehicle body domain controller is connected to the HIL cabinet through a hardwire, and the HIL cabinet is connected to the host computer through an Ethernet cable.

[0050] Step S6, the vehicle body domain controller is verified by using the simulation test bench.

[0051] Specifically, real-time closed-loop verification is performed in a real hardware-in-the-loop simulation test environment to monitor whether the state machine jump of the VIU meets the preset function specification.

[0052] For example, the HIL cabinet real-time system simulates the door opening and closing signal and the motor locked-rotor scene (such as sudden increase of the window resistance), injects the CAN bus command (such as the window lifting command) and the sensor feedback signal (Hall pulse count) into the VIU through 100 μs level closed-loop control, monitors the VIU internal state machine jump in real time through the bus tool, synchronously collects the PWM output duty cycle change curve, and compares the trigger condition defined in the foregoing functional specification: if the measured state machine jump timing and logic comply with the design specification, it is determined that the design specification is met.

[0053] The foregoing closed-loop verification process covers the complete link of signal input-logic judgment-execution output, and ensures the consistency of the VIU behavior and the design.

[0054] Step S7: After the verification, the automatic test case is generated based on the functional specification, and the function test of each subsystem of the body domain controller is carried out in the current simulation test bench test environment.

[0055] Finally, it can be further supplemented that in some other preferable embodiments of the application, the simulation test bench can also be maintained according to the software version change of the VIU, including: adjusting the hardware channel and the selected subsystem simulation model, and carrying out multiple rounds of regression test after the adjustment.

[0056] In summary, the main idea of the application is that based on the standardized interface definition of the AUTOSAR basic software layer, the hardware channel standardized mapping relationship library is established, and the hardware corresponding relationship configuration file template is constructed; combined with different functional specifications, the subsystem simulation model is built for each functional module and the three-layer decoupling architecture is constructed, the dynamic binding of the test software and the hardware channel is realized; then, based on the actual hardware interface and the software function definition, the simulation test bench is built and the verification is completed; finally, the automatic test case is generated based on the functional specification, and the function test of each subsystem of the body domain controller is carried out in the current test environment. The application significantly shortens the development cycle of the test bench, improves the flexibility and scalability of the test environment, and optimizes the whole life cycle test verification capability.

[0057] If the expression direction is mentioned in the embodiments of the present application, it is based on the relative concept of the embodiments. In addition, "at least one" means one or more, and "multiple" means two or more. The "and / or" describes the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B, which can represent the cases of A alone, A and B together, and B alone. Wherein A and B can be singular or plural. The character " / " generally represents that the associated objects before and after are in an "or" relationship. "At least one of the following" and the like means any combination of these items, including any combination of single or multiple items. For example, at least one of a, b and c can represent: a, b, c, a and b, a and c, b and c, or a and b and c, wherein a, b, c can be single or multiple.

[0058] The above describes the structure, features and effects of the present application according to the embodiments shown in the drawings, but the above is only the preferred embodiment of the present application. It should be noted that the technical features involved in the above embodiments and preferred modes can be reasonably combined and matched into various equivalent schemes by those skilled in the art without departing from or changing the design idea and technical effects of the present application. Therefore, the present application is not limited by the drawings shown in the drawings. Any change or modification made according to the concept of the present application, or any equivalent embodiment within the scope of the present application, shall be within the scope of the present application.

Claims

1. A hardware-in-the-loop simulation method for a body domain controller under an AUTOSAR architecture, characterized in that, The simulation method comprises the following steps: establishing a standardized mapping relationship database of HIL cabinet hardware channels based on the standardized interface definition of the AUTOSAR basic software layer; constructing a configuration file of the corresponding relationship between the physical interface of the controller and the HIL cabinet channel in combination with the mapping relationship database; building a subsystem closed-loop simulation model for each functional module controlled by the body domain controller according to different functional specifications; constructing a three-layer decoupling architecture to realize the dynamic binding of test software logic and hardware channels; the three-layer decoupling architecture comprises an application layer, an interface mapping layer, and a hardware execution layer; configuring the HIL cabinet hardware channels and each subsystem model in the model library based on the actual hardware interface and software function definition of the body domain controller, and building a simulation test bench; verifying the body domain controller by using the simulation test bench; generating an automatic test case based on the functional specification after verification, and carrying out functional test of each subsystem of the body domain controller in the test environment of the current simulation test bench.

2. The hardware-in-the-loop simulation method of the body domain controller under the AUTOSAR architecture according to claim 1, characterized in that, The step of building a subsystem closed-loop simulation model for each functional module controlled by the body domain controller comprises the following steps: at least establishing a load characteristic model, a sensor simulation model, and a vehicle network model, and forming a parameterizable Simulink subsystem model library.

3. The hardware-in-the-loop simulation method of the body domain controller under the AUTOSAR architecture according to claim 1, characterized in that, The step of verifying the body domain controller by using the simulation test bench comprises the following steps: performing real-time closed-loop verification based on a real hardware-in-the-loop simulation test environment, and monitoring whether the state machine transition of the body domain controller meets the preset functional specification.

4. The hardware-in-the-loop simulation method of the body domain controller under the AUTOSAR architecture according to claim 1, characterized in that, The simulation method further comprises the following steps: according to the change of the software version of the body domain controller, maintaining the simulation test bench: adjusting the hardware channel and the selected subsystem simulation model, and carrying out multiple rounds of regression testing after adjustment.

5. The hardware-in-the-loop simulation method of the body domain controller under the AUTOSAR architecture according to claim 1, characterized in that, The step of establishing a standardized mapping relationship database of HIL cabinet hardware channels comprises the following steps: configuring a fixed cabinet channel for the CAN / LIN communication interface; adopting a unified hardware board card for the power drive interface; configuring a standardized signal conditioning unit for the sensor input interface.

6. The hardware-in-the-loop simulation method of a body domain controller under the AUTOSAR architecture according to claim 1, characterized in that, The step of constructing a configuration file of the corresponding relationship between the physical interface of the controller and the HIL cabinet channel in combination with the mapping relationship database comprises the following steps: establishing the mapping relationship between the controller pin and the HIL cabinet channel through a hardware abstraction layer configuration file, to form a reusable hardware interface configuration template.

7. The hardware-in-the-loop simulation method of a body domain controller under the AUTOSAR architecture according to any one of claims 1-6, characterized in that, The complete simulation test bench comprises a body domain controller, a HIL cabinet comprising at least an I / O and communication board card and a real-time machine, and an upper computer; the body domain controller is connected to the HIL cabinet through a hardwire, and the HIL cabinet is connected to the upper computer through an Ethernet cable.

Images