Test system capable of realizing rapid configuration of communication protocol and UI interface

Abstract

The invention provides a test system capable of realizing rapid configuration of a communication protocol and a UI interface, and relates to the field of communication protocols. The receiving protocol configuration module generates a receiving protocol storage file according to the message name and the message attribute; the sending protocol configuration module generates a sending protocol storage file according to the message name and the message attribute; the interface UI configuration module generates an interface layout protocol storage file according to the monitoring signal and the interface expected display effect; the interface UI generation module stores a file according to an interface layout protocol and automatically generates a software test interface; a sending data generation module generates a parameter binding interface to complete framing of sending data; and the received data analysis module analyzes the received data and updates the data corresponding to the UI control on the test interface. The problems that a test system is only suitable for a fixed and single communication protocol data format, and the layout of a display interface is continuously adjusted due to different monitoring signals are solved. And the system is good in flexibility and has relatively high universality.

Description

Technical Field

[0001] This document relates to the field of communication protocols, and in particular to a test system that enables rapid configuration of communication protocols and UI interfaces. Background Technology

[0002] Traditionally, the host computer software for testing systems was custom-designed for specific products. Different products required different protocol data formats, resulting in a wide variety of highly specialized protocols. The user interface of the host computer software was closely tied to the sending and receiving protocols. If protocol parameters needed to be modified, or if the software was to be used for testing other products, the host computer software program had to be rewritten. This inefficient and repetitive development work was time-consuming, error-prone, and required users to have a certain level of programming knowledge. Furthermore, screen size limitations made interface design and control layout difficult when monitoring numerous signals, often resulting in a cluttered and disorganized interface. Each testing software had its own unique layout, making standardization difficult. Adding monitoring signals temporarily necessitated a redesign of the software interface, which was also a cumbersome process.

[0003] Therefore, there is an urgent need for a host computer software solution for testing systems to solve the problem that previous host computer testing systems were only applicable to a certain fixed and single communication protocol data format, and the display interface layout had to be constantly adjusted due to different monitoring signals. Summary of the Invention

[0004] This manual provides a testing system that enables rapid configuration of communication protocols and UI interfaces, addressing the problem that host computer testing systems are only applicable to a fixed, single communication protocol data format, and that the display interface layout is constantly adjusted due to different monitored signals.

[0005] Firstly, this specification provides a test system that enables rapid configuration of communication protocols and UI interfaces, including: UI generation module, receiving protocol configuration module, sending protocol configuration module, protocol file saving module, sending data generation module, and receiving data parsing module;

[0006] The receiving protocol configuration module is used to generate a receiving protocol save file based on the message name and message attributes entered by the user in the receiving message configuration interface, and then send it to the protocol file save module for saving.

[0007] The sending protocol configuration module is used to generate a sending protocol save file based on the message name and message attributes entered by the user in the sending message configuration interface, and then send it to the protocol file save module for saving.

[0008] The UI configuration module is used to bind the monitoring signal with the data in the received message according to the monitoring signal and the expected display effect of the interface, freely and flexibly configure each display control, generate an interface layout protocol save file, and send it to the protocol file save module for saving.

[0009] The protocol file saving module is used to store the received protocol saving file, the sent protocol saving file, and the interface layout protocol saving file;

[0010] The UI generation module is used to read the receiving protocol, sending protocol, and interface layout protocol from the protocol file storage module to generate the system test interface.

[0011] The data generation module is used to package the protocol parameters input by the user in the system test interface into a sending frame according to the sending protocol and send it to the product under test.

[0012] The received data parsing module is used to parse the response frames returned by the product under test according to the receiving protocol, display the parsed data information on the system test interface, and update the data information on the system test interface in real time.

[0013] Secondly, this specification provides a testing method that enables rapid configuration of communication protocols and UI interfaces, including:

[0014] The receiving protocol configuration module generates a receiving protocol save file based on the message name and message attributes entered by the user in the receiving message configuration interface, and sends it to the protocol file save module for saving.

[0015] The sending protocol configuration module generates a sending protocol save file based on the message name and message attributes entered by the user in the sending message configuration interface, and sends it to the protocol file save module for saving.

[0016] The UI configuration module binds the monitoring signals and the data in the received messages according to the monitoring signals and the expected display effect of the interface. It can freely and flexibly configure each display control, generate an interface layout protocol save file, and send it to the protocol file save module for saving.

[0017] The protocol file saving module reads and receives protocol files, sends protocol files, and saves interface layout protocol files.

[0018] The UI generation module reads the receiving protocol, sending protocol, and interface layout protocol from the protocol file saving module to generate the system test interface;

[0019] The data generation module takes the parameters entered by the user on the system test interface, packages them into a sending frame according to the sending protocol, and sends it to the product under test.

[0020] The receiving data parsing module parses the response frames sent back by the product under test according to the receiving protocol, displays the parsed data information on the system test interface, and updates the data information on the system test interface in real time.

[0021] Thirdly, this specification provides a protocol-configurable method for sending and receiving data frames, which specifically includes the following steps:

[0022] Step 1: After the test system initializes global variables, it reads the parameters in the sending protocol file and dynamically generates a sending protocol button; it reads the receiving protocol and interface configuration protocol to generate a test main interface display control group and establishes a connection between the display control group and the parsed data storage set.

[0023] Step 2: The test system maps the underlying hardware interface according to the communication device and communication method selected by the user. The program opens a main thread and a sub-thread. The main thread is responsible for the human-computer interaction work of software control and interface update, while the sub-thread is responsible for driving the underlying hardware to perform data reading and writing communication work and receiving and parsing data.

[0024] Step 3: The main thread of the sending protocol configuration module waits for the user to trigger the sending protocol button, generates a parameter binding interface according to the sending protocol, inputs the values ​​of each parameter control, and after the input is completed and the settings are confirmed, it assembles a frame of data to be sent according to the starting position and length of each parameter, data type, and frame type information.

[0025] Step 4: Based on the general protocol information in the transmission protocol file, determine whether the current frame is a single transmission frame or a periodic transmission frame.

[0026] Step 5: If it is a periodically transmitted frame, update the data in the acquisition frame transmission set with the data of the frame to be transmitted; if it is a single transmitted frame, determine whether it is a radar parameter binding frame.

[0027] Step 6: Based on the general protocol information in the transmission protocol file, determine whether the current transmission frame data is a radar parameter binding frame;

