A distributed hardware remote communication system based on UDP protocol and a control method thereof

Abstract

The application provides a distributed hardware remote communication system based on a UDP protocol and a control method thereof, and belongs to the technical field of data communication. The system specifically comprises a host computer, a plurality of test devices in communication connection with the host computer, and each test device is configured with one or more hardware board cards. The host computer is used for sending instructions to the test devices, and the host computer and the test devices adopt a UDP communication protocol for communication. The test device is used for receiving and analyzing the instructions, and driving the hardware board card according to the analyzed instructions. The hardware board card is in communication connection with a product to be tested. After receiving the instructions from the host computer, the test device drives the hardware board card to test the product to be tested and receive feedback information of the product to be tested. The test device is used for receiving and analyzing the feedback information, and converting the analyzed feedback information into data of the UDP protocol, and transmitting the data to the host computer through a UDP channel for analysis. Through the processing scheme, the application range of the test hardware is expanded.

Description

Technical Field

[0001] This application relates to the field of data communication technology, and in particular to a distributed hardware remote communication system based on the UDP protocol and its control method. Background Technology

[0002] In embedded system testing, with the increasing use of communication buses, the required hardware support also increases. Existing test hardware often needs to be upgraded or modified, which is costly. Furthermore, the operating systems used on the devices may not support the new hardware drivers, reducing the versatility of the devices.

[0003] Adding a new set of test hardware is used to expand the existing test environment. To simplify operation, most test equipment uses standalone test software. However, standalone test software lacks scalability, and establishing data communication between multiple hardware components is also limited. Summary of the Invention

[0004] In view of this, embodiments of this application provide a distributed hardware remote communication control method based on the UDP protocol. By extending existing hardware drivers, it meets the needs of various types of hardware in embedded system testing, making it compatible with existing hardware boards. Without changing the existing hardware, it adds the UDP communication protocol, encapsulates the hardware driver layer, changes the testing requirements of the embedded product's communication bus, and improves testing efficiency.

[0005] In a first aspect, embodiments of this application provide a distributed hardware remote communication system based on the UDP protocol. The system includes a main control computer and multiple test devices that are communicatively connected to the main control computer. Each test device is configured with one or more hardware boards.

[0006] The main control computer is used to send instructions to the test equipment, and the main control computer and the test equipment communicate using the UDP communication protocol;

[0007] The test equipment is used to receive and parse the instructions, and drive the hardware board according to the parsed instructions.

[0008] The hardware board communicates with the product under test, and after being driven, it tests the product under test and receives feedback information from the product under test, and transmits the feedback information to the test equipment.

[0009] The testing equipment is used to receive and parse the feedback information, and convert the parsed feedback information into UDP protocol data, which is then transmitted to the main control computer for analysis via the UDP channel.

[0010] According to a specific implementation of an embodiment of this application, the driver layer of the packaged hardware board is encapsulated as an application programming interface (API), which is used to be called by the test device.

[0011] According to a specific implementation of this application embodiment, the parameter information of the application interface includes: hardware board initialization parameter information, configuration information loading parameter information, channel usage parameter information, and data transmission and reception parameter information.

[0012] According to a specific implementation of an embodiment of this application, the test device is equipped with a data protocol module, which is used to formulate a communication protocol format according to the UDP communication protocol.

[0013] According to a specific implementation of an embodiment of this application, the communication protocol format includes a packet header, hardware board type, hardware board channel, data message number, actual data, and data verification.

[0014] According to a specific implementation of an embodiment of this application, the packet header includes a sending information identifier and a receiving information identifier;

[0015] The hardware board types are identified by Arabic numerals in sequence for different hardware boards;

[0016] The hardware board channel number is used to specify the specific channel of the hardware board for communication based on the number of channels on the hardware board.

[0017] The data message number is used to specify the specific MsgId sent or received by the hardware board;

[0018] The actual data is used to specify the quantity of actual data sent and received, as well as the real data;

[0019] The data verification is used to specify a verification method to verify the data information from the packet header to the actual data, so as to ensure the reliability of the data.

[0020] According to a specific implementation of an embodiment of this application, the hardware board receives instructions from the main control computer through an execution thread mechanism and analyzes the data by calling the data protocol module.

[0021] According to a specific implementation of this application, the measurement and testing device parses the instructions / feedback information through a program resident on the device, analyzes the meaning of the data, and sends the data according to the meaning of the bytes. The data transmission and reception adopts the UDP communication protocol.

[0022] Secondly, embodiments of this application also provide a control method for a distributed hardware remote communication system based on the UDP protocol, employing the distributed hardware remote communication system based on the UDP protocol as described in any embodiment of the first aspect. The control method includes the following steps:

