Multi-ecu simulation test method and device, computer equipment and storage medium
By building a multi-ECU simulation environment and utilizing the DoIP protocol stack and analog network technology, the challenge of cross-platform simulation testing of automotive ECUs was solved, enabling efficient simulation testing and rapid iterative development.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2021-12-27
- Publication Date
- 2026-03-17
AI Technical Summary
Existing vehicle ECU simulation testing methods cannot independently complete cross-platform simulation testing, resulting in low development and testing efficiency, and requiring multiple parties to collaborate on the use of limited software and hardware equipment.
By building a multi-ECU simulation environment, the DoIP protocol stack is used to simulate vehicle ECUs with different IP addresses on a single Linux platform, realizing communication between the ECUs. The communication process of the target ECU is simulated by simulating CAN bus and Internet network, and the running results of the application are output.
It enables independent cross-platform simulation testing in a single simulation environment, improving testing efficiency, reducing costs, and accelerating the development iteration process.
Smart Images

Figure CN115437337B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of vehicle ECU technology, and in particular to a simulation testing method, apparatus, computer equipment, and storage medium for multiple ECUs. Background Technology
[0002] A typical integrated electronic and electrical architecture network topology includes communication methods such as CAN (Controller Area Network), CANFD (CAN with Flexible Data-Rate), LIN (Local Interconnect Network), and Ethernet. When developing a functional application for an automotive ECU (Electronic Control Unit), it is necessary to test the application's performance. Current testing methods involve purchasing and using CANoe (CAN open environment) and CANCaseXL (vector hardware interface card). Furthermore, current testing methods often require multiple simulation testing products, necessitating collaboration among multiple developers. This results in limited software and hardware testing equipment and a large number of physical devices involved in testing a single application, making independent cross-platform simulation, development, and testing impossible. Summary of the Invention
[0003] This invention provides a multi-ECU simulation testing method, apparatus, computer equipment, and storage medium to solve the technical problem that the same application developed for ECU electronic control units cannot independently complete cross-platform simulation testing.
[0004] A simulation testing method for multiple ECUs, applied to computer equipment, the method comprising:
[0005] Obtain pre-developed applications for the target electronic control unit;
[0006] The application is input into a pre-built multi-electronic control unit simulation environment;
[0007] The target simulated electronic control unit is obtained by querying the simulated vehicle electronic control unit in the multi-electronic control unit simulation environment that has the same unique identifier as the target electronic control unit.
[0008] The communication process of the target simulated electronic control unit is simulated through the simulated controller local area network or simulated Internet network in the multi-electronic control unit simulation environment, and the application is run based on the target simulated electronic control unit, and the running results of the application are output.
[0009] A simulation test device for multiple ECUs, comprising:
[0010] The program acquisition module is used to acquire pre-developed applications applied to the target electronic control unit.
[0011] The input module is used to input the application into a pre-built multi-electronic control unit simulation environment;
[0012] The query module is used to query the simulated vehicle electronic control unit that has the same unique identifier as the target electronic control unit from the multi-electronic control unit simulation environment, and obtain the target simulated electronic control unit.
[0013] The running module is used to simulate the communication process of the target simulated electronic control unit through the simulated controller local area network or simulated Internet network in the multi-electronic control unit simulation environment, and to run the application based on the target simulated electronic control unit and output the running results of the application.
[0014] A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described multi-ECU simulation test method.
[0015] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described multi-ECU simulation test method.
[0016] The multi-ECU simulation testing method, apparatus, computer equipment, and storage medium proposed in this application input the application to be tested into a pre-built multi-ECU simulation environment. The simulation environment queries for the simulated vehicle ECU with the same unique identifier as the target ECU to obtain the target simulated ECU. The application is then run through the target simulated ECU, and the application's running results are output. Since this multi-ECU simulation environment can simulate CAN controller area networks and the Internet, and can obtain the target simulated electronic control unit from each simulated vehicle electronic control unit, the application under test, whether applied to a single target ECU or involving data interaction between multiple target ECUs, can be tested through this multi-ECU simulation environment. This allows the application under test to independently complete cross-platform simulation testing within a single simulation environment, improving the efficiency of simulation testing while reducing its cost. Attached Figure Description
[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0018] Figure 1 This is a schematic diagram of an application environment for a multi-ECU simulation testing method according to an embodiment of the present invention;
[0019] Figure 2 This is a flowchart of a simulation test method for multiple ECUs in one embodiment of the present invention;
[0020] Figure 3 This is a schematic diagram of the network topology of a multi-ECU simulation environment in one embodiment of the present invention;
[0021] Figure 4 This is an example diagram of simulated ECUs connected to a single theme in a multi-ECU simulation environment according to an embodiment of the present invention;
[0022] Figure 5 This is a schematic diagram of the structure of a simulation test device for multiple ECUs in one embodiment of the present invention;
[0023] Figure 6 This is a schematic diagram of a computer device according to an embodiment of the present invention. Detailed Implementation
[0024] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0025] The multi-ECU simulation testing method provided in this application can be applied to applications such as... Figure 1 In this application environment, the computer device is able to communicate with other devices via a network. This computer device can be, but is not limited to, various personal computers, laptops, smartphones, tablets, etc.
[0026] In one embodiment, such as Figure 2 As shown, a simulation testing method for multiple ECUs (Electronic Control Units) is provided, which is then applied to... Figure 1 The following steps, S101 to S104, are used as an example of computer equipment.
[0027] S101. Obtain a pre-developed application program for the target electronic control unit.
[0028] In one embodiment, the target ECU refers to a physical ECU mounted on a vehicle. The application program for the target ECU can be a functional application applied to the physical ECU, or it can be a diagnostic program used to diagnose the target ECU.
[0029] S102. Input the application into the pre-built multi-ECU simulation environment. The multi-ECU simulation environment includes at least one DoIP (Diagnostic On IP, a communication rule that applies IP technology to the field of vehicle network diagnostics) simulation node and several simulated vehicle ECUs. Each simulated vehicle ECU communicates through a simulated CAN bus or a simulated DoIP network based on the DoIP simulation node.
[0030] Understandably, a DoIP emulator node is used to simulate a virtual network with one IP address. Since the DoIP protocol stack is based on TCP (Transmission Control Protocol) / IP (Internet Protocol) and UDP (User Datagram Protocol) protocols and has cross-platform compatibility, applying the DoIP protocol stack technology in this multi-ECU simulation environment allows different IP addresses to be simulated via Docker virtual networks on a single Linux platform. This enables each simulated vehicle ECU to start in different Docker containers, allowing different simulated vehicle ECUs in the same multi-ECU simulation environment to have different IP addresses. The communication method for DoIP node messages generated between simulated vehicle ECUs with different IP addresses is as follows: the destination address is converted to an IP address or Docker name in the virtual network for communication. Finally, it can be managed through Docker Compose. The conversion instructions are as follows:
[0031] docker network create-d bridge ecu-bridge;
[0032] docker run-d--name Node1--network ecu-bridge mydocker:latest / bin / bash-cv;
[0033] docker run -d --name Node2 --network ecu-bridge mydocker:latest / bin / bash-cv.
[0034] In one embodiment, the multi-ECU simulation environment is pre-built, including the following steps (1) to (4).
[0035] (1) Configure the data link layer and physical layer of the simulated Internet network according to the first instruction received.
[0036] Specifically, according to the requirements of ISO-13400, DoIP communication needs to be configured at the physical layer to support both 100BASE-TX (100Mbit / s Ethernet) and 10BASE-T (10Mbit / s Ethernet).
[0037] (2) Configure the transport layer and network layer of the simulated Internet network according to the received second instruction and Internet protocol stack.
[0038] Specifically, this Internet protocol stack, namely the DoIP protocol stack, requires that the MAC (Media Access Control Address, LAN address) of the DoIP device conform to the Ethernet IEEE 802.3 requirements. Communication at the transport layer must support both UDP and TCP, and communication at the network layer must use the IPv6 protocol, but for backward compatibility, IPv4 is also supported. Furthermore, it needs to be configured to support the Address Resolution Protocol (ARP), and for IPv6, it also needs to support the Neighbor Discovery Protocol (NDP). These two protocols are used to obtain the MAC address when only the IP address is known.
[0039] (3) Based on the received third instruction and data distribution service DDS (Direct Digital Synthesis), simulate the CAN bus communication of the controller area network.
[0040] Several key features of CAN communication include: carrier monitoring, multi-master control / collision avoidance; messages are broadcast without relying on a specific destination address; error detection, self-recovery, and high reliability.
[0041] Based on the above features, the sending and receiving of messages on a CAN bus can be replaced by the SUB (Subscriber) / PUB (Publisher) operation of a TOPIC topic. Each node sends the messages sent to the CAN bus out through the PUB, and at the same time filters the data received by the SUB. Communication priority arbitration strategy, communication reliability strategy, etc. can be easily implemented by configuring QoS.
[0042] Figure 4 This is an example diagram of a simulated ECU connected to a single theme in a multi-ECU simulation environment according to an embodiment of the present invention, achieving the following: Figure 4 As shown, nodes belonging to the same topic are represented by a line connecting them. Figure 4 Each node in the model represents a corresponding simulated vehicle ECU, and each simulated vehicle ECU corresponds one-to-one with the simulated physical vehicle ECU.
[0043] (4) Configure the virtual network corresponding to the Internet Protocol simulation address of each simulated vehicle electronic control unit according to the received fourth instruction.
[0044] Understandably, after setting up the multi-ECU simulation environment, it's necessary to import the corresponding configuration files based on the actual testing scenarios. For example, if diagnostics of the vehicle ECU are required, a CDD (CANdelaStudio, Diagnostic Specification) / ODX (Open Diagnostic Data Exchange) configuration file needs to be imported. If testing the CAN broadcast function of a specific application is required, such as intelligently detecting whether windows / doors are closed, a DBC (Database CAN, CAN database file) configuration file needs to be imported. Additionally, Lua configuration files can be imported to configure the basic parameters of the ECU and the node status of the overall network, assisting in the setup of the simulation environment. Preferably, the Lua configuration file, CDD / ODX configuration file, and DBC configuration file can all be imported into the multi-ECU simulation environment.
[0045] By building a multi-ECU simulation environment, the business functions of the currently developed ECU can be self-tested. By writing test cases in the simulation environment, the development iteration process can be accelerated.
[0046] S103. Query the simulated vehicle electronic control unit that has the same unique identifier as the target electronic control unit from the multi-electronic control unit simulation environment to obtain the target simulated electronic control unit.
[0047] Figure 3 This is a schematic diagram of the network topology of a multi-ECU simulation environment in one embodiment of the present invention, as shown below. Figure 3 As shown, Figure 3 Each node in the diagram represents a corresponding simulated vehicle ECU, and each simulated vehicle ECU corresponds one-to-one with the simulated physical vehicle ECU. The DoIP node represents a simulated DoIP network within the virtual network, and each DoIP node or DoIP edge node has its own IP address. Each simulated vehicle ECU connects via a simulated CAN bus or a simulated DoIP network based on DoIP simulated nodes (i.e.,...). Figure 3 They communicate via ETH.
[0048] The application under test can be divided into two main categories based on its function: development related to communication on the physical bus and development of business logic. This embodiment focuses on the development of communication logic simulating the physical bus, so that the simulation environment of the application layer is not limited to hardware devices such as CANCaseXL. Engineers developing applications can focus more on rapid iteration of business logic, just like regular APP (Application) development, thus accelerating development efficiency.
[0049] When testing an application under test in a multi-ECU simulation environment, it is necessary to first know which physical ECU the application under test is applied to. This allows the corresponding target simulation ECU to be found in the simulation environment based on the unique identifier of the target ECU. By testing the application based on the target simulation ECU, the effect of the application running on the physical ECU can be predicted.
[0050] S104. Simulate the communication process of the target simulated electronic control unit through the simulated controller local area network or simulated Internet network in the multi-electronic control unit simulation environment, run the application based on the target simulated electronic control unit, and output the running results of the application.
[0051] In one embodiment, when the number of target electronic control units (ECUs) applied by the application is multiple, and the Internet addresses of the multiple target ECUs include one type, the application running based on the target simulated ECUs includes:
[0052] Acquire the first message sent to the local area network of the analog controller;
[0053] Obtain the simulated electronic control unit of the first message recipient from the first message;
[0054] Replace the first message with the source transmission code of the topic containing the simulated electronic control unit of the target recipient. This original transmission code can be a PUB transmission code.
[0055] In one embodiment, when the number of target electronic control units (ECUs) used by the application is multiple, and the Internet Protocol (IP) addresses of the multiple target ECUs include two or more types, running the application based on the target ECU simulation includes:
[0056] Obtain the destination address of the second target simulated electronic control unit from the simulated Internet network message sent by the first target simulated electronic control unit;
[0057] This destination address is translated into a target Internet Protocol (IP) emulation address in a simulated Internet network, i.e., a target IP emulation address.
[0058] The simulated Internet network message is sent to the second target simulated electronic control unit corresponding to the target Internet Protocol simulated address.
[0059] Among these, the simulation of the Internet network can be achieved by building a DoIP simulation node in the multi-electronic control unit simulation environment.
[0060] This embodiment proposes an implementation method for running the application through the target ECU when the number of target ECUs used by the application is multiple, and the IP addresses of the multiple target ECUs include one or more types. This allows the application to process the data transmission and reception related to the application through the multi-ECU simulation environment, regardless of the actual environment in which it is used, and enables the testing of the application based on the same computer equipment and the same simulation environment.
[0061] In one embodiment, the application includes diagnostic files, and the simulated electronic control unit based on the target runs the application, outputting the application's results, including:
[0062] Import the diagnostic file into the target simulated electronic control unit;
[0063] Obtain the execution result of the target simulated electronic control unit on the diagnostic file;
[0064] If the execution result contains diagnostic fault codes or corresponding error text, then the target simulated electronic control unit is determined to be operating abnormally.
[0065] The diagnostic document includes a CDD diagnostic description document and / or an ODX open diagnostic data exchange document.
[0066] This embodiment implements the diagnostic interface of the ECU by parsing diagnostic files in file formats such as CDD and ODX. The diagnostic file contains the communication protocol and required communication parameters for diagnosis, diagnostic services on the ECU and their format / sub-functions, DID (Data Identifier) and its interpretation code value, DTC (Diagnostic Trouble Code) and corresponding error text.
[0067] In one embodiment, the step of running the application based on the target simulated electronic control unit and outputting the running results of the application includes:
[0068] Import the application into the target simulated electronic control unit;
[0069] Obtain the execution result of the application by the target simulated electronic control unit;
[0070] The functional status parameters of the target simulated electronic control unit carried in the execution result are output.
[0071] In this embodiment, the application used is an application that controls the raising and lowering of car windows. In this case, the functional status parameters of the target simulated electronic control unit carried in the output execution result are, for example, 00, 01, and 11, where 00 indicates that the window is raised, 01 indicates that the window is lowered, and 11 indicates that the window is stopped.
[0072] In other embodiments, the application suitable for this embodiment may also be an application for controlling changes in the volume of in-vehicle speakers, a vehicle braking control program, etc.
[0073] In one embodiment, the electronic control unit based on the target simulation runs the application, including:
[0074] The target simulated electronic control unit is analyzed based on the first file in DBC format generated by the application.
[0075] Based on the information cycle recorded in the first file, the message message generated according to the first file is broadcast in the local area network of the analog controller.
[0076] It is understandable that parsing the first file in the DBC format enables the sending of message messages on the CAN bus according to the information in the DBC. Alternatively, the value of the custom signal can be configured via Lua for testing.
[0077] In other embodiments, when the application, such as an application for controlling the volume of in-vehicle speakers, a vehicle braking control program, or a program for controlling the raising and lowering of vehicle windows, requires simulated Internet communication between different target simulated electronic control units, it is necessary to simulate the Internet network by pre-constructing DoIP simulated nodes in the multi-electronic control unit simulation environment.
[0078] In one embodiment, after step S104 described above, the multi-ECU simulation test method further includes:
[0079] If the result meets expectations, the application is deemed correct; otherwise, a message indicating that the application needs to be repaired is issued.
[0080] Understandably, each application under test has specific expectations, such as popping up a window, controlling the raising or lowering of a car window, or controlling the on / off state of the high beams. When the performance of an application under test does not meet expectations, it indicates that the application may have a program error and needs to be fixed.
[0081] In one embodiment, the notification message is sent in a manner such as popping up a notification box, sending an error code, or emitting a beeping sound.
[0082] The multi-ECU simulation testing method proposed in this embodiment first inputs the application to be tested into a pre-built multi-ECU simulation environment. It then queries the simulation environment for a simulated vehicle ECU with the same unique identifier as the target ECU to obtain the target simulated ECU. The application is then run on this target simulated ECU, and the running results are output. Finally, the correctness of the application is determined based on the running results. Since the multi-ECU simulation environment includes at least one DoIP simulation node and several simulated vehicle ECUs, each of which communicates via a simulated CAN bus or a simulated DoIP network based on the DoIP simulation node, the application under test can be tested in this multi-ECU simulation environment, regardless of whether it is applied to a single target ECU or involves data interaction between multiple target ECUs. This allows the application under test to independently complete cross-platform simulation testing within a single simulation environment, improving the efficiency of simulation testing while reducing its cost.
[0083] Traditional distributed electrical and electronic architectures struggle to support the complex functions of automobiles, leading to a gradual evolution towards centralized architectures. This involves developing a proprietary underlying operating system and using a central processing unit (CPU) to manage different domain processors and ECUs in a unified manner. This simplifies the internal structure. Simultaneously, in-vehicle Ethernet is beginning to replace CAN and LIN bus structures in some domains, reducing the complexity of in-vehicle wiring harnesses and significantly improving versatility and portability. The multi-ECU simulation testing method proposed in this embodiment can operate independently of CANoe, CANCaseXL, and other hardware and software, enabling the rapid establishment of cross-platform simulation, development, and testing environments. This improves development iteration efficiency and allows for the rapid verification of all ECU functions during iterative development. Furthermore, it allows for the creation of full-process test cases in a cross-platform x86 environment, enhancing code quality.
[0084] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.
[0085] In one embodiment, a multi-ECU simulation testing apparatus is provided, which corresponds one-to-one with the multi-ECU simulation testing method described in the above embodiments. For example... Figure 5 As shown, the multi-ECU simulation test device 100 includes a program acquisition module 11, an input module 12, a query module 13, and a running module 14. Detailed descriptions of each functional module are as follows:
[0086] Program acquisition module 11 is used to acquire a pre-developed application program applied to the target electronic control unit;
[0087] Input module 12 is used to input the application into a pre-built multi-electronic control unit simulation environment;
[0088] The query module 13 is used to query the simulated vehicle electronic control unit that has the same unique identifier as the target electronic control unit from the multi-electronic control unit simulation environment, and obtain the target simulated electronic control unit;
[0089] The running module 14 is used to simulate the communication process of the target simulated electronic control unit through the simulated controller local area network or simulated Internet network in the multi-electronic control unit simulation environment, and run the application based on the target simulated electronic control unit, and output the running results of the application.
[0090] The multi-ECU simulation testing device proposed in this embodiment inputs the application to be tested into a pre-built multi-ECU simulation environment through the input module 12. Then, the query module 13 queries the multi-ECU simulation environment for the simulated vehicle ECU with the same unique identifier as the target ECU to obtain the target simulated ECU. The running module 14 runs the application through the target simulated ECU and outputs the running results of the application. Since the multi-ECU simulation environment includes at least one DoIP simulation node and several simulated vehicle ECUs, and each simulated vehicle ECU communicates through a simulated CAN bus or a simulated DoIP network based on the DoIP simulation node, the application to be tested can be tested through the multi-ECU simulation environment, whether it is applied to a single target ECU or involves data interaction between multiple target ECUs. This allows the application to be tested to independently complete cross-platform simulation testing in a single simulation environment, improving the efficiency of simulation testing and reducing the cost of simulation testing.
[0091] In one embodiment, the multi-ECU simulation test apparatus 100 further includes:
[0092] The first configuration module is used to configure the data link layer and physical layer of the simulated Internet network according to the received first instruction;
[0093] The second configuration module is used to configure the transport layer and network layer of the simulated Internet network according to the received second instruction and Internet protocol stack.
[0094] The communication simulation module is used to simulate controller local area network bus communication based on the received third-party instructions and data distribution service.
[0095] The third configuration module is used to configure the virtual network corresponding to the Internet Protocol simulation address of each simulated vehicle electronic control unit according to the received fourth instruction.
[0096] Understandably, after setting up the multi-ECU simulation environment, it's necessary to import the corresponding configuration files based on the actual testing scenarios. For example, when diagnosing an onboard ECU, a CDD (CANdelaStudio, Diagnostic Specification) / ODX (Open Diagnostic Data Exchange) configuration file needs to be imported; when testing the CAN broadcast function of a specific application, such as intelligently detecting whether windows / doors are closed, a DBC configuration file needs to be imported. Additionally, a Lua configuration file can be imported to configure the basic parameters of the ECU and the node status of the overall network, assisting in setting up the simulation environment. Preferably, the Lua configuration file, CDD / ODX configuration file, and DBC configuration file can all be imported into the multi-ECU simulation environment.
[0097] By building a multi-ECU simulation environment, the business functions of the currently developed ECU can be self-tested. By writing test cases in the simulation environment, the development iteration process can be accelerated.
[0098] In one embodiment, when the application targets multiple target ECUs, and the IP addresses of these multiple target ECUs include one type, the running module 14 specifically includes:
[0099] The first message sending unit is used to acquire the first message to be sent to the local area network of the analog controller;
[0100] An object acquisition unit is used to acquire, from the first message, a simulated electronic control unit that receives the first message;
[0101] The replacement unit is used to replace the first message with the source transmission code of the topic where the simulated electronic control unit of the sending object is located.
[0102] In one embodiment, when the number of target electronic control units (ECUs) applied by the application is multiple, and the Internet Protocol addresses of the multiple target ECUs include two or more types, the operation module 14 specifically includes:
[0103] The address acquisition unit is used to acquire the destination address of the second target simulated electronic control unit in the simulated Internet network message sent by the first target simulated electronic control unit;
[0104] The address replacement unit is used to convert the destination address into a target Internet Protocol (IP) analog address in a simulated Internet network.
[0105] The node message sending unit is used to send the simulated Internet network message to the second target simulation electronic control unit corresponding to the target Internet Protocol simulated address.
[0106] This embodiment proposes an implementation method for running the application through the target ECU when the number of target ECUs used by the application is multiple, and the IP addresses of the multiple target ECUs include one or more types. This allows the application to process the data transmission and reception related to the application through the multi-ECU simulation environment, regardless of the actual environment in which it is used, and enables the testing of the application based on the same computer equipment and the same simulation environment.
[0107] In one embodiment, the application includes diagnostic files, and the runtime module 14 specifically includes:
[0108] The first import unit is used to import the diagnostic file into the target simulated electronic control unit;
[0109] The diagnostic result acquisition unit is used to acquire the execution result of the target simulated electronic control unit on the diagnostic file.
[0110] The identification unit is used to identify whether the execution result contains diagnostic fault codes or corresponding error text. If so, it is determined that the target simulated electronic control unit is operating abnormally.
[0111] In one embodiment, the diagnostic file includes a CDD diagnostic description file and / or an ODX open diagnostic data exchange file.
[0112] Furthermore, the operating module 14 also includes:
[0113] The second import unit is used to import the application into the target simulation electronic control unit;
[0114] An execution result acquisition unit is used to acquire the execution result of the target simulated electronic control unit on the application program;
[0115] The parameter output unit is used to output the functional status parameters of the target simulated electronic control unit carried in the execution result.
[0116] This embodiment implements the diagnostic interface of the ECU by parsing diagnostic files in file formats such as CDD and ODX. The diagnostic file contains the communication protocol and required communication parameters for diagnosis, diagnostic services on the ECU and their format / sub-functions, DID (Data Identifier) and its interpretation code value, DTC (Diagnostic Trouble Code) and corresponding error text.
[0117] In one embodiment, the operation module 14 further includes:
[0118] The parsing unit is used to parse the first file in DBC format generated by the target simulated electronic control unit according to the application.
[0119] The broadcast unit is used to broadcast message messages generated according to the first file in the local area network of the analog controller according to the information period recorded in the first file.
[0120] The terms "first" and "second" in the above-mentioned modules / units are only used to distinguish different modules / units and are not intended to specify which module / unit has a higher priority or any other limiting meaning. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or modules is not necessarily limited to those steps or modules explicitly listed, but may include other steps or modules not explicitly listed or inherent to these processes, methods, products, or devices. The module divisions appearing in this application are merely logical divisions; in actual applications, different division methods may be used.
[0121] Specific limitations regarding the simulation test apparatus for multi-ECUs can be found in the limitations of the simulation test method for multi-ECUs mentioned above, and will not be repeated here. Each module in the aforementioned simulation test apparatus for multi-ECUs can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of the processor, or stored in the memory of a computer device in software form, so that the processor can call and execute the corresponding operations of each module.
[0122] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 6 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes storage media and internal memory. The storage media includes non-volatile and / or volatile storage media, storing the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the storage media. The network interface is used for communication with external devices via a network connection. When the computer program is executed by the processor, it implements a multi-ECU simulation testing method.
[0123] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the multi-ECU simulation testing method described in the above embodiment, for example... Figure 2The steps 101 to 104 shown, as well as other extensions and related steps of the method, are examples. Alternatively, when the processor executes the computer program, it implements the functions of each module / unit of the multi-ECU simulation test device in the above embodiments, for example... Figure 5 The functions of modules 11 to 14 are shown. To avoid repetition, they will not be described again here.
[0124] The processor can be an electronic control unit (ECU), a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor. The processor is the control center of the computer device, connecting various parts of the computer device via various interfaces and lines.
[0125] The memory can be used to store the computer programs and / or modules. The processor implements various functions of the computer device by running or executing the computer programs and / or modules stored in the memory and by calling data stored in the memory. The memory may mainly include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created based on the use of the mobile phone (such as audio data, video data, etc.).
[0126] The memory can be integrated into the processor or it can be set up separately from the processor.
[0127] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When executed by a processor, the computer program implements the steps of the multi-ECU simulation testing method described in the above embodiments, for example... Figure 2 The steps 101 to 104 shown, as well as other extensions and related steps of the method, are examples. Alternatively, when the computer program is executed by the processor, it implements the functions of each module / unit of the multi-ECU simulation test device in the above embodiments, for example... Figure 5 The functions of modules 11 to 14 are shown. To avoid repetition, they will not be described again here.
[0128] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile and / or volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).
[0129] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.
[0130] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.
Claims
1. A method of simulation test of multiple ECUs, characterized by, The application comprises the following steps: acquiring a pre-developed application program applied to a target electronic control unit; inputting the application program into a pre-built multi-electronic control unit simulation environment; querying a simulation vehicle-mounted electronic control unit with the same unique identification as the target electronic control unit from the multi-electronic control unit simulation environment to obtain a target simulation electronic control unit; simulating the communication process of the target simulation electronic control unit through a simulated controller area network or a simulated Internet network in the multi-electronic control unit simulation environment, and running the application program based on the target simulation electronic control unit to output the running result of the application program; when the number of target electronic control units to which the application program is applied is multiple, and the Internet protocol addresses of the multiple target electronic control units include one type, the running of the application program based on the target simulation electronic control unit comprises the following steps: acquiring a first message sent to the simulated controller area network; acquiring the simulation electronic control unit of the first message sending object from the first message; replacing the first message with the source sending code of the subject of the simulation electronic control unit of the sending object.
2. The method of claim 1, wherein, The pre-built multi-electronic control unit simulation environment comprises the following steps: configuring the data link layer and the physical layer of the simulated Internet network according to the received first instruction; configuring the transmission layer and the network layer of the simulated Internet network according to the received second instruction and the Internet protocol stack; simulating the controller area network bus communication according to the received third instruction and the data distribution service; configuring the virtual network corresponding to the Internet protocol simulation address of each simulation vehicle-mounted electronic control unit according to the received fourth instruction.
3. The method of claim 1, wherein, When the number of target electronic control units to which the application program is applied is multiple, and the Internet protocol addresses of the multiple target electronic control units include two or more types, the running of the application program based on the target simulation electronic control unit comprises the following steps: acquiring the destination address of the second target simulation electronic control unit in the simulated Internet network message sent by the first target simulation electronic control unit; converting the destination address into a target Internet protocol simulation address in the simulated Internet network; sending the simulated Internet network message to the second target simulation electronic control unit corresponding to the target Internet protocol simulation address.
4. The method of claim 1, wherein, The application program comprises a diagnostic file, and the running of the application program based on the target simulation electronic control unit to output the running result of the application program comprises the following steps: importing the diagnostic file into the target simulation electronic control unit; acquiring the execution result of the diagnostic file by the target simulation electronic control unit; identifying whether the execution result contains a diagnostic fault code or a corresponding error text, and if so, judging that the target simulation electronic control unit is abnormally running.
5. The method of claim 1, wherein, The running of the application program based on the target simulation electronic control unit to output the running result of the application program comprises the following steps: importing the application program into the target simulation electronic control unit; Obtaining an execution result of the application program by the target simulation electronic control unit; Outputting a functional state parameter of the target simulation electronic control unit carried in the execution result.
6. The method of claim 1, wherein, The running of the application program by the target simulation electronic control unit comprises: Parsing a first file in DBC format generated by the target simulation electronic control unit according to the application program; Broadcasting a message packet generated according to the first file in the simulated controller area network according to an information period recorded in the first file.
7. A multi-ECU simulation test device characterized by comprising: Comprise: A program acquisition module for acquiring an application program developed in advance and applied to a target electronic control unit; An input module for inputting the application program into a multi-electronic control unit simulation environment built in advance; A query module for querying a simulation vehicle-mounted electronic control unit with the same unique identifier as the target electronic control unit from the multi-electronic control unit simulation environment to obtain a target simulation electronic control unit; A running module for simulating a communication process of the target simulation electronic control unit through a simulated controller area network or a simulated Internet network in the multi-electronic control unit simulation environment, and running the application program based on the target simulation electronic control unit and outputting a running result of the application program; When the number of target electronic control units to which the application program is applied is multiple, and the Internet protocol addresses of the multiple target electronic control units include one kind, the running module specifically comprises: A first message sending unit for obtaining a first message sent to the simulated controller area network; An object acquisition unit for obtaining a simulation electronic control unit of the first message sending object from the first message; A replacement unit for replacing the first message with source sending code of a topic in which the simulation electronic control unit of the sending object is located.
8. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor executes the computer program to realize the steps of the multi-ECU simulation test method in any one of claims 1 to 6.
9. A computer-readable storage medium storing a computer program, the computer program comprising instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 8. The computer program is executed by the processor to realize the steps of the multi-ECU simulation test method in any one of claims 1 to 6.
Citation Information
Patent Citations
Automatic diagnosis test method based on VT system
CN107943008A
Testing method and device, equipment and storage medium
CN113791605A