[0028] Step 7: If it is radar parameter binding frame data, then save the frame data to be sent into the radar parameter binding transmission set;

[0029] If it is not a radar parameter binding frame, the frame data to be sent is sent to the product under test through the hardware board mapped by the hardware interface layer.

[0030] Step 8: The sub-thread continuously checks whether there is data written in the radar parameter binding and sending set. If there is data written, it is split into several frames as needed and sent to the product under test through the hardware board mapped by the hardware interface layer. After sending, the radar parameter binding and sending set is cleared.

[0031] Step 9: If there is no data in the radar parameter binding and transmission set, check if there is data written in the acquisition frame transmission set. If there is data written, insert the sequence code and check value at the appropriate position according to the transmission protocol, and send it to the product under test through the hardware board mapped by the hardware interface layer.

[0032] Step 10: The receiving protocol configuration module queries the hardware board receiving buffer mapped by the hardware interface layer. If data is received, the frame length and verification are checked, and a frame of data that meets the requirements is sent to the data parsing function for processing.

[0033] Step 11: In the data parsing function, the data frame is parsed according to the starting position and length of each parameter, and then converted into the data format corresponding to each parameter as specified by the protocol. The parsed data is then stored in a file or database according to the receiving protocol.

[0034] Step 12: After parsing the data, the display controls are allocated according to the interface layout protocol, and the main thread is returned to update the display control groups of the UI interface.

[0035] The beneficial effects of this invention are as follows:

[0036] This specification provides a test system that enables rapid configuration of communication protocols and UI interfaces. The receiving protocol configuration module generates a receiving protocol save file based on message name and message attributes; the sending protocol configuration module generates a sending protocol save file based on message name and message attributes; the UI configuration module generates an interface layout protocol save file based on monitored signals and the expected display effect; the UI generation module automatically generates the software test interface based on the interface layout protocol save file; the sending data generation module generates a parameter binding interface and completes the framing of sending data; and the receiving data parsing module parses the received data and updates the data of the corresponding UI controls on the test interface. This method strongly decouples the communication protocol and software interface from the host computer software. Only when the host computer software is running does it read the parameter information from the communication protocol and software interface configuration files. This enables automatic parsing and configuration of the communication protocol within the software and dynamic generation of the human-machine interface. The parsed data can be flexibly combined with different controls and adjusted according to user preferences. The granularity of the parsed data can reach single-bit. Regardless of subsequent changes in communication protocols or the addition or adjustment of software interface inputs and displays, no code modification is required. Real-time interface configuration and a WYSIWYG (What You See Is What You Get) approach greatly enhance the communicability and flexibility of the control console software. It solves the problem that host computer testing software is only applicable to a fixed, single communication protocol data format, and the display interface layout constantly needs adjustment due to different monitored signals. When the communication protocol changes, it can efficiently modify the new protocol. The system has good flexibility and high versatility, is easy to operate, greatly reduces the development and maintenance costs of the control console software, and also solves the problem of poor maintainability in traditional methods. Attached Figure Description

[0037] The accompanying drawings, which are included to provide a further understanding of this specification and form part of this specification, illustrate exemplary embodiments and are used to explain this specification, but do not constitute an undue limitation thereof. In the drawings:

[0038] Figure 1 This is a schematic diagram of a test system that enables rapid configuration of communication protocols and UI interfaces, as provided in the embodiments of this specification.

[0039] Figure 2 This is a schematic diagram of an automatic configuration generation interface for a test system provided in the embodiments of this specification;

[0040] Figure 3 This is a schematic diagram of an interface for automatically generating parameters based on a message transmission protocol, provided in the embodiments of this specification.

[0041] Figure 4 This is a schematic diagram of a message sending configuration interface provided in the embodiments of this specification;

[0042] Figure 5 This is a schematic diagram of a message receiving configuration interface provided in the embodiments of this specification;

[0043] Figure 6 This is a schematic diagram of a host computer program initialization process provided in the embodiments of this specification;

[0044] Figure 7 This is a schematic diagram of a data framing, sending, receiving, and parsing process provided in the embodiments of this specification. Detailed Implementation

[0045] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments in this specification, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments in this application without creative effort are within the scope of protection of this document.

[0046] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings. Specific Implementation Example 1:

[0048] This embodiment provides a testing system that enables rapid configuration of communication protocols and UI interfaces. See [link to documentation]. Figures 1-6 It includes: UI generation module 1, receiving protocol configuration module 2, UI configuration module 3, sending protocol configuration module 4, protocol file saving module 5, sending data generation module 6, receiving data parsing module 7;

[0049] Specifically, the connection relationships between the various modules can be as follows:

[0050] like Figure 1 As shown, the receiving protocol configuration module 2, the sending protocol configuration module 4, and the interface UI configuration module 3 are respectively connected to the protocol file saving module 5, and the protocol file saving module 5 is connected to the interface UI generation module 1;

[0051] The data generation module 6 and the data parsing module 7 are respectively connected to the UI generation module 1.

[0052] Furthermore, the system also includes a hardware underlying module 8, wherein the data transmission generation module 6 and the data reception parsing module 7 communicate and interact with the product under test through the hardware underlying module 8.

[0053] The functions of each module are described in detail below:

[0054] The receiving protocol configuration module 2 is used to generate a receiving protocol save file based on the message name and message attributes entered by the user in the receiving message configuration interface, and then transmit it to the protocol file save module 5 for saving.

[0055] The sending protocol configuration module 4 is used to generate a sending protocol save file based on the message name and message attributes entered by the user in the sending message configuration interface, and then send it to the protocol file save module 5 for saving.

[0056] The UI configuration module 3 is used to bind the monitoring signal with the data in the received message according to the monitoring signal and the expected display effect of the interface, freely and flexibly configure each display control, generate an interface layout protocol save file, and send it to the protocol file save module 5 for saving.

[0057] The protocol file saving module 5 is used to store the received protocol saving file, the sent protocol saving file, and the interface layout protocol saving file;

[0058] The UI generation module 1 is used to read the receiving protocol, sending protocol, and interface layout protocol from the protocol file saving module 5 to generate the system test interface.

[0059] The data generation module 6 is used to package the protocol parameters input by the user in the system test interface into a sending frame according to the sending protocol and send it to the product under test.

[0060] The receiving data parsing module 7 is used to parse the response frame returned by the product under test according to the receiving protocol, display the parsed data information on the system test interface, and update the data information on the system test interface in real time.