[0023] S1. The main control computer sends test commands to multiple test devices via the UDP communication protocol;

[0024] S2. The test device receives the test command and parses the test command, and drives the hardware board according to the parsed test command;

[0025] S3. The hardware board is connected to the product under test for communication. After the hardware board is driven, it tests the product under test.

[0026] S4. The hardware board receives feedback information from the product under test and transmits the feedback information to the testing equipment.

[0027] S5. The test device receives the feedback information and parses it. The parsed feedback information is then transmitted to the main control computer for analysis via the UDP communication protocol.

[0028] According to a specific implementation of an embodiment of this application, step S2 specifically includes the following steps:

[0029] S201. The program residing in the test equipment performs the operation of initializing the hardware board;

[0030] S202. Execute the initialization process of UDP communication socket. If the network connection is successful, start the thread waiting mechanism and jump to step 203; otherwise, check the network connection.

[0031] S203. Start the thread mechanism to continuously detect the UDP port data bound to the hardware board, wherein the UDP port data is the test command issued by the main control computer;

[0032] S204. If data is detected, proceed to step 205; otherwise, continue waiting for detected data in the thread.

[0033] S205. Perform data communication packet header judgment. If the judgment is correct, jump to step 206 to parse the data. Otherwise, return to the current test and continue to wait for data.

[0034] S206. Perform data parsing operation, parse the relevant data according to the communication protocol format defined by the UDP communication protocol, and convert it into instructions that the hardware board can recognize;

[0035] S207. The parsed instructions are filled into the corresponding parameters of the encapsulated hardware driver application interface to perform the execution operation of the hardware board and drive the hardware board to send data.

[0036] Beneficial effects

[0037] The distributed hardware remote communication system based on the UDP protocol in this application embodiment is compatible with the interaction of stand-alone hardware driver data on the test equipment side, realizes the compatibility of network UDP communication driver data interaction, expands the application scope of test hardware, and provides richer means in testing and product development by utilizing the flexible interaction capabilities of the UDP protocol while meeting data communication tasks.

[0038] The control method proposed in this invention can be widely used in embedded system testing. The method is located in the program residing on the device side, and is not affected by the test platform and operating system. It has excellent inheritance, scalability and portability. Attached Figure Description

[0039] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0040] Figure 1 This is a schematic diagram of a distributed hardware remote communication system based on the UDP protocol according to an embodiment of the present invention;

[0041] Figure 2 This is a flowchart of a control method for a distributed hardware remote communication system based on the UDP protocol according to an embodiment of the present invention. Detailed Implementation

[0042] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0043] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. This application can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0044] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this application, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0045] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. The drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0046] Furthermore, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that the described aspects can be practiced without these specific details.

[0047] In a first aspect, embodiments of this application provide a distributed hardware remote communication system based on the UDP protocol, referring to... Figure 1 Specifically, it includes a main control computer and multiple test devices that communicate with the main control computer. Each test device is equipped with a hardware board.

[0048] Specifically, the main control computer sends instructions to the test equipment. Communication between the main control computer and the test equipment uses the UDP protocol. The main control computer can connect to multiple test equipment terminals via a switch. Upon power-up, the test equipment terminals perform a series of hardware board initialization operations to establish a UDP data channel. The test equipment receives and parses the instructions sent by the main control computer, and drives the hardware boards according to the parsed instructions. The hardware boards communicate with the product under test (DUT), perform tests on the DUT after being driven, and receive feedback information from the DUT, transmitting the feedback information to the test equipment. The test equipment receives and parses the feedback information, converts the parsed feedback information into UDP protocol data, and transmits it to the main control computer for analysis via the UDP channel.

[0049] Before testing the aforementioned system, the driver layer of the hardware board needs to be encapsulated. Specifically, this is done by calling the hardware manufacturer's SDK (Software Development Kit), which encapsulates the driver layer of the hardware board. This encapsulates basic functions such as hardware initialization, loading hardware board configuration information, and sending and receiving hardware data. This encapsulation is then presented as an API (Application Programming Interface) for use by upper-layer applications. The API includes various parameters related to hardware initialization, configuration loading, channel usage, and data transmission and reception.

[0050] Furthermore, a data protocol module needs to be developed on the testing equipment side. This module is used to develop a compliant communication protocol format according to the UDP communication protocol. The communication protocol format includes a packet header, hardware board type, hardware board channel, data message number, actual data, and data verification.

[0051] In one embodiment, the packet header includes a sending information identifier and a receiving information identifier. For example, a custom 0xFE identifier is used to represent the sending information, and a 0xFD identifier represents the receiving information.

[0052] Hardware board types are identified by Arabic numerals in sequence, such as 1394, AFDX / FCAE / 1533, etc. Each new hardware board type is assigned a new serial number.

