Communication method and system for cooperative calling of multiple upper computers in HIL automatic test

Abstract

The invention provides a communication method and system for cooperative calling of multiple upper computers in an HIL automatic test, and the method comprises the steps: an automatic test module calls one or more upper computers in an upper computer unit in a unified manner through a console, and drives an HIL rack module and a tested electric control system module to complete a test action; the HIL rack module receives an instruction and signal simulation transmitted by the automatic test module, and transmits a simulation signal to the tested electric control system module; and the tested electric control system module receives an analog signal of the HIL rack module and an instruction transmitted by the automatic test module to complete the test.

Description

Technical Field

[0001] This invention relates to the field of hardware-in-the-loop automated testing technology, and in particular to a communication method and system for collaborative invocation of multiple host computers in HIL automated testing. Background Technology

[0002] Hardware-in-the-Loop (HIL) automated testing is a type of testing that combines real hardware with simulation models to simulate actual operating conditions and external signals. In current MCU controller HIL automated testing scenarios, a complete test case often requires the coordination of multiple specialized host computers. Typically, these three host computers include: an HIL host computer responsible for running the motor model and providing electrical signals to the device under test (DUT); a vehicle CAN host computer responsible for simulating the vehicle's network environment (such as sending / receiving CAN messages); and a debug CAN host computer used for software flashing, debugging, and monitoring. Due to the different specializations of these host computers, they are usually deployed on different physical PC terminals to optimize computing resource allocation and system stability.

[0003] However, this distributed deployment architecture presents significant challenges to automated testing. In traditional MCU Hardware-in-the-Loop (HIL) automated testing, a complete test case typically requires the collaborative work of three different host computers: the HIL host computer, the vehicle CAN host computer, and the debug CAN host computer. Due to computational load and the need for specialized division of labor, these host computers are often deployed on different physical PC terminals. Therefore, existing technologies suffer from the following prominent problems and bottlenecks: 1. Fragmented operation, unable to be automated: Test engineers need to manually launch the software, perform operations, and record results on three separate computers. This process is cumbersome, inefficient, and heavily reliant on manual labor, making true "one-click" automated testing impossible.

[0004] 2. Difficulties in coordination and synchronization: Due to the lack of a unified scheduling mechanism, it is difficult to ensure precise synchronization and consistency among multiple host computers in terms of command triggering, test timing, and data interaction. A test step may require simultaneously commanding the HIL host computer to output signals and the vehicle CAN host computer to send messages at a specific moment; manual operation is almost impossible to reliably fulfill this requirement.

[0005] 3. Rigid system with poor scalability: The host computers are tightly coupled or use direct local calls. Once a host computer needs to change its PC host or add a new test node, the communication architecture of the entire system needs to be modified and reconfigured extensively, lacking flexibility.

[0006] To address the aforementioned issues, an innovative method is urgently needed to achieve unified scheduling and collaborative control of heterogeneous host computers distributed across multiple PC terminals. This invention aims to propose a multi-host computer communication and invocation method for HIL automated testing, achieving centralized instruction distribution and synchronous execution of the HIL host computer, the vehicle CAN host computer, and the debugging CAN host computer. Ultimately, this will overcome the challenges of collaborative control in distributed testing environments, truly realizing efficient and reliable integrated automated testing. Summary of the Invention

[0007] In order to overcome the above-mentioned technical defects, the purpose of this invention is to provide a communication method and system for collaborative invocation of multiple host computers in HIL automated testing, which integrates multiple host computers distributed in different locations into a virtual, unified "test execution cluster", realizing centralized, remote and automated scheduling of multiple host computers.

[0008] This invention discloses a communication method for multi-host computer collaborative invocation in HIL automated testing, comprising the following steps: The automated testing module uses the console to uniformly control one or more host computers in the host computer unit and drive the HIL bench module and the electrical control system module under test to complete the test actions. The HIL bench module receives instructions and simulates signals from the automated test module and transmits simulated signals to the electrical control system module under test. The tested electrical control system module receives analog signals from the HIL bench module and instructions transmitted by the automated test module to complete the test.