[0061] Furthermore, when the communication protocol of the product under test changes, the receiving protocol configuration module 2, the sending protocol configuration module 4, and the interface UI configuration module 3 regenerate the receiving protocol save file, the sending protocol save file, and the interface layout protocol save file according to the new communication protocol received by the protocol configuration interface, thereby modifying the entire test software.

[0062] The following details the three types of protocol files in the Send Protocol Configuration Module 4, Receive Protocol Configuration Module 2, and Interface UI Configuration Module 3. These files are stored as XML files in the "Send Protocol", "Receive Protocol", and "Interface UI Layout and Generation" folders under the program project directory.

[0063] (1) Sending Protocol Configuration Module:

[0064] The sending protocol XML file consists of three parts:

[0065] General protocol information, basic protocol, and radar parameter protocol, format as follows: Figure 3 As shown;

[0066] Part One: General Protocol Information

[0067] The general protocol information is used to specify whether the current transmission protocol is periodic or single-transmission, checksum byte position, sequence code position, endianness, whether it includes radar parameter protocol, how many bytes are combined into one frame for transmission, maximum number of radar units to be bound, number of sub-protocols in the radar parameter protocol, and total number of bytes in the radar parameter protocol section. The specific meanings of each attribute are as follows:

[0068] 1) SendInterval: Periodic / single transmission flag (0: single transmission, 1: periodic transmission)

[0069] 2) CheckPosition: The starting byte of the checksum in the transmission protocol (applicable to frame protocols that transmit periodically).

[0070] 3) XuLieMaPosition: The starting position byte of the sequence code in the transmission protocol (applicable to frame protocols that transmit periodically).

[0071] 4) Direction: The order in which high and low bytes are sent in the communication protocol (0: low byte first, 1: high byte first).

[0072] 5) IsRadarParameter: Whether it contains a radar parameter type frame (0: does not contain radar parameter type, 1: contains radar parameter type)

[0073] 6) HowManyByteToDevide: How many bytes are combined into one frame for transmission (applicable to parameter binding frames that need to be split into several frames for transmission);

[0074] 7) RadarMaxNum: Number of radar parameter types (maximum number of radars that can be installed, applicable to parameter binding frames)

[0075] 8) RadarFrameNum: The number of sub-protocols contained in the radar parameter type (template).

[0076] 9) RadarFrameTotalByte: The number of bytes in the radar parameter type (template).

[0077] Part Two: Basic Agreement

[0078] The basic protocol is the main protocol part of the radar, and each of its clauses...<ControlProperty...... / > Each represents a sub-protocol. The host computer software will automatically generate corresponding parameter input controls on the interface based on the attributes in each sub-protocol;

[0079] Among them, the entity protocol attributes include: parameter name, parameter start position, length, endianness, control generation type, data value type, parsing and processing method, scale, data value unit, number of decimal places of data value, maximum and minimum values of numerical value, etc. The specific meanings of its main attributes are as follows:

[0080] 1) frameNum: Entity protocol serial number

[0081] 2) frameName: Entity protocol name, which is configured by the host computer program to be displayed as the signal name next to the UI control

[0082] 3) frameType: Entity protocol type, and its meaning is as follows:

[0083] 0 = "Numeric type", which is configured by the host computer program to be a TextBox control

[0084] 1 = "Enumeration type", which is configured by the host computer program to be a ComboBox control (Note 1)

[0085] 2 = "Constant type", which is a fixed hexadecimal value in the protocol (applicable to frame headers, frame tails, command words, etc.)

[0086] 3 = "Zero-padding type", which pads zeros during protocol splicing

[0087] 4 = "Check type", which is the checksum during protocol splicing

[0088] 5 = "Repeated type", which repeats the previously existing entity protocol segment during protocol splicing

[0089] 6 = "Sequence code", which is the sequence code during protocol splicing

[0090] 7 = "Radar parameter type", which inserts the radar parameter protocol here during protocol splicing (Note 2)

[0091] Among them: when frameType = 1, the next-level XML appears under <ControlProperty...... / > to represent the SelectItem in the ComboBox control. For example:

[0092] <SelectItem value = "0" key = "No target found" / >

[0093] <SelectItem value = "1" key = "Target found" / >

[0094] Among them: the radar parameter protocol radarParameter_templet has only 0, 1, 2, 3

[0095] 4) dataType: Entity protocol data type, with the following specific meanings:

[0096] 0 = "less than 8 bits" / >

[0097] 1="8-bit U" / >

[0098] 2="8-bit I" / >

[0099] 3="16-bit U" / >

[0100] 4="16-bit I" /

[0101] 5="32-bit U" / >

[0102] 6="32-bit I" / >

[0103] 7 = "Float" / >

[0104] 5) frameDefault: The default parameter value of the TextBox control configured by the host computer program.

[0105] 6) frameMax: Maximum value (used for judging input parameters exceeding limits and the maximum limit displayed by the Chart drawing control)

[0106] 7) frameMin: Minimum value (used for judging excessive input parameters and the minimum limit displayed by the Chart drawing control)

[0107] 8) frameRatio: Numerical scale

[0108] 9) frameBias: Numerical offset

[0109] 10) frameUint: Used to display the unit next to the TextBox control in the UI interface.

[0110] 11) frameConstant: Hexadecimal constant data (used in conjunction with frameType=2)

[0111] 12) frameDuplicate: Use this value as the entity protocol sequence number to copy an existing entity protocol (in conjunction with frameType=5).

[0112] 13) frameMinBit: The minimum bit size of data used when the entity protocol is less than 1 byte.

[0113] 14) frameMaxBit: The maximum number of bits used for data when the entity protocol is less than 1 byte.

[0114] Part Three: Radar Parameter Protocol

[0115] The radar parameter protocol is designed to simplify the configuration process. In parameter binding protocols, there are often situations where parameters for several radars need to be loaded simultaneously. If the parameters for each radar are entered into the basic protocol, the software interface would become too cumbersome. Since the protocol part of each radar parameter is the same, the "radar parameter protocol" is abstracted. Only one radar parameter protocol needs to be entered as a template, and the host computer software will embed this radar parameter protocol part into the basic protocol during processing, which simplifies the protocol configuration to the greatest extent.

[0116] The protocol attributes are similar to those of the basic protocol, and will not be described in detail here.