[0053] The hardware board channel number is used to specify the specific channel of the hardware board to be used for communication, based on the number of channels on the hardware board. If there are too many channels on the board, it is specified that a specific channel of the board will be used for communication.

[0054] The data message number is used to specify the specific MsgId sent or received by the hardware board, and to filter out unnecessary message numbers.

[0055] Actual data is used to specify the actual amount of data sent and received, as well as the real data.

[0056] Data validation is used to specify a validation method to verify the data information from the packet header to the actual data, ensuring the reliability of the data.

[0057] Furthermore, the hardware board receives instructions from the host computer through a thread mechanism and analyzes the data by calling the data protocol module. Specifically, after the hardware board is powered on and initialized, it executes a thread function, waits for instructions from the host computer, and upon receiving an instruction, effectively analyzes the data by calling the data protocol module. Based on the meaning of the instruction, it drives the corresponding hardware board to send relevant commands to perform bus testing on the product under test. After receiving the command, the product under test executes the corresponding operation, and the operation result is fed back to the hardware board. The hardware board then converts the result into data in UDP communication protocol format and sends it back to the host computer.

[0058] Furthermore, the main control computer sends UDP data via network protocol. The test equipment parses the instructions / feedback information through a program resident on the device, analyzes the meaning of the data, and sends data according to the meaning of the bytes. Data transmission and reception use the UDP communication protocol.

[0059] Secondly, embodiments of this application also provide a control method for a distributed hardware remote communication system based on the UDP protocol, employing a distributed hardware remote communication system based on the UDP protocol as described in any embodiment of the first aspect, referring to... Figure 2 The figure illustrates the main flow of the control method in this embodiment, which mainly includes the following steps:

[0060] S1. The main control computer sends test commands to multiple test devices via the UDP communication protocol.

[0061] S2. The test equipment receives and parses the test commands, and drives the hardware board according to the parsed test commands. This step specifically includes the following steps:

[0062] When the S200 test equipment is powered on, the program residing on the test equipment starts the service and runs normally.

[0063] S201. The program residing on the test equipment performs the operation of initializing the hardware board to ensure that the hardware is installed correctly. If there is a fault, you need to test the hardware yourself.

[0064] S202. Execute the initialization process of UDP communication socket. If the network connection is successful, start the thread waiting mechanism and jump to step 203; otherwise, check the network connection.

[0065] S203. Start the thread mechanism and continuously detect the UDP port data bound to the hardware board. The UDP port data is the test command issued by the master computer. In order to prevent the program from being stuck due to data processing and the data not being received in time, a thread mechanism is used for operation.

[0066] S204. If data is detected, proceed to step 205; otherwise, continue waiting for detected data in the thread.

[0067] S205. Perform data communication packet header judgment. If the judgment is correct, jump to step 206 to parse the data. Otherwise, return to the current test and continue to wait for data.

[0068] S206. Perform data parsing operation. Based on the communication protocol format specified by the UDP communication protocol, parse the relevant data, including parsing packet header, hardware type, hardware channel, transmit and receive data message number, actual data, data check board and other data information, and convert them into instructions that can be recognized by the hardware board.

[0069] S207. The parsed instructions, i.e. the data parsed by UDP, are filled into the encapsulated hardware driver application programming interface (API) and the corresponding parameters of the API are filled into the hardware board to perform the execution operation, drive the hardware board to send data, and thus test the bus protocol of the product under test, which is an embedded product.

[0070] S3. The hardware board establishes a communication connection with the product under test. After the hardware board is driven, it tests the product under test. After the hardware board sends a command and executes it successfully, the embedded product will provide corresponding feedback information.

[0071] S4. The hardware board receives feedback information from the product under test and transmits the feedback information to the test equipment, that is, the hardware executes the feedback instruction to complete.

[0072] S5. The testing equipment receives and parses the feedback information. The parsed feedback information is then transmitted to the main control computer for analysis via the UDP communication protocol. Specifically, this includes the following steps:

[0073] S501. If the test device fails to receive the feedback information, i.e., the instruction execution fails, then it generates corresponding error information based on the error code value and reassembles the corresponding error information in reverse according to a predetermined UDP communication protocol format.

[0074] S502. If the test device successfully receives the feedback information, that is, the instruction is successfully executed, the data information is reassembled in reverse according to the predetermined UDP communication protocol format.

[0075] S503: The feedback information after assembly is transmitted to the main control computer via the UDP communication protocol. After the transmission is completed, the return thread mechanism continues to detect the next data. After the program starts normally, it will continue to loop in the thread until the application exits.