[0009] Preferably, the automated testing module includes multiple PC terminals, each PC terminal having a host computer unit and / or a main control console, the host computer unit including one or more host computers, and the automated testing module including a PC terminal with a main control console and one or more PC terminals with host computer units.

[0010] Preferably, the automated testing module uses a console to uniformly control one or more host computers in the host computer unit, and drives the HIL test bench module and the electrical control system module under test to complete the test actions, including the following steps: The APIs provided by the host computer on the PC terminal are encapsulated to obtain the host computer API ports. Using the Socket network programming library, a globally unique port number is assigned and bound to each encapsulated service. This host computer includes, but is not limited to, the debugging CAN host computer, the HIL host computer, and the vehicle CAN host computer. The main control console parses the test sequence, encapsulates the test instructions in the test sequence, and transmits them to the host computer's API port. The host computer API port receives and parses the encapsulated test commands, executes the parsed test commands, and drives, but is not limited to, the HIL bench module and the electrical control system module under test to complete the test action.

[0011] Preferably, the main control console parses the test sequence, encapsulates the test instructions in the test sequence, and transmits them to the host computer's API port, including the following steps: The main console reads and parses the test sequence from the test cases to obtain the test instructions. Based on the function type of the test instructions, the test instructions are encapsulated into data packets using the TCP protocol and transmitted to the host computer's API port.

[0012] Preferably, the host computer API port receives, parses, and executes the encapsulated test command, including the following steps: The host computer's API port maps the received encapsulated test instructions into specific executable functions or operations, which are then executed by the host computer.

[0013] Preferably, the method specifically includes: The APIs provided by the HIL host computer of the second PC terminal, the CAN host computer of the whole vehicle, and the debugging CAN host computer of the first PC terminal are encapsulated as services to obtain the first host computer API port, the second host computer API port and the third host computer API port respectively. Using the Socket network programming library, the encapsulated service is assigned and bound to a port number, which is a globally unique port number. The main control console located on the first PC terminal parses the test sequence, encapsulates the test instructions in the test sequence, and transmits them to the corresponding host computer API port. The host computer API port that receives the instruction parses the encapsulated test instruction, executes the parsed test instruction, and drives, but is not limited to, the HIL bench module and the electrical control system module under test to complete the test action. The main control console transmits commands to the debugging CAN host computer via TCP protocol, and the first PC terminal and the second PC terminal are interconnected via network cable via TCP / IP protocol.

[0014] This invention also discloses a communication system for HIL automated testing involving collaborative calls between multiple host computers, comprising: The automated testing module, including but not limited to the console and the host computer unit, is used to uniformly call one or more host computers in the host computer unit through the console and drive the HIL bench module and the electrical control system module under test to complete the test action. The HIL bench module is used to receive instructions and simulate signals transmitted by the automated test module, and to transmit simulated signals to the electrical control system module under test. The tested electrical control system module is used to receive analog signals from the HIL bench module and instructions transmitted by the automated test module to complete the test.

[0015] Preferably, the automated testing module includes multiple PC terminals, each PC terminal having a host computer unit and / or a main control console, the host computer unit including one or more host computers, and the automated testing module including a PC terminal with a main control console and one or more PC terminals with host computer units.

[0016] Preferably, the automated testing module includes: The encapsulation module is used to encapsulate the APIs provided by the host computer of the PC terminal to obtain the host computer API ports. Using the Socket network programming library, a globally unique port number is assigned and bound to each encapsulated service. The host computer includes, but is not limited to, the debugging CAN host computer, the HIL host computer, and the vehicle CAN host computer. The parsing module is used by the main control console to parse the test sequence, encapsulate the test instructions in the test sequence, and transmit them to the host computer's API port. The execution module is used to receive encapsulated test commands from the host computer's API port, parse them, and execute the parsed test commands to drive, but is not limited to, the HIL bench module and the electrical control system module under test to complete the test actions.

[0017] Preferably, the parsing module is specifically used for: The main console reads and parses the test sequence from the test cases to obtain the test instructions. Based on the function type of the test instructions, the test instructions are encapsulated into data packets using the TCP protocol and transmitted to the host computer's API port.

[0018] Preferably, the execution module is specifically used for: The host computer's API port maps the received encapsulated test instructions into specific executable functions or operations, which are then executed by the host computer.