[0117] Figure 3 This is a parameter binding interface automatically generated based on the radar parameter protocol. For the message sending configuration interface, please refer to [link / reference]. Figure 4 .

[0118] (2) Receive Protocol Configuration Module:

[0119] Figure 5 This is the receiving protocol configuration interface. The parameter settings are similar to those in the sending protocol configuration interface, but with the addition of data display control options. After each sub-protocol data is parsed, you can choose to display it using a Chart control, a TextBox control, both controls, or no display. You can specify the data display method according to your needs.

[0120] The XML file for the receiving protocol is similar to that for the transmitting protocol, except that it lacks a radar parameter protocol section. Additionally, several attributes have been added to the basic protocol section.

[0121] 1) TextBoxGroupNumber: Represents the serial number of the TextBoxGroup control group.

[0122] 2) ChartGroupNumber: Represents the serial number of the ChartGroup control group.

[0123] 3) UserControlType: Specifies which control is used to display the parsed data (0: displayed as a TextBox control, 1: displayed as a drawing control, 2: displayed using both TextBox and drawing controls, 3: data is not displayed).

[0124] (3) Interface UI configuration module:

[0125] The interface layout protocol is located below the receiving protocol configuration interface (e.g., Figure 5As shown), multiple controls of the same type can be freely combined into control groups (TextBoxGroup, ChartGroup) to further configure and optimize the interface layout. Each control group can be flexibly arranged in any position on the test interface.

[0126] Figure 2 The software testing interface is based on Figure 5 The interface layout configuration is automatically generated.

[0127] The advantages of this interface layout configuration feature are as follows:

[0128] (1) It solves the problem that the previous test program still needed to consider the design of the software interface, and standardizes the interface layout of the test software, avoiding the situation of messy layout of software interface controls.

[0129] (2) This software solves the problem that the display controls cannot fit on the screen due to the limited screen size when there is too much data monitored by previous testing software. In this software, control groups can be added and arranged downwards indefinitely. When the screen cannot display all of them, you can slide to view the control groups below, just like browsing a web page.

[0130] (3) The monitoring signals that are added and adjusted later can be easily inserted into any control group, avoiding the previous situation where space had to be squeezed into many UI controls and then backend code had to be written. The software's functionality can be expanded without modifying the program code.

[0131] In summary, this embodiment achieves strong decoupling between the communication protocol and software interface and the host computer software. The parameter information in the communication protocol and software interface configuration files is read only when the host computer software is running. This enables automatic parsing and configuration of the communication protocol within the software and dynamic generation of the human-machine interface. The parsed data can be flexibly combined with different controls to adjust the display according to user preferences. The granularity of the parsed data can reach single-bit. Regardless of subsequent changes in communication protocols or the addition or adjustment of software interface inputs and displays, no code modification is required, allowing for real-time interface configuration and a WYSIWYG (What You See Is What You Get) experience. This significantly increases the communicability and flexibility of the control console software. It solves the problem that host computer testing software is only applicable to a fixed, single communication protocol data format, and the display interface layout constantly needs adjustment due to different monitored signals. When the communication protocol changes, the new protocol can be modified efficiently. The system has good flexibility and high versatility, is easy to operate, greatly reduces the development and maintenance costs of the control console software, and also solves the problem of poor maintainability in traditional methods. Specific Implementation Example 2:

[0133] This embodiment provides a testing method that enables rapid configuration of communication protocols and UI interfaces, specifically including the following steps:

[0134] Step 201: The receiving protocol configuration module generates a receiving protocol save file based on the message name and message attributes entered by the user in the receiving message configuration interface, and sends it to the protocol file save module for saving.

[0135] Step 202: The sending protocol configuration module generates a sending protocol save file based on the message name and message attributes entered by the user in the sending message configuration interface, and sends it to the protocol file save module for saving.

[0136] Step 203: The UI configuration module binds the monitoring signals and the data in the received messages according to the monitoring signals and the expected display effect of the interface. It can freely and flexibly configure each display control, generate an interface layout protocol save file, and send it to the protocol file save module for saving.

[0137] Step 204: Protocol file saving module, reads the received protocol saving file, sends the protocol saving file, and the interface layout protocol saving file;

[0138] Step 205: The UI generation module reads the receiving protocol, sending protocol, and interface layout protocol from the protocol file saving module to generate the system test interface.

[0139] Step 206: The data generation module sends the parameters entered by the user on the system test interface into a sending frame according to the sending protocol and sends it to the product under test.

[0140] Step 207: The receiving data parsing module parses the response frame sent back by the product under test according to the receiving protocol, displays the parsed data information on the system test interface, and updates the data information on the system test interface in real time.

[0141] In summary, this embodiment achieves strong decoupling between the communication protocol and software interface and the host computer software. The parameter information in the communication protocol and software interface configuration files is read only when the host computer software is running. This enables automatic parsing and configuration of the communication protocol within the software and dynamic generation of the human-machine interface. The parsed data can be flexibly combined with different controls to adjust the display according to user preferences. The granularity of the parsed data can reach single-bit. Regardless of subsequent changes in communication protocols or the addition or adjustment of software interface inputs and displays, no code modification is required, allowing for real-time interface configuration and a WYSIWYG (What You See Is What You Get) experience. This significantly increases the communicability and flexibility of the control console software. It solves the problem that host computer testing software is only applicable to a fixed, single communication protocol data format, and the display interface layout constantly needs adjustment due to different monitored signals. When the communication protocol changes, the new protocol can be modified efficiently. The system has good flexibility and high versatility, is easy to operate, greatly reduces the development and maintenance costs of the control console software, and also solves the problem of poor maintainability in traditional methods. Specific Implementation Example 3:

[0143] This embodiment provides a protocol-configurable data frame sending and receiving method, the process of which can be found in [link to documentation]. Figure 7 ;

[0144] Step 1: After the test system initializes global variables, it reads the parameters in the sending protocol file and dynamically generates a sending protocol button; it reads the receiving protocol and interface configuration protocol to generate a test main interface display control group and establishes a connection between the display control group and the parsed data storage set.

[0145] Step 2: The test system maps the underlying hardware interface according to the communication device and communication method selected by the user. The program opens a main thread and a sub-thread. The main thread is responsible for the human-computer interaction work of software control and interface update, while the sub-thread is responsible for driving the underlying hardware to perform data reading and writing communication work and receiving and parsing data.