[0076] The system provided by this invention mainly involves initiating a UDP request on the main control computer to connect to multiple test device terminals. The test device terminals power on and perform a series of hardware initialization operations to establish a UDP data channel, receive commands from the main control computer, and control the hardware to achieve system testing of embedded products by controlling the hardware bus. The test feedback results are collected by the hardware and forwarded to the main control computer to complete a series of control tasks.

[0077] This invention relates to a distributed hardware board remote communication control method based on the UDP protocol. It extends existing test hardware by adding the UDP protocol, enabling data interaction between multiple test devices and hardware boards via a network. This combines hardware board debugging with network connectivity and also supports data interaction between the hardware board and the host computer system software. The embedded test software is divided into an application layer, a middleware layer, and a driver layer. This invention resides in the middleware layer, encapsulating the hardware board driver layer, defining the UDP transmission protocol, and communicating with the application layer. When the host computer uses the hardware board, it is independent of the operating system used by the hardware board and the physical location of the hardware board, exhibiting excellent inheritance, scalability, and portability.

[0078] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A distributed hardware remote communication system based on the UDP protocol, characterized in that, The system includes a main control computer and multiple test devices that are communicatively connected to the main control computer. Each test device is equipped with one or more hardware boards. The main control computer is used to send instructions to the test equipment, and the main control computer and the test equipment communicate using the UDP communication protocol; The test equipment is used to receive and parse the instructions, and drive the hardware board according to the parsed instructions. The hardware board communicates with the product under test, and after being driven, it tests the product under test and receives feedback information from the product under test, and transmits the feedback information to the test equipment. The testing equipment is used to receive the feedback information and parse it, and convert the parsed feedback information into UDP protocol data, which is then transmitted to the main control computer for analysis via the UDP channel. The driver layer of the hardware board is encapsulated as an application programming interface (API), which is used to be called by the test device. The test equipment is equipped with a data protocol module, which is used to formulate a communication protocol format according to the UDP communication protocol. The communication protocol format includes a packet header, hardware board type, hardware board channel, data message number, actual data, and data verification. The parameters for hardware board initialization, configuration loading, channel usage, and data transmission / reception.

2. The distributed hardware remote communication system based on UDP protocol according to claim 1, characterized in that, The packet header includes a sending information identifier and a receiving information identifier; The hardware board types are identified by Arabic numerals in sequence for different hardware boards; The hardware board channel number is used to specify the specific channel of the hardware board for communication based on the number of channels on the hardware board. The data message number is used to specify the specific MsgId sent or received by the hardware board; The actual data is used to specify the quantity of actual data sent and received, as well as the real data; The data verification is used to specify a verification method to verify the data information from the packet header to the actual data, so as to ensure the reliability of the data.

3. The distributed hardware remote communication system based on UDP protocol according to claim 1, characterized in that, The hardware board receives instructions from the main control computer through an execution thread mechanism and analyzes the data by calling the data protocol module.

4. The distributed hardware remote communication system based on UDP protocol according to claim 1, characterized in that, The test device parses the instructions / feedback information through a program resident on the device, analyzes the meaning of the data, and sends the data according to the meaning of the bytes. The data sending and receiving adopts the UDP communication protocol.

5. A control method for a distributed hardware remote communication system based on the UDP protocol, characterized in that, The control method of the distributed hardware remote communication system based on the UDP protocol as described in any one of claims 1-4 includes the following steps: S1. The main control computer sends test commands to multiple test devices via the UDP communication protocol; S2. The test device receives the test command and parses the test command, and drives the hardware board according to the parsed test command; S3. The hardware board is connected to the product under test for communication. After the hardware board is driven, it tests the product under test. S4. The hardware board receives feedback information from the product under test and transmits the feedback information to the testing equipment. S5. The test equipment receives the feedback information and parses it. The parsed feedback information is then transmitted to the main control computer for analysis via the UDP communication protocol. Step S2 specifically includes the following steps: S201. The program residing in the test equipment performs the operation of initializing the hardware board; S202. Execute the initialization process of UDP communication socket. If the network connection is successful, start the thread waiting mechanism and jump to step 203; otherwise, check the network connection. S203. Start the thread mechanism to continuously detect the UDP port data bound to the hardware board, wherein the UDP port data is the test command issued by the main control computer; S204. If data is detected, proceed to step 205; otherwise, continue waiting for detected data in the thread. S205. Perform data communication packet header judgment. If the judgment is correct, jump to step 206 to parse the data. Otherwise, return to the current test and continue to wait for data. S206. Perform data parsing operation, parse the relevant data according to the communication protocol format defined by the UDP communication protocol, and convert it into instructions that the hardware board can recognize; S207. The parsed instructions are filled into the corresponding parameters of the encapsulated hardware driver application interface to perform the execution operation of the hardware board and drive the hardware board to send data.

Images