[0019] Compared with existing technologies, the above technical solution has the following advantages: 1. This invention encapsulates multiple host computer APIs, sets up host computer API ports, and performs unified data transmission through the host computer API ports. By using TCP protocol network communication, it integrates heterogeneous host computer resources distributed on multiple PC terminals into a virtual, uniformly invoked "test execution cluster", thereby realizing centralized, remote, and automated scheduling of multiple host computers. 2. This invention achieves service-oriented architecture by setting up the host computer API port, networking by utilizing the TCP / IP protocol, and centralized scheduling by the main control console. By combining these three elements, it effectively solves the problem of collaborative automation under distributed deployment of multiple host computers in HIL testing, and achieves a leap in testing efficiency. Attached Figure Description

[0020] Figure 1 This is a flowchart of the communication method for multi-host computer collaborative invocation disclosed in this invention; Figure 2 This is a flowchart of the communication steps of the automated testing module disclosed in a preferred embodiment of the present invention; Figure 3 This is a structural framework diagram of the communication system for multi-host computer collaborative invocation disclosed in this invention; Figure 4 This is a schematic diagram of a host computer linkage communication structure disclosed in a preferred embodiment of the present invention; Figure 5 This is a schematic diagram of another host computer linkage communication structure disclosed in a preferred embodiment of the present invention.

[0021] Figure label: 40-Automatic test module, 50-HIL bench module, 60-Electrical control system module under test. Detailed Implementation

[0022] The advantages of the present invention will be further illustrated below with reference to the accompanying drawings and specific embodiments.

[0023] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0024] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” as used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0025] It should be understood that although the terms first, second, third, etc., may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are used only to distinguish information of the same type from one another. For example, without departing from the scope of this disclosure, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0026] In the description of this invention, it should be understood that the terms "longitudinal", "lateral", "up", "down", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0027] In the description of this invention, unless otherwise specified and limited, it should be noted that the terms "installation", "connection" and "linking" should be interpreted broadly. For example, they can refer to mechanical or electrical connections, or internal connections between two components. They can be direct connections or indirect connections through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms according to the specific circumstances.

[0028] In the following description, suffixes such as "module," "part," or "unit" used to denote elements are used only for the convenience of the description of the invention and have no specific meaning in themselves. Therefore, "module" and "part" can be used interchangeably.

[0029] like Figure 1 As shown, to achieve the above objectives, this invention discloses a communication method for multi-host computer collaborative invocation in HIL automated testing, comprising the following steps: Step S10: The automated test module uses the console to uniformly mobilize one or more host computers in the host computer unit and drive the HIL bench module and the electrical control system module under test to complete the test action. In step S20, the HIL bench module receives the instructions and simulates the signals transmitted by the automated test module, and transmits the simulated signals to the electrical control system module under test. In step S30, the tested electrical control system module receives the analog signal from the HIL bench module and the instructions transmitted by the automated test module to complete the test.

[0030] Specifically, refer to Figure 4The HIL bench module is equipped with a HIL bench, which serves as the physical core of the system. It is typically connected to an adapter board via a DB50 high-performance multi-pin interface and is responsible for transmitting a large number of raw I / O signals. The adapter board plays a crucial role in interface adaptation and management. It receives signals from the HIL bench, converts them, and distributes them to the DB50 interface on the other end. That is, the HIL bench module and the under-test (UTC) system module are connected via DB50. In addition, the UTC system module and the automated test module are connected via a CAN / CANFD bus. The CAN / CANFD bus provides a physical network channel between the UTC system module and the host computer in the automated test module.

[0031] More specifically, the system, consisting of an automated testing module, a HIL bench module, and a tested electronic control system module, can be divided into multiple layers, from bottom to top: the physical layer, the transport layer, the session layer, the presentation layer, and the application layer. The physical layer and the transport layer are responsible for the specific transmission and reception of electrical signals and the transmission of network messages (such as CAN, CAN FD, Ethernet, etc.). The session layer is responsible for managing the parsing of automated testing instructions. The presentation layer serves as a bridge connecting the upper-layer application and the lower-layer communication, and its core function is to complete the encoding and decoding between application data and network messages. The application layer contains specific test cases, simulation models (such as motor models and vehicle models), and human-machine interfaces.