[0146] Step 3: The main thread of the sending protocol configuration module waits for the user to trigger the sending protocol button, generates a parameter binding interface according to the sending protocol, inputs the values ​​of each parameter control, and after the input is completed and the settings are confirmed, it assembles a frame of data to be sent according to the starting position and length of each parameter, data type, and frame type information.

[0147] Step 4: Based on the general protocol information in the transmission protocol file, determine whether the current frame is a single transmission frame or a periodic transmission frame.

[0148] Step 5: If it is a periodically transmitted frame, update the data in the acquisition frame transmission set with the data of the frame to be transmitted; if it is a single transmitted frame, determine whether it is a radar parameter binding frame.

[0149] Step 6: Based on the general protocol information in the transmission protocol file, determine whether the current transmission frame data is a radar parameter binding frame;

[0150] Step 7: If it is radar parameter binding frame data, then save the frame data to be sent into the radar parameter binding transmission set;

[0151] If it is not a radar parameter binding frame, the frame data to be sent is sent to the product under test through the hardware board mapped by the hardware interface layer.

[0152] Step 8: The sub-thread continuously checks whether there is data written in the radar parameter binding and sending set. If there is data written, it is split into several frames as needed and sent to the product under test through the hardware board mapped by the hardware interface layer. After sending, the radar parameter binding and sending set is cleared.

[0153] Step 9: If there is no data in the radar parameter binding and transmission set, check if there is data written in the acquisition frame transmission set. If there is data written, insert the sequence code and check value at the appropriate position according to the transmission protocol, and send it to the product under test through the hardware board mapped by the hardware interface layer.

[0154] Step 10: The receiving protocol configuration module queries the hardware board receiving buffer mapped by the hardware interface layer. If data is received, the frame length and verification are checked, and a frame of data that meets the requirements is sent to the data parsing function for processing.

[0155] Step 11: In the data parsing function, the data frame is parsed according to the starting position and length of each parameter, and then converted into the data format corresponding to each parameter as specified by the protocol. The parsed data is then stored in a file or database according to the receiving protocol.

[0156] Step 12: After parsing the data, the display controls are allocated according to the interface layout protocol, and the main thread is returned to update the display control groups of the UI interface.

[0157] Step 13: Determine if the user confirms to stop communication. If not, return to step 8 and continue the loop. Otherwise, exit the send / receive sub-thread and end the communication process.

[0158] In summary, this embodiment achieves strong decoupling between the communication protocol and software interface and the host computer software. The parameter information in the communication protocol and software interface configuration files is read only when the host computer software is running. This enables automatic parsing and configuration of the communication protocol within the software and dynamic generation of the human-machine interface. The parsed data can be flexibly combined with different controls to adjust the display according to user preferences. The granularity of the parsed data can reach single-bit. Regardless of subsequent changes in communication protocols or the addition or adjustment of software interface inputs and displays, no code modification is required, allowing for real-time interface configuration and a WYSIWYG (What You See Is What You Get) experience. This significantly increases the communicability and flexibility of the control console software. It solves the problem that host computer testing software is only applicable to a fixed, single communication protocol data format, and the display interface layout constantly needs adjustment due to different monitored signals. When the communication protocol changes, the new protocol can be modified efficiently. The system has good flexibility and high versatility, is easy to operate, greatly reduces the development and maintenance costs of the control console software, and also solves the problem of poor maintainability in traditional methods. Specific Implementation Example 4:

[0160] This embodiment provides a general-purpose testing software system and platform that enables rapid configuration of communication protocols and UI interfaces, specifically including: UI generation module 1, receiving protocol configuration module 2, UI configuration module 3, sending protocol configuration module 4, protocol file saving module 5, sending data generation module 6, receiving data parsing module 7, and hardware underlying module 8.

[0161] Its overall architecture is as follows:

[0162] The UI generation module 1, the receiving protocol configuration module 2, the UI configuration module 3, the sending protocol configuration module 4, the protocol file saving module 5, the sending data generation module 6, the receiving data parsing module 7, and the hardware underlying module 8 are connected into a whole.

[0163] When the test system is built for the first time, users only need to enter the name of the message and select the corresponding attributes of the message by entering the message name through the keyboard or mouse on the message sending or receiving configuration interface. The receiving protocol save file can be generated by receiving protocol configuration module 2, and the sending protocol save file can be generated by sending protocol configuration module 4. Software users can design and adjust the signals they want to monitor according to their own usage habits, and arbitrarily choose drawing controls or text display controls to bind the signals they want to monitor to the data in the received message. The various controls on the test interface can be freely and flexibly configured through interface UI configuration module 3 and an interface UI save file can be generated for future use when generating test interfaces.

[0164] After the test system runs, it reads the UI file saved in the protocol file saving module 5, automatically generates the software test interface through the UI generation module 1, completes the data binding of UI controls, reads the sending protocol from the protocol file saving module 5, generates the parameter binding interface in the sending data generation module 6 to complete the framing of the sending data, reads the receiving protocol from the protocol file saving module 5, and completes the parsing of the received data and the data update of the corresponding UI controls on the test interface in the receiving data parsing module 7.

[0165] The data generation module 6 and the data parsing module 7 communicate with the product under test through the underlying hardware module 8.

[0166] When the communication protocol of the product under test changes, the entire test software can be modified simply by regenerating the protocol file in the protocol configuration interface according to the new protocol through the receiving protocol configuration module 2, sending protocol configuration module 4, and interface UI configuration module 3.

[0167] The following details the three types of protocol files in the Send Protocol Configuration Module 4, Receive Protocol Configuration Module 2, and Interface UI Configuration Module 3. These files are stored as XML files in the "Send Protocol", "Receive Protocol", and "Interface UI Layout and Generation" folders under the program project directory.

[0168] (1) Sending Protocol Configuration Module:

[0169] The sending protocol XML file consists of three parts:

[0170] General protocol information, basic protocol, and radar parameter protocol, format as follows: Figure 3 As shown;

[0171] Part One: General Protocol Information

[0172] The general protocol information is used to specify whether the current transmission protocol is periodic or single-transmission, checksum byte position, sequence code position, endianness, whether it includes radar parameter protocol, how many bytes are combined into one frame for transmission, maximum number of radar units to be bound, number of sub-protocols in the radar parameter protocol, and total number of bytes in the radar parameter protocol section. The specific meanings of each attribute are as follows:

[0173] (1) SendInterval: Periodic / single transmission flag (0: single transmission, 1: periodic transmission)

[0174] (2) CheckPosition: The starting byte of the checksum in the transmission protocol (applicable to frame protocols that transmit periodically).

[0175] (3) XuLieMaPosition: The start position byte of the sequence code in the transmission protocol (applicable to frame protocols that transmit periodically).

[0176] (4) Direction: The order in which high and low bytes are sent in the communication protocol (0: low byte first, 1: high byte first).

[0177] (5) IsRadarParameter: Whether it contains a radar parameter type frame (0: does not contain radar parameter type, 1: contains radar parameter type)

[0178] (6) HowManyByteToDevide: How many bytes are combined into one frame for transmission (applicable to parameter binding frames that need to be split into several frames for transmission);

[0179] (7)RadarMaxNum: Number of radar parameter types (maximum number of radars that can be installed, applicable to parameter binding frames)

[0180] (8)RadarFrameNum: The number of sub-protocols contained in the radar parameter type (template).

[0181] (9)RadarFrameTotalByte: The number of bytes in the radar parameter type (template).

[0182] Part Two: Basic Agreement

[0183] The basic protocol is the main protocol part of the radar, and each of its clauses...<ControlProperty...... / > Each represents a sub-protocol. The host computer software will automatically generate corresponding parameter input controls on the interface based on the attributes in each sub-protocol;

[0184] The entity protocol attributes include: parameter name, parameter start position, length, endianness, control generation type, data value type, parsing processing method, scale, data value unit, data value decimal places, maximum and minimum values, etc. The specific meanings of its main attributes are as follows:

[0185] (1) frameNum: Entity protocol sequence number

[0186] (2) frameName: Entity protocol name, configured by the host computer program to be displayed as the signal name next to the UI control.

[0187] (3) frameType: Entity protocol type, the meaning of which is as follows:

[0188] 0 = "Number type", the host computer program configures it as a TextBox control.

[0189] 1 = "Enumeration type", the host computer program is configured as a ComboBox control (Note 1)

[0190] 2 = "Constant type", a fixed hexadecimal value in the protocol (applicable to frame headers, frame tails, command words, etc.)

[0191] 3 = "Pad with 0 type", pad with 0 when splicing the protocol

[0192] 4 = "Check type", this item is the checksum when splicing the protocol

[0193] 5 = "Repeat type", repeat the existing entity protocol segment before when splicing the protocol

[0194] 6 = "Sequence code", this item is the sequence code when splicing the protocol

[0195] 7 = "Radar parameter type", insert the radar parameter protocol here when splicing the protocol (Note 2)

[0196] Among them: when frameType = 1, the next-level XML appears under <ControlProperty...... / > to represent the SelectItem in the ComboBox control. For example:

[0197] <SelectItem value = "0" key = "No target found" / >

[0198] <SelectItem value = "1" key = "Target found" / >

[0199] Among them: the radar parameter protocol radarParameter_templet has only 0, 1, 2, 3

[0200] (4) dataType: Entity protocol data type, the specific meanings are as follows:

[0201] 0 = "Less than 8 bits"

[0202] 1 = "8-bit unsigned"

[0203] 2 = "8-bit signed"

[0204] 3 = "16-bit unsigned"

[0205] 4 = "16-bit signed"

[0206] 5 = "32-bit unsigned"

[0207] 6 = "32-bit signed"

[0208] 7 = "Float"

[0209] (5) frameDefault: The default parameter value of the TextBox control configured by the host computer program.

[0210] (6) frameMax: Maximum value (used for input parameter limit judgment and the maximum limit displayed by the Chart drawing control) (7) frameMin: Minimum value (used for input parameter limit judgment and the minimum limit displayed by the Chart drawing control) (8) frameRatio: Numerical scale

[0211] (9) frameBias: Numerical offset

[0212] (10)frameUint: Used to display the unit next to the TextBox control in the UI interface.

[0213] (11) frameConstant: Hexadecimal constant data (used in conjunction with frameType=2)

[0214] (12) frameDuplicate: Use this value as the entity protocol sequence number to copy an existing entity protocol (in conjunction with frameType=5).

[0215] (13)frameMinBit: The minimum bit of data used when the entity protocol is less than 1 byte.

[0216] (14)frameMaxBit: The maximum number of bits used for data when the entity protocol is less than 1 byte.

[0217] Part Three: Radar Parameter Protocol

[0218] The radar parameter protocol is designed to simplify the configuration process. In parameter binding protocols, there are often situations where parameters for several radars need to be loaded simultaneously. If the parameters for each radar are entered into the basic protocol, the software interface would become too cumbersome. Since the protocol part of each radar parameter is the same, the "radar parameter protocol" is abstracted. Only one radar parameter protocol needs to be entered as a template, and the host computer software will embed this radar parameter protocol part into the basic protocol during processing, which simplifies the protocol configuration to the greatest extent.

[0219] The protocol attributes are similar to those of the basic protocol, and will not be described in detail here.

[0220] Figure 3 It is a parameter binding interface automatically generated according to the radar parameter protocol.

[0221] (2) Receive Protocol Configuration Module:

[0222] Figure 5This is the receiving protocol configuration interface. The parameter settings are similar to those in the sending protocol configuration interface, but with the addition of data display control options. After each sub-protocol data is parsed, you can choose to display it using a Chart control, a TextBox control, both controls, or no display. You can specify the data display method according to your needs.

[0223] The XML file for the receiving protocol is similar to that for the transmitting protocol, except that it lacks a radar parameter protocol section. Additionally, several attributes have been added to the basic protocol section.

[0224] (1) TextBoxGroupNumber: Represents the serial number of the TextBoxGroup control group.

[0225] (2) ChartGroupNumber: Represents the serial number of the ChartGroup control group.

[0226] (3) UserControlType: Specifies which control is used to display the parsed data (0: displayed as a TextBox control, 1: displayed as a drawing control, 2: displayed using both TextBox and drawing controls, 3: data is not displayed).

[0227] (3) Interface UI configuration module:

[0228] The interface layout protocol is located below the receiving protocol configuration interface (e.g., Figure 5 As shown), multiple controls of the same type can be freely combined into control groups (TextBoxGroup, ChartGroup) to further configure and optimize the interface layout. Each control group can be flexibly arranged in any position on the test interface.

[0229] Figure 2 The software testing interface is based on Figure 5 The interface layout configuration is automatically generated.