[0032] The session layer is used to predefine test cases. Test cases specify the test objectives, steps, conditions and expected results. The abstract test cases are then transformed into specific automated tool instructions. The generated instructions are parsed and distributed to different hardware and software layers (such as the application layer) to direct the execution of specific operations, such as controlling the HIL test bench, sending CAN messages, reading signals, etc., and finally driving the application layer functions to complete the actual test actions. The presentation layer first reads the configuration information of the current test item, mainly the software version number of the tested electronic control system module, and then performs DBC file mapping based on the version number. It matches a specific software version with a dedicated DBC file that defines all communication matrices (such as CAN messages and signals), realizing dynamic mapping of "version number - communication protocol". After matching, the mapped target DBC file is imported into the test environment. Using the loaded DBC file that is completely matched with the current one, the CAN / CAN FD communication link is initialized and established, enabling the CAN host computer and the tested electronic control system module to automatically connect based on the software version number. The application layer receives instructions from the upper layer, such as scheduling from the session layer or "test case execution instructions" directly initiated by the user. It coordinates and drives the various host computers in the lower layer to perform specific operations, including sending stimulus signals from the HIL test bench, controlling model operation, and sending messages to the tested electronic control system via the CAN bus. This actually stimulates various operating conditions of the tested system. Simultaneously, it collects and records all feedback signals from the tested electronic control system modules in real time and synchronously. The recorded test signals are automatically compared and analyzed with the predefined "expected results" or standard specifications in the test cases to determine whether the tested system's functions and performance are qualified. Further data analysis may be performed. Finally, all information, including test execution records, result evaluation details, and judgment conclusions, is automatically summarized and formatted into a complete test report. It should be noted that other parts not described are existing technologies and will not be elaborated upon here.

[0033] Furthermore, the automated testing module includes multiple PC terminals, each PC terminal having a host computer unit and / or a main control console. The host computer unit includes one or more host computers. The automated testing module includes a PC terminal with a main control console and one or more PC terminals with host computer units. That is, the automated testing module includes at least two PC terminals: a PC terminal with a main control console and a PC terminal with a host computer unit. The PC terminal with the main control console may also have a host computer.

[0034] like Figure 2 As shown, step S10 includes the following steps: Step S101: Encapsulate the API provided by the host computer of the PC terminal to obtain the host computer API port. Use the Socket network programming library to assign and bind a globally unique port number to each encapsulated service. The host computer includes, but is not limited to, the debugging CAN host computer, the HIL host computer, and the vehicle CAN host computer. Step S102: The main control console parses the test sequence, encapsulates the test instructions in the test sequence, and transmits them to the host computer's API port. Furthermore, the main console reads and parses the test sequence from the test cases to obtain test instructions. Based on the functional type of the test instructions, the test instructions are encapsulated into data packets via the TCP protocol and transmitted to the host computer's API port. Specifically, this step transforms abstract test cases into concrete, executable automated tool instructions, translating high-level test requirements into a standardized and recognizable set of commands. Step S103: The host computer API port receives the encapsulated test command, parses it, and executes the parsed test command to drive, but is not limited to, the HIL bench module and the electrical control system module under test to complete the test action. Furthermore, the host computer's API port maps the received encapsulated test instructions into specific executable functions or operations, which are then executed by the host computer.

[0035] Specifically, the first step is to register services and bind ports. This involves encapsulating the application programming interfaces (APIs) provided by various host computers (such as HIL host computer, vehicle CAN host computer, and debugging CAN host computer) deployed on different PC terminals. Using the Socket network programming library, a globally unique port number is assigned and bound to each service. This step completes the discovery and addressing of network services, laying the foundation for remote calls. Next, test sequence parsing is performed. The main console, as the unified command center, reads and parses the test sequence from the test cases. This sequence contains a series of high-level test instructions that specify "what to do", such as: stimulating a certain signal or checking a certain message. Next, instruction encapsulation and network transmission are performed. The main control console encapsulates the abstract test instructions into data packets according to their function type using the TCP protocol, and reliably transmits them to the corresponding host computer's API service listening port. TCP ensures the reliability, orderliness, and integrity of instruction transmission in complex network environments. Next, instruction parsing and function mapping are performed. After receiving the instruction, the server-side API residing in each host computer parses the received instruction data and maps it precisely to a specific executable function or operation, i.e. "how to do it", such as calling a specific function in a DLL file. Finally, after the instructions are successfully parsed, each host computer executes the function it calls, which in turn drives hardware resources such as the HIL test bench and CAN bus to complete the actual test actions, such as sending messages, changing signal states, and reading feedback.