[0230] The advantages of this interface layout configuration feature are as follows:

[0231] (1) It solves the problem that the previous test program still needed to consider the design of the software interface, and standardizes the interface layout of the test software, avoiding the situation of messy layout of software interface controls.

[0232] (2) This software solves the problem that the display controls cannot fit on the screen due to the limited screen size when there is too much data monitored by previous testing software. In this software, control groups can be added and arranged downwards indefinitely. When the screen cannot display all of them, you can slide to view the control groups below, just like browsing a web page.

[0233] (3) The monitoring signals that are added and adjusted later can be easily inserted into any control group, avoiding the previous situation where space had to be squeezed into many UI controls and then backend code had to be written. The software's functionality can be expanded without modifying the program code.

[0234] After the generalized testing system program starts (equivalent to variable initialization), it reads the protocol file, automatically configures the UI interface, maps the interface of the hardware interface layer, and starts the send and receive sub-threads according to the protocol file saving module 5 generated by the user-set send protocol configuration module 4, receive protocol configuration module 2, and UI configuration module 3.

[0235] The flowchart of the host computer software initialization is as follows: Figure 6 As shown.

[0236] Furthermore, this embodiment also provides a protocol-configurable data frame transmission and reception process;

[0237] The implementation of the configurable data transmission generation module (6) and data reception parsing module (7) of the communication protocol is achieved through the main thread and sub-thread to send and receive data.

[0238] See Figure 7 Specifically, it includes the following steps:

[0239] Step 1: After the host computer software initializes the global variables, it reads the parameters from the sending protocol file from the local hard disk and dynamically generates each sending protocol button. It reads the receiving protocol and the interface configuration protocol to generate each display control group on the test main interface. It then establishes a connection between each control group and the parsed data storage set through delegation.

[0240] Step 2: The host computer software maps the underlying hardware interface according to the communication device and communication method selected by the user. The program opens a main thread and a sub-thread. The main thread is responsible for the human-computer interaction work of software control and interface update, while the sub-thread is responsible for driving the underlying hardware to perform data reading and writing communication work and receiving and parsing data.

[0241] Step 3: The main thread waits for the user to click the send protocol button, generates a parameter binding interface according to the send protocol, inputs the values ​​of each parameter control, and after the input is completed and the settings are confirmed, it assembles a frame of data to be sent according to the starting position and length of each parameter, data type, frame type and other information.

[0242] Step 4: Determine whether the current frame is a single-transmission frame or a periodic-transmission frame based on the SendInterval attribute in the transmission protocol file;

[0243] Step 5: If it is a periodic transmission frame, update the data in the acquisition frame transmission set with the data of the frame to be transmitted; if it is a single transmission frame, determine whether it is a radar parameter binding frame.

[0244] Step 6: Determine whether the current frame is a radar parameter binding frame based on the IsRadarParameter attribute in the transmission protocol file;

[0245] Step 7: If it is a radar parameter binding frame, save the data to be sent into the radar parameter binding transmission set.

[0246] If it is not a radar parameter binding frame, the frame of data to be sent will be sent through the hardware board mapped by the hardware interface layer;

[0247] Step 8: Meanwhile, the sub-thread continuously checks whether there are any numbers in the radar parameter binding and sending set. If there is data written, it is split into several frames as needed and sent sequentially through the hardware board mapped by the hardware interface layer. After sending, the radar parameter binding and sending set is cleared to zero.

[0248] Step 9: If there is no data in the radar parameter binding transmission set, check if there is data in the acquisition frame transmission set. If there is data, insert the sequence code and check value at the appropriate position according to the transmission protocol, and then send it through the hardware board mapped by the hardware interface layer.

[0249] Step 10: Query the hardware board receive buffer mapped by the hardware interface layer. If data is received, perform frame length and verification. Send a frame of data that meets the requirements to the data parsing function for processing.

[0250] Step 11: In the data parsing function, the data frame is parsed according to the starting position and length of each parameter, and then converted into the data format corresponding to each parameter as specified by the protocol. The parsed data is then stored in a file or database according to the receiving protocol.

[0251] Step 12: After parsing the data, the display controls are allocated according to the interface layout protocol, and the main thread is returned to update the display control groups of the UI interface.

[0252] Step 13: Determine if the user confirms to stop communication. If not, return to step 8 and continue the loop. Otherwise, exit the send / receive sub-thread and end the communication process.

[0253] In summary, this embodiment achieves strong decoupling between the communication protocol and software interface and the host computer software. The parameter information in the communication protocol and software interface configuration files is read only when the host computer software is running. This enables automatic parsing and configuration of the communication protocol within the software and dynamic generation of the human-machine interface. The parsed data can be flexibly combined with different controls to adjust the display according to user preferences. The granularity of the parsed data can reach single-bit. Regardless of subsequent changes in communication protocols or the addition or adjustment of software interface inputs and displays, no code modification is required, allowing for real-time interface configuration and a WYSIWYG (What You See Is What You Get) experience. This significantly increases the communicability and flexibility of the control console software. It solves the problem that host computer testing software is only applicable to a fixed, single communication protocol data format, and the display interface layout constantly needs adjustment due to different monitored signals. When the communication protocol changes, the new protocol can be modified efficiently. The system has good flexibility and high versatility, is easy to operate, greatly reduces the development and maintenance costs of the control console software, and also solves the problem of poor maintainability in traditional methods.

[0254] The above description is merely a preferred embodiment of this specification and is not intended to limit this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of protection of this specification.

Claims

1. A testing system capable of rapidly configuring communication protocols and UI interfaces, characterized in that, include: UI generation module (1), receiving protocol configuration module (2), UI configuration module (3), sending protocol configuration module (4), protocol file saving module (5), sending data generation module (6), receiving data parsing module (7); The receiving protocol configuration module (2) is used to generate a receiving protocol save file based on the message name and message attributes entered by the user in the receiving message configuration interface, and then transmit it to the protocol file save module (5) for saving. The sending protocol configuration module (4) is used to generate a sending protocol save file based on the message name and message attributes entered by the user in the sending message configuration interface, and then send it to the protocol file save module (5) for saving. The UI configuration module (3) is used to bind the monitoring signal and the data in the received message according to the monitoring signal and the expected display effect of the interface, freely and flexibly configure each display control, generate the interface layout protocol save file, and send it to the protocol file save module (5) for saving. The protocol file saving module (5) is used to store the received protocol saving file, the sent protocol saving file, and the interface layout protocol saving file; The UI generation module (1) is used to read the receiving protocol, sending protocol, and interface layout protocol from the protocol file saving module (5) to generate the system test interface; The data generation module (6) is used to package the protocol parameters input by the user in the system test interface into a sending frame according to the sending protocol and send it to the product under test. The receiving data parsing module (7) is used to parse the response frame returned by the product under test according to the receiving protocol, display the parsed data information on the system test interface, and update the data information of the system test interface in real time.

2. The system according to claim 1, characterized in that, When the communication protocol of the product under test changes, the receiving protocol configuration module (2), the sending protocol configuration module (4), and the interface UI configuration module (3) regenerate the receiving protocol save file, the sending protocol save file, and the interface layout protocol save file according to the new communication protocol received by the protocol configuration interface, thereby modifying the entire test software.

3. The system according to claim 1, characterized in that, The receiving protocol configuration module (2), the sending protocol configuration module (4), and the interface UI configuration module (3) are respectively connected to the protocol file saving module (5), and the protocol file saving module (5) is connected to the interface UI generation module (1); The data generation module (6) and the data parsing module (7) are respectively connected to the UI generation module (1).

4. The system according to claim 1, characterized in that, The testing system also includes a hardware underlying module (8), wherein the data transmission generation module (6) and the data reception parsing module (7) communicate and interact with the product under test through the hardware underlying module (8).

5. The system according to claim 1, characterized in that, The transmission protocol includes: general protocol information, basic protocol, and radar parameter protocol; The general protocol information is used to specify the current transmission protocol periodic transmission / single transmission, check byte position, sequence code position, endianness, whether it includes radar parameter protocol, number of bytes to be assembled into a frame, maximum number of radar parts to be bound, number of sub-protocols in radar parameter protocol, and total number of bytes in radar parameter protocol part.

6. The system according to claim 5, characterized in that, The attributes of the basic protocol include: parameter name, parameter start position, length, endianness, control generation type, data value type, parsing processing method, scale, data value unit, number of decimal places in the data value, maximum value and minimum value; The radar parameter protocol attributes are the same as the basic protocol attributes.

7. The system according to claim 1, characterized in that, The interface layout protocol allows multiple controls of the same type to be freely combined into a control group, configuring and optimizing the interface layout.

8. The system according to claim 1, characterized in that, The receiving protocol configuration interface also includes data display control options; wherein the data display control options include: displaying a Chart control, displaying a TextBox control, displaying both controls, and not displaying either.

9. A testing method for rapidly configuring communication protocols and UI interfaces, applied to the system according to any one of claims 1 to 8, characterized in that, include: The receiving protocol configuration module generates a receiving protocol save file based on the message name and message attributes entered by the user in the receiving message configuration interface, and sends it to the protocol file save module for saving. The sending protocol configuration module generates a sending protocol save file based on the message name and message attributes entered by the user in the sending message configuration interface, and sends it to the protocol file save module for saving. The UI configuration module binds the monitoring signals and the data in the received messages according to the monitoring signals and the expected display effect of the interface. It can freely and flexibly configure each display control, generate an interface layout protocol save file, and send it to the protocol file save module for saving. The protocol file saving module reads and receives protocol files, sends protocol files, and saves interface layout protocol files. The UI generation module reads the receiving protocol, sending protocol, and interface layout protocol from the protocol file saving module to generate the system test interface; The data generation module takes the parameters entered by the user on the system test interface, packages them into a sending frame according to the sending protocol, and sends it to the product under test. The receiving data parsing module parses the response frames sent back by the product under test according to the receiving protocol, displays the parsed data information on the system test interface, and updates the data information on the system test interface in real time.

10. A protocol-configurable data frame transmission and reception method, used to implement the system according to any one of claims 1 to 8, characterized in that, include: Step 1: After the test system initializes global variables, it reads the parameters from the sending protocol file and dynamically generates a sending protocol button. Read the receiving protocol and interface configuration protocol to generate a test main interface display control group, and establish a connection between the display control group and the parsed data storage set; Step 2: The test system maps the underlying hardware interface according to the communication device and communication method selected by the user. The program opens a main thread and a sub-thread. The main thread is responsible for the human-computer interaction work of software control and interface update, while the sub-thread is responsible for driving the underlying hardware to perform data reading and writing communication work and receiving and parsing data. Step 3: The main thread of the sending protocol configuration module waits for the user to trigger the sending protocol button, generates a parameter binding interface according to the sending protocol, inputs the values ​​of each parameter control, and after the input is completed and the settings are confirmed, it assembles a frame of data to be sent according to the starting position and length of each parameter, data type, and frame type information. Step 4: Based on the general protocol information in the transmission protocol file, determine whether the current frame is a single transmission frame or a periodic transmission frame. Step 5: If it is a periodic frame transmission, then update the data in the collection frame transmission set with the data of the frame to be transmitted; If it is a single-transmission frame, determine whether it is a radar parameter binding frame; Step 6: Based on the general protocol information in the transmission protocol file, determine whether the current transmission frame data is a radar parameter binding frame; Step 7: If it is radar parameter binding frame data, then save the frame data to be sent into the radar parameter binding transmission set; If it is not a radar parameter binding frame, the frame data to be sent is sent to the product under test through the hardware board mapped by the hardware interface layer. Step 8: The sub-thread continuously checks whether there is data written in the radar parameter binding and sending set. If there is data written, it is split into several frames as needed and sent to the product under test through the hardware board mapped by the hardware interface layer. After sending, the radar parameter binding and sending set is cleared. Step 9: If there is no data in the radar parameter binding and transmission set, check if there is data written in the acquisition frame transmission set. If there is data written, insert the sequence code and check value at the appropriate position according to the transmission protocol, and send it to the product under test through the hardware board mapped by the hardware interface layer. Step 10: The receiving protocol configuration module queries the hardware board receiving buffer mapped by the hardware interface layer. If data is received, the frame length and verification are checked, and a frame of data that meets the requirements is sent to the data parsing function for processing. Step 11: In the data parsing function, the data frame is parsed according to the starting position and length of each parameter, and then converted into the data format corresponding to each parameter as specified by the protocol. The parsed data is then stored in a file or database according to the receiving protocol. Step 12: After parsing the data, the display controls are allocated according to the interface layout protocol, and the main thread is returned to update the display control groups of the UI interface.

Images