[0036] In summary, the above invocation steps, through the design of service-oriented (API) and networking (TCP / Socket), integrate heterogeneous host computer resources distributed across multiple PCs into a virtual, uniformly invoked "test execution cluster," thereby achieving centralized, remote, and automated scheduling of multiple host computers.

[0037] like Figure 5 As shown, in a preferred embodiment of the present invention, a host computer linkage communication structure is constructed, and the communication method based on this communication structure includes: The APIs provided by the HIL host computer of the second PC terminal, the CAN host computer of the whole vehicle, and the debugging CAN host computer of the first PC terminal are encapsulated as services to obtain the first host computer API port, the second host computer API port and the third host computer API port respectively. Using the Socket network programming library, the encapsulated service is assigned and bound to a port number, which is a globally unique port number. The main control console located on the first PC terminal parses the test sequence, encapsulates the test instructions in the test sequence, and transmits them to the corresponding host computer API port. The host computer determines the first host computer API port or / and the second host computer API port or / and the third host computer API port according to the test instructions. The host computer API port that receives the instruction parses the encapsulated test instruction, executes the parsed test instruction, and drives, but is not limited to, the HIL bench module and the electrical control system module under test to complete the test action. The main control console transmits commands to the debugging CAN host computer via TCP protocol, and the first PC terminal and the second PC terminal are interconnected via network cable via TCP / IP protocol.

[0038] Specifically, the first PC terminal is the main control node, which sets up the main control console and the debugging CAN host computer. The main control console acts as the brain of the test task, used to parse the test sequence, schedule and instruct all host computers. The debugging CAN host computer is used for communication tasks related to debugging the CAN bus, such as software flashing and deep monitoring. The second PC terminal is the execution node, with a HIL host computer and a vehicle CAN host computer set up. The HIL host computer is used to run the real-time model, manage I / O boards, and interact with the electrical signals of the tested electronic control system module. The vehicle CAN host computer is used to simulate the vehicle network environment and generate and parse the vehicle CAN bus messages. The first and second PC terminals are interconnected via network cable using the TCP / IP protocol, forming a backbone network. All remote call commands and data exchanges across devices are conducted through this channel. In the first PC terminal, the main control console and the debugging CAN host computer are also connected via the TCP protocol. Although the debugging CAN host computer and the main control console are located on the same PC terminal, in order to maintain the uniformity and flexibility of the architecture, they also use TCP loopback communication for command transmission, ensuring that the calling method is consistent whether the host computer is local or remote, thus simplifying the complexity of system design.

[0039] In this embodiment, an application programming interface (API) is encapsulated for each functional module of the host computer, and a globally unique network port number is bound to each API service using the Socket library. This makes each host computer's function an independent service accessible via a network address (IP + port), achieving service encapsulation and addressing. Next, a main control console deployed on the first PC terminal serves as the sole command center, responsible for reading and parsing the test sequence. Then, through a reliable TCP protocol, abstract test instructions are encapsulated into data packets and remotely transmitted to the corresponding port of the target PC terminal (second PC terminal or local), achieving centralized scheduling and instruction distribution. On each host computer, a dedicated session layer parsing module is responsible for receiving TCP instructions and translating and mapping them into executable functions and operation calls, ultimately driving the hardware to execute tests, achieving instruction parsing and mapping. Through the above steps, the function of remotely, automatically, and reliably calling heterogeneous host computers is achieved.

[0040] Furthermore, this invention employs a standard TCP / IP network as a unified communication backbone, completely replacing traditional local process calls or complex custom communication cables. Regardless of whether the host computer is distributed across different PC terminals (such as between the first and second PC terminals) or located on the same PC terminal (such as the main control console and the debugging CAN host computer within the first PC terminal), the same TCP protocol is used for communication, achieving unified logical calls and complete physical decoupling. Because the main control console does not need to know the location of the target host computer, it only needs to know its IP address and port number to make calls, greatly enhancing the system's flexibility, scalability, and maintainability.

[0041] like Figure 3 As shown, to achieve the above objectives, the present invention also discloses a communication system for HIL automated testing involving collaborative invocation of multiple host computers, comprising: The automated testing module 40 includes, but is not limited to, a console and a host computer unit, which is used to uniformly call one or more host computers in the host computer unit through the console and drive the HIL bench module and the electrical control system module under test to complete the test action. HIL bench module 50 is used to receive instructions and simulate signals transmitted by the automated test module, and to transmit simulated signals to the electrical control system module under test. The tested electrical control system module 60 is used to receive analog signals from the HIL bench module and instructions transmitted by the automated test module to complete the test.

[0042] Furthermore, the automated testing module includes multiple PC terminals, each PC terminal having a host computer unit and / or a main control console, the host computer unit including one or more host computers, and the automated testing module including a PC terminal with a main control console and one or more PC terminals with host computer units.

[0043] Furthermore, the automated testing module 40 includes: The encapsulation module is used to encapsulate the APIs provided by the host computer of the PC terminal to obtain the host computer API ports. Using the Socket network programming library, a globally unique port number is assigned and bound to each encapsulated service. The host computer includes, but is not limited to, the debugging CAN host computer, the HIL host computer, and the vehicle CAN host computer. The parsing module is used by the main control console to parse the test sequence, encapsulate the test instructions in the test sequence, and transmit them to the host computer's API port. The execution module is used to receive encapsulated test commands from the host computer's API port, parse them, and execute the parsed test commands to drive, but is not limited to, the HIL bench module and the electrical control system module under test to complete the test actions.

[0044] Furthermore, this parsing module is specifically used for: The main console reads and parses the test sequence from the test cases to obtain the test instructions. Based on the function type of the test instructions, the test instructions are encapsulated into data packets using the TCP protocol and transmitted to the host computer's API port.

[0045] Furthermore, this execution module is specifically used for: The host computer's API port maps the received encapsulated test instructions into specific executable functions or operations, which are then executed by the host computer.

[0046] It should be noted that this system corresponds to the method described above. For other parts not described, please refer to the content of that method, which will not be repeated here.

[0047] It should be noted that the embodiments of the present invention have better implementability and are not intended to limit the present invention in any way. Any person skilled in the art may use the above-disclosed technical content to change or modify it into equivalent effective embodiments. However, any modifications or equivalent changes and modifications made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall still fall within the scope of the technical solution of the present invention.

Claims

1. A communication method for collaborative invocation of multiple host computers in HIL automated testing, characterized in that, Includes the following steps: The automated testing module uses the console to uniformly control one or more host computers in the host computer unit and drive the HIL bench module and the electrical control system module under test to complete the test actions. The HIL bench module receives instructions and simulates signals from the automated test module, and transmits simulated signals to the electrical control system module under test. The tested electrical control system module receives analog signals from the HIL bench module and instructions transmitted by the automated test module to complete the test.

2. The communication method for multi-host computer collaborative invocation in HIL automated testing as described in claim 1, characterized in that, The automated testing module includes multiple PC terminals, each PC terminal having a host computer unit and / or a main control console. The host computer unit includes one or more host computers. The automated testing module includes a PC terminal with a main control console and one or more PC terminals with host computer units.

3. The communication method for multi-host computer collaborative invocation in HIL automated testing as described in claim 2, characterized in that, The automated testing module uses a console to uniformly control one or more host computers in the host computer unit, and drives the HIL bench module and the electrical control system module under test to complete the test actions, including the following steps: The API provided by the host computer of the PC terminal is encapsulated as a service to obtain the host computer API port. Using the Socket network programming library, a globally unique port number is assigned and bound to each encapsulated service. The host computer includes, but is not limited to, the debugging CAN host computer, the HIL host computer, and the vehicle CAN host computer. The main control console parses the test sequence, encapsulates the test instructions in the test sequence, and transmits them to the host computer's API port. The host computer API port receives and parses the encapsulated test commands, executes the parsed test commands, and drives, but is not limited to, the HIL bench module and the electrical control system module under test to complete the test action.

4. The communication method for multi-host computer collaborative invocation in HIL automated testing as described in claim 3, characterized in that, The main control console parses the test sequence, encapsulates the test instructions in the test sequence, and transmits them to the host computer's API port, including the following steps: The main control console reads and parses the test sequence from the test cases to obtain the test instructions. Based on the function type of the test instructions, the test instructions are encapsulated into data packets via the TCP protocol and transmitted to the host computer's API port.

5. The communication method for multi-host computer collaborative invocation in HIL automated testing as described in claim 3, characterized in that, The host computer API port receives, parses, and executes the encapsulated test commands, including the following steps: The host computer's API port maps the received encapsulated test instructions into specific executable functions or operations, and the host computer executes the specific functions or operations.

6. The communication method for multi-host computer collaborative invocation in HIL automated testing as described in claim 3, characterized in that, The method specifically includes the following steps: The APIs provided by the HIL host computer of the second PC terminal, the CAN host computer of the whole vehicle, and the debugging CAN host computer of the first PC terminal are encapsulated as services to obtain the first host computer API port, the second host computer API port and the third host computer API port respectively. Using the Socket network programming library, the encapsulated service is assigned and bound to a port number, which is a globally unique port number. The main control console located on the first PC terminal parses the test sequence, encapsulates the test instructions in the test sequence, and transmits them to the corresponding host computer API port. The host computer API port that receives the instruction parses the encapsulated test instruction, executes the parsed test instruction, and drives, but is not limited to, the HIL bench module and the electrical control system module under test to complete the test action. The main control console transmits commands to the debugging CAN host computer via TCP protocol, and the first PC terminal and the second PC terminal are interconnected via network cable via TCP / IP protocol.

7. A communication system for HIL automated testing involving multiple host computers in collaborative invocation, characterized in that, include: An automated testing module, including but not limited to a console and a host computer unit, is used to uniformly mobilize one or more host computers in the host computer unit through the console and drive the HIL bench module and the electrical control system module under test to complete the test action. The HIL bench module is used to receive instructions and simulate signals transmitted by the automated test module, and to transmit simulated signals to the electrical control system module under test. The tested electrical control system module is used to receive analog signals from the HIL bench module and instructions transmitted by the automated test module to complete the test.

8. The communication system for HIL automated testing with multi-host computer collaborative invocation as described in claim 7, characterized in that, The automated testing module includes multiple PC terminals, each PC terminal having a host computer unit and / or a main control console. The host computer unit includes one or more host computers. The automated testing module includes a PC terminal with a main control console and one or more PC terminals with host computer units.

9. The communication system for HIL automated testing with multi-host computer collaborative invocation as described in claim 8, characterized in that, The automated testing module includes: The encapsulation module is used to encapsulate the APIs provided by the host computer of the PC terminal to obtain the host computer API ports. Using the Socket network programming library, a globally unique port number is assigned and bound to each encapsulated service. The host computer includes, but is not limited to, the debugging CAN host computer, the HIL host computer, and the vehicle CAN host computer. The parsing module is used by the main control console to parse the test sequence, encapsulate the test instructions in the test sequence, and transmit them to the host computer's API port. The execution module is used to receive encapsulated test commands from the host computer's API port, parse them, and execute the parsed test commands to drive, but is not limited to, the HIL bench module and the electrical control system module under test to complete the test actions.

10. The communication system for HIL automated testing with multi-host computer collaborative invocation as described in claim 9, characterized in that, The parsing module is specifically used by the main control console to read and parse the test sequence from the test cases to obtain test instructions. According to the function type of the test instructions, the test instructions are encapsulated into data packets via the TCP protocol and transmitted to the host computer API port. The execution module is specifically used by the host computer API port to map the received encapsulated test instructions into specific executable functions or operations, and the host computer executes the specific functions or operations.

Images