A configuration-based embedded software interface data frame parsing method

Abstract

The present application relates to a kind of based on the embedded software interface data frame analysis method of configuration, belong to embedded software interface test technical field.The present application supports rich field type.By providing 9 simple fields and 5 compound field type definitions, interface protocol configuration requirements can be basically covered;Support complex structure interface protocol configuration and processing.By providing fixed-length array, variable-length array, field set, bit set, communication command and other field types, it supports variable-length and nested complex structure communication command frame configuration and automatic analysis;With good versatility and applicability.Interface protocol is described by XML file, decouples specific interface protocol and interface data frame analysis process, enhances the versatility and adaptability of interface data frame analysis method.

Description

Technical Field

[0001] This invention belongs to the field of embedded software interface testing technology, specifically relating to a configuration-based embedded software interface data frame parsing method. Background Technology

[0002] In embedded software testing, interface testing plays a crucial role as a key test type. Statistics show that software defects directly or indirectly caused by interface issues account for approximately 30% of all embedded system defects. Embedded software interface testing simulates the interaction between external devices or systems and the software under test, verifying the consistency, correctness, and fault tolerance of the embedded software interface protocol.

[0003] The general method for embedded software interface testing is to connect an industrial control computer or commercial computer to the embedded system via an interface device (such as a serial port, network port, or bus), use interface testing tools to send test data to the embedded software under test, and then observe whether the behavior of the embedded software is consistent with expectations; or by collecting the output data of the embedded software, performing data analysis, and judging the working status of the embedded software. Embedded software is characterized by diverse interface protocol types, complex structures, and significant differences between different types of embedded software interfaces. Therefore, embedded software interface testing techniques and methods still face the following challenges:

[0004] (1) Existing embedded software interface testing tools mainly address the problem of generating and sending data in bytes based on interface protocol description documents. They do not have automatic interface data parsing and response functions. For example, widely used serial port and network debugging assistants can send and receive interface data, but manual comparison of interface data and interface protocol is still required to understand the meaning of sending and receiving data.

[0005] (2) Existing embedded software interface testing tools only support the parsing of communication command frames for simple fixed-length interface protocols, and do not support the processing of variable-length or nested interface protocols, thus failing to fully cover interface testing requirements. For complex interface protocols, it is necessary to customize and develop corresponding embedded software interface testing tools or platforms, thereby increasing testing time and manpower costs, and potentially affecting the overall progress of embedded software testing. Summary of the Invention

[0006] (a) Technical problems to be solved

[0007] The technical problem this invention aims to solve is: how to achieve automatic data frame parsing based on configuration, support complex structure interface protocol processing such as variable length or nested fields, and provide a solution for automatic response of interface data and test data analysis in embedded software interface testing.

[0008] (II) Technical Solution

[0009] To address the aforementioned technical problems, this invention provides a configuration-based embedded software interface data frame parsing method, comprising two stages: constructing a data frame parsing model and parsing the data frame. In the data frame parsing model construction stage, the data frame parsing model is constructed through three steps: interface protocol configuration, constructing an interface protocol model, and refining the data frame parsing model. In the data frame parsing stage, based on the data frame parsing model, the communication command frames contained in the interface data frames are parsed out, including the command frame name and the values ​​of each component field.

[0010] Preferably, the method specifically includes the following steps:

[0011] Step 1: Interface Protocol Configuration

[0012] First, an embedded software interface protocol logical model is constructed to implement interface protocol configuration, extract data frame parsing models, and parse data frames. The embedded software interface protocol logical model includes three types of fields: simple fields, composite fields, and specification fields. Simple fields include nine types: bit fields, byte fields, short integer fields, integer fields, long integer fields, floating-point fields, long floating-point fields, check fields, and hexadecimal fields. Composite fields include five types: fixed-length arrays, variable-length arrays, field sets, bit sets, and communication commands. Specification fields are used to extract data frame parsing models and parse data frames, but are not directly used for interface protocol configuration. Interface protocol configuration refers to describing the embedded software interface protocol based on the simple and composite fields using Extensible Markup Language (XML).

[0013] Step 2: Constructing the interface protocol model

[0014] The interface protocol model is constructed by loading the interface protocol configuration, that is, loading a series of XML configuration files. Since each communication command corresponds to an XML configuration file, and the interface protocol model is built based on a series of communication commands, the interface protocol model is a collection of communication command models.

[0015] Step 3: Refine the data frame parsing model

[0016] Extracting the data frame parsing model is based on the second step, and involves refining the interface protocol model, i.e., a set of communication command models C = {C0, C1, ..., C...}. n The data is reduced to a unified data frame parsing model M = (L, S), where the field list L = {i0, i1, ..., i...} p The set of sub-analytic models S = {M0, M1, ..., M} q}, M k For the sub-analytic model, where Ci A communication command consisting of a set of fields, 0≤i≤n, i0,i1,…,i p For simple fields or set fields, 0 ≤ k ≤ q;

[0017] Step 4: Parse the data frame

[0018] Parsing data frames is based on the data frame parsing model M = (L, S) extracted in the third step, and the received interface data frames F = B0B1B2…B n The data frame is parsed to identify the communication command corresponding to the interface data frame, as well as the values ​​of each constituent field, including B. i It is single-byte data.

[0019] The present invention also provides a system for implementing the method.

[0020] The present invention also provides an embedded software interface testing method based on the above method.

[0021] The present invention also provides an embedded software interface testing tool based on the method described above.

[0022] (III) Beneficial Effects

[0023] (1) Supports a wide range of field types. By providing nine simple fields, such as bit field, byte field, short integer field, integer field, long integer field, floating-point field, long floating-point field, check field, and hexadecimal field, and five composite field types, such as fixed-length array, variable-length array, field set, bit set, and communication command, it can basically cover the interface protocol configuration requirements.

[0024] (2) Supports configuration and processing of complex interface protocols. By providing field types such as fixed-length arrays, variable-length arrays, field sets, bit sets, and communication commands, it supports the configuration and automatic parsing of complex communication command frames with variable length and nesting.

[0025] (3) It has good versatility and applicability. By describing the interface protocol through an XML file, the specific interface protocol and the interface data frame parsing process are decoupled, which enhances the versatility and adaptability of the interface data frame parsing method. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of the embedded software interface data frame parsing method of the present invention;

[0027] Figure 2 This is the embedded software interface protocol logic model of the present invention;

[0028] Figure 3 This is an example diagram of a servo system interface protocol according to the present invention;

[0029] Figure 4 This is a servo system interface protocol model of the present invention;

[0030] Figure 5 This is a data frame parsing model for a certain servo system according to the present invention. Detailed Implementation

[0031] To make the objectives, contents, and advantages of the present invention clearer, the specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples.

[0032] The schematic diagram of the configuration-based embedded software interface data frame parsing method provided by this invention is shown below. Figure 1 As shown, the embedded software interface data frame parsing method comprises two stages: constructing a data frame parsing model and parsing the data frame. In the data frame parsing model construction stage, the model is built through three steps: interface protocol configuration, constructing the interface protocol model, and refining the data frame parsing model. In the data frame parsing stage, based on the data frame parsing model, the communication command frames contained in the interface data frames are parsed out, including the command frame name and the values ​​of each component field. The specific implementation steps of the embedded software interface data frame parsing method are detailed below.

[0033] Step 1: Interface Protocol Configuration

[0034] First, an embedded software interface protocol logic model is constructed to implement interface protocol configuration, refine the data frame parsing model, and parse data frames, such as... Figure 2 As shown, the embedded software interface protocol logical model includes three types of fields: simple fields, composite fields, and specification fields. Simple fields include nine types: bit fields, byte fields, short integer fields, integer fields, long integer fields, floating-point fields, long floating-point fields, check fields, and hexadecimal fields. Composite fields include five types: fixed-length arrays, variable-length arrays, field sets, bit sets, and communication commands. Specification fields are specifically used for refining the data frame parsing model and parsing data frames, and are not directly used for interface protocol configuration. Interface protocol configuration refers to describing the embedded software interface protocol (communication command frames) using Extensible Markup Language (XML) based on the above-mentioned simple and composite fields. The following describes the various field definition methods and field definition constraints in detail.

[0035] (1) Bit field

[0036] The bit field is used to describe bit data in the interface protocol. Bit field definition method: The corresponding XML tag for the bit field is... <bititem>The attributes include id (field identifier), name (field name), length (field length), defaultValue (field default value), and description (field description).

[0037] Bit field definition constraints: Bit fields are simple fields and cannot contain any field type, i.e. <bititem>No sub-tags can be defined within a tag; furthermore, bit fields must be defined within a bit set, i.e., the tag. <bititem>Must be used as a label <bitcollection>It must be defined by its child tags, and cannot be defined independently.

[0038] (2) Byte field

[0039] Byte fields are used to describe byte data in the interface protocol, including signed and unsigned types, representing a character or integer of length 1 byte. Byte field definition method: The corresponding XML tags for signed and unsigned byte fields are respectively... <byteitem>and <ubyteitem>The attributes include id (field identifier), name (field name), length (field length), identified (whether the field is identified), defaultValue (field default value), and description (field description).

[0040] Byte field definition constraints: Byte fields are simple fields and cannot contain any field type, i.e. <byteitem>or <ubyteitem>No child tags can be defined within a tag.

[0041] (3) Short integer field

[0042] Short integer fields are used to describe short integer data in the interface protocol. They include both signed and unsigned types, representing integers of 2 bytes in length. The definition method for short integer fields is as follows: the corresponding XML tags for signed and unsigned short integer fields are... <shortitem>and <ushortitem>The attributes include id (field identifier), name (field name), length (field length), identified (whether the field is identified), defaultValue (field default value), and description (field description).

[0043] Short integer field definition constraints: Short integer fields are simple fields and cannot contain any field type, i.e. <shortitem>or <ushortitem>No child tags can be defined within a tag.

[0044] (4) Integer field

[0045] Integer fields are used to describe integer data in the interface protocol, including both signed and unsigned types, representing 4-byte integers. Integer field definition method: The corresponding XML tags for signed and unsigned integer fields are respectively... <intitem>and <uintitem>The attributes include id (field identifier), name (field name), length (field length), identified (whether the field is identified), defaultValue (field default value), and description (field description).

[0046] Integer field definition constraints: Integer fields are simple fields and cannot contain any field type, i.e. <intitem>or <uintitem>No child tags can be defined within a tag.

[0047] (5) Long integer field

[0048] Long integer fields are used to describe long integer data in the interface protocol, including both signed and unsigned types, representing integers of 8 bytes in length. Long integer field definition methods: The corresponding XML tags for signed and unsigned long integer fields are as follows: <longitem>and <ulongitem>The attributes include id (field identifier), name (field name), length (field length), identified (whether the field is identified), defaultValue (field default value), and description (field description).

[0049] Long integer field definition constraints: Long integer fields are simple fields and cannot contain any field type, i.e. <longitem>or <ulongitem>No child tags can be defined within a tag.

[0050] (6) Floating-point field

[0051] The floating-point field is used to describe floating-point numbers in the interface protocol, representing a 4-byte floating-point number. The floating-point field is defined as follows: the corresponding XML tag for the floating-point field is... <floatitem>The attributes include id (field identifier), name (field name), length (field length), defaultValue (field default value), and description (field description).

[0052] Floating-point field definition constraints: Floating-point fields are simple fields and cannot contain any field type, i.e. <floatitem>No child tags can be defined within a tag.

[0053] (7) Long floating-point field

[0054] The long floating-point field is used to describe high-precision floating-point numbers in the interface protocol, representing a floating-point number with a length of 8 bytes. The long floating-point field is defined as follows: The corresponding XML tag for the long floating-point field is... <doubleitem>The attributes include id (field identifier), name (field name), length (field length), defaultValue (field default value), and description (field description).

[0055] Long floating-point field definition constraints: Long floating-point fields are simple fields and cannot contain any field type, i.e. <doubleitem>No child tags can be defined within a tag.

[0056] (8) Validation fields

[0057] The checksum field describes the CRC data in the interface protocol. Defining the checksum field allows for automatic calculation of the CRC checksum of the data frame. The checksum field is defined using the XML tag provided. <crcitem>The attributes include id (field identifier), name (field name), length (field length), description (field description), defaultValue (field default value), algorithm (validation algorithm name), start (validation start byte), and end (validation end byte).

[0058] Validation field definition constraints: Validation fields must be simple fields and cannot contain any field type, i.e. <crcitem>No child tags can be defined within a tag.

[0059] (9) Hexadecimal field

[0060] Hexadecimal fields are used to describe hexadecimal data in the interface protocol, primarily for ease of data representation. The definition method for hexadecimal fields is as follows: The corresponding XML tag for a hexadecimal field is... <hexitem>The attributes include id (field identifier), name (field name), length (field length), identified (whether the field is identified), defaultValue (field default value), and description (field description).

[0061] Hexadecimal field definition constraints: Hexadecimal fields are simple fields and cannot contain any field type, i.e. <hexitem>No child tags can be defined within a tag.

[0062] (10) Fixed-length array

[0063] Fixed-length arrays are used to describe array data in interface protocols. The dimensions of the array are specified by the field length. Fixed-length arrays are defined using the XML tag: <itemarray>The attributes include id (field identifier), name (field name), length (field length), and description (field description).

[0064] Fixed-length array definition constraints: Fixed-length arrays are composite fields. The field itself only defines the dimensions of the array; the data type is specified by defining a simple field, i.e., by defining a label. <itemarray>The sub-tags (simple field type tags) specify the data type of the array field; the data type of a fixed-length array can only be specified through a simple field, and only one simple field can be defined.

[0065] (11) Variable-length array

[0066] Variable-length arrays are used to describe variable-length array data in the interface protocol. The dimensions of the array are determined by other simple fields (such as integer fields) in the interface protocol. Variable-length arrays are defined using the XML tag: <itemdimarray>The attributes include id (field identifier), name (field name), ref (related field id), and description (field description).

[0067] Variable-length array definition constraints: Variable-length arrays are composite fields. The dimensions of the array are determined by the associated field specified by the `ref` attribute. The data type is specified by defining a simple field, i.e., by defining a tag. <itemdimarray>The sub-tags (simple field type tags) specify the data type of the array field; the data type of a variable-length array can only be specified through a simple field, and only one simple field can be defined.

[0068] (12) Field set

[0069] Field sets are used to categorize fields in an interface protocol, grouping multiple adjacent fields together. Field sets are defined using the XML tag `<fieldset>`. <itemcollection>The attributes include id (field identifier), name (field name), and description (field description).

[0070] Field set definition constraints: Field sets can contain simple fields or composite fields, meaning they can be nested, i.e., tags. <itemcollection>You can define both simple field type sub-tags and composite field type sub-tags.

[0071] (13) Bit set

[0072] Bit sets are used to maintain bit data in the interface protocol, ensuring that multiple bit fields combine to form a complete byte of data. Bit set definition method: The corresponding XML tag for a bit set is... <bitcollection>The attributes include id (field identifier), name (field name), length (field length), and description (field description).

[0073] Bit set definition constraints: The bit set is a composite field and can only and must contain bit fields, i.e., tags. <bitcollection>Only and must define <bititem>Sub-tags.

[0074] (14) Communication commands

[0075] Communication commands describe how a set of simple or composite fields are combined to form a complete communication command. The definition method for communication commands is as follows: the corresponding XML tag for a communication command is... <requestcommand>The attributes include id (command identifier), name (command name), byteOrder (command byte order), and description (command description).

[0076] Communication command definition constraints: Communication commands belong to composite fields and can contain all simple field types and all composite field types except communication commands, i.e., tags. <requestcommand>You can define any simple field label, or you can define labels other than... <requestcommand>Any other composite field label besides the tag.

[0077] (15) Specification Fields

[0078] The specification field is specifically used for refining the data frame parsing model and parsing data frames. It primarily maintains the data frame parsing specification and is not directly used for interface protocol configuration. Specification field definition method: The corresponding XML tag for the specification field is... <discriminator>The attributes include id (command identifier), name (command name), ref (related field id), and description (command description).

[0079] Figure 3 This is an example diagram of a servo system interface protocol, where (a) is the servo system interface protocol format, and (b) and (c) are specific communication commands conforming to the communication interface protocol format. Following the above interface protocol configuration method, Figure 3 The XML configuration corresponding to the "Set Servo Working Mode" communication command in (b) is as follows:

[0080]

[0081] Figure 3 The XML configuration corresponding to the "Set Servo System Parameters" communication command in (c) is as follows:

[0082]

[0083] It should be noted that each communication command is configured using a separate XML configuration file, and each XML configuration file can only define one communication command.

[0084] Step 2: Constructing the interface protocol model

[0085] The interface protocol model is constructed by loading the interface protocol configuration, which is a series of XML configuration files. Since each communication command corresponds to an XML configuration file, and the interface protocol model is built upon a series of communication commands, it is a collection of communication command models.

[0086] In constructing the interface protocol model, the first step is to validate the XML elements in the XML configuration file, including element structure constraint validation and attribute constraint validation. Element structure constraint validation is performed based on field definition constraints; for example, a bit field cannot be defined as a child element other than a bit set. Attribute constraint validation verifies the field's attribute configuration; for example, attributes such as id (command identifier), name (command name), length (field length), and defaultValue (field default value) must be set; the length attribute value must be an integer greater than 1; the start (validation start byte) and end (validation end byte) attribute values ​​must be non-negative integers; and the id (command identifier) ​​of fields at the same level must be unique.

[0087] After validating the XML configuration file, the XML configuration file is parsed, and a corresponding entity object is created for each XML element. Following the hierarchical structure of the XML elements, a communication command model is constructed, i.e., based on... <requestcommand>The tree structure with the root node as the element, the set of communication command models is the interface protocol model. Figure 4 According to Figure 3 The communication commands shown in (b) and (c) represent the interface protocol model of a certain servo system.

[0088] Step 3: Refine the data frame parsing model

[0089] Extracting the data frame parsing model is based on the second step, "Constructing the Interface Protocol Model," and involves refining the interface protocol model, i.e., a set of communication command models C = {C0, C1, ..., C...}. n }(C i A communication command consisting of a set of fields (0 ≤ i ≤ n) is reduced to a unified data frame parsing model M = (L, S), where the field list L = {i0, i1, ..., i...} p }(i0, i1, ..., i p For simple fields or set fields), the sub-parse model set S = {M0, M1, ..., M} q }, M k This is a sub-parse model (0≤k≤q). The specific process for refining the data frame parsing model is described below:

[0090] (1) Initialize model M, let... i = 0, k = 0.

[0091] (2) If 0≤i≤n, from the communication command model set C={C0,C1,…,C n Extract a communication command model C from} i If the data frame parsing model is completed, proceed to step (3) to continue processing; otherwise, the process ends normally.

[0092] (3) Let T be a temporary model, let T = M, and reset model T (i.e., set the field matching position of model T to the starting position 0).

[0093] (4) If 0 ≤ k ≤ size(C i ), size(C i (C) is a communication command model. i The number of fields is determined from C. i Extract field i from k Proceed to the next step; otherwise, proceed to step (2) to continue processing.

[0094] (5) Extract the next field i from model T. match Used for field matching, if i match If the result is empty, proceed to step (6) for processing; otherwise, proceed to step (9) for processing.

[0095] (6) The communication command model C i middle field i k Add it to the end of the field list L in model T.

[0096] (7) If field i k If the field is a simple field and an identifier field (attribute identified = true), then create a new Discriminator object (attribute ref set to field i). k The `id` attribute (specifying the associated fields of the specification) and sub-parse models Add the field Discriminator object to the end of the field list L in model T, and add the sub-parse model M. k Add a new reduction condition to the sub-parse model set S of model M, specifically to the Discriminator field object, i.e., field i. k To sub-analytic model M k Association mapping (i.e., describing when field i) k When the value equals the defaultValue property value, the sub-parse model M is used. k (To proceed with the next step of analysis), set Y = M k Reset model T, k++, and jump to step (4) to continue processing.

[0097] (8) If field i k If it is a composite field or a non-identifying field (attribute identified = false), then k++, and jump to step (4) to continue processing.

[0098] (9) If field i k and field i match If the fields are identical (for simple fields, the field type, including the attribute values ​​of id, length, identified, etc., must all be the same; for composite fields, the types and attributes of the fields they contain must all be the same), then proceed to step (10) to continue processing; otherwise, if the specification fails, exit abnormally.

[0099] (10) If field i k If it is a composite field or a non-identifying field (attribute identified = false), then k++, and jump to step (4) to continue processing; otherwise, jump to step (11) to continue processing.

[0100] (11) Extract the next field i from model T. next If i next Does not exist or i next If it is not a specification field, the specification fails and the process exits abnormally; otherwise, it jumps to step (12) to continue processing.

[0101] (12) In field i next (Convention Field) using field i k The defaultValue property value is used to find the associated sub-parse model M. k If the subanalytic model M k If it exists, then set T = M. k If the model Y is reset, k++, then proceed to step (4) to continue processing; otherwise, proceed to step (13) to continue processing.

[0102] (13) Create a new sub-analytical model Add the sub-parse model Mk to the set S of sub-parse models of model M, in field i next Add a new specification condition to (specification field), namely field i k To sub-analytic model M k Association mapping (i.e., describing when field i) k When the value equals the defaultValue property value, the sub-parse model M is used. k (Proceed to the next step of analysis), set T=M k Reset model T, k++, and jump to step (4) to continue processing.

[0103] Figure 5 The image shows a data frame parsing model for a servo system extracted using the method described above.

[0104] Step 4: Parse the data frame

[0105] Parsing data frames is based on the data frame parsing model M = (L, S) extracted in the third step, and the received interface data frames F = B0B1B2…B n (B i The data is parsed as single-byte data (0≤i≤n) to identify the communication command corresponding to the interface data frame and the values ​​of each constituent field. The specific process of parsing the data frame is described below:

[0106] (1) Initialize the first-in-first-out queue Data parsing result set Data frame parsing model T = M.

[0107] (2) Add all fields in the field list L of the data frame parsing model M = (L, S) into the queue Q in index order.

[0108] (3) If queue Q is not empty, jump to step (4) to continue processing; otherwise, the data frame parsing is completed and the process ends normally (the data frame parsing model T corresponds to the communication command frame, and the data parsing result set D corresponds to the field value).

[0109] (4) Pop a field item from queue Q. If the field item is a reduced field, jump to step (5) to continue processing; otherwise, call the corresponding field data parser to parse the data according to the type of the field item. The main operations include extracting the corresponding bytes of data from the interface data frame F according to the field length, and then converting the extracted byte data into the corresponding data value (such as 2-byte integer, 4-byte floating point, etc.). The parsed data value is added to the data parsing result set D in the format of (k, v), where k is the id attribute of the field item and v is the data value obtained from the parsing of the field item. Jump to step (3) to continue processing.

[0110] (5) Obtain the associated field id of the reduced field item through the ref attribute of the reduced field item; obtain the data parsing result value of the associated field from the data parsing result set D through the associated field id; obtain the sub-parsing model M from the data frame parsing model M = (L, S) based on the reduced conditions in the reduced field item through the data parsing result value of the associated field. k If the subanalytic model M k If the data frame does not exist, parsing the data frame will fail and the process will exit abnormally; otherwise, proceed to step (6) to continue processing.

[0111] (6) Let the data frame parsing model T = M k Sub-analytical model M k All fields in the field list L are added to queue Q in index order, and then the process jumps to step (3) to continue processing.

[0112] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.< / requestcommand> < / discriminator> < / requestcommand> < / requestcommand> < / requestcommand> < / bititem> < / bitcollection> < / bitcollection> < / itemcollection> < / itemcollection> < / itemdimarray> < / itemdimarray> < / itemarray> < / itemarray> < / hexitem> < / hexitem> < / crcitem> < / crcitem> < / doubleitem> < / doubleitem> < / floatitem> < / floatitem> < / ulongitem> < / longitem> < / ulongitem> < / longitem> < / uintitem> < / intitem> < / uintitem> < / intitem> < / ushortitem> < / shortitem> < / ushortitem> < / shortitem> < / ubyteitem> < / byteitem> < / ubyteitem> < / byteitem> < / bitcollection> < / bititem> < / bititem> < / bititem>

Claims

1. A configuration-based embedded software interface data frame parsing method, characterized in that, The process includes two phases: building a data frame parsing model and parsing the data frame. In the data frame parsing model building phase, the data frame parsing model is built through three steps: interface protocol configuration, building the interface protocol model, and refining the data frame parsing model. During the data frame parsing stage, based on the data frame parsing model, the communication command frames contained in the interface data frames are parsed out, including the command frame name and the values ​​of each component field. The method specifically includes the following steps: Step 1: Interface Protocol Configuration First, an embedded software interface protocol logical model is constructed to implement interface protocol configuration, extract data frame parsing models, and parse data frames. The embedded software interface protocol logical model includes three types of fields: simple fields, composite fields, and specification fields. Simple fields include nine types: bit fields, byte fields, short integer fields, integer fields, long integer fields, floating-point fields, long floating-point fields, check fields, and hexadecimal fields. Composite fields include five types: fixed-length arrays, variable-length arrays, field sets, bit sets, and communication commands. Specification fields are used to extract data frame parsing models and parse data frames, but are not directly used for interface protocol configuration. Interface protocol configuration refers to describing the embedded software interface protocol based on the simple and composite fields using Extensible Markup Language (XML). Step 2: Constructing the interface protocol model The interface protocol model is constructed by loading the interface protocol configuration, that is, loading a series of XML configuration files. Since each communication command corresponds to an XML configuration file, and the interface protocol model is built based on a series of communication commands, the interface protocol model is a collection of communication command models. Step 3: Refine the data frame parsing model Extracting the data frame parsing model builds upon the second step, by extracting the interface protocol model, which is essentially a set of communication command models. Reduced to a unified data frame parsing model The list of fields ={ }, Sub-analytic model set ={ }, For the sub-analytic model, where, A communication command consisting of a set of fields , ; Step 4: Parse the data frame Parsing data frames is based on the data frame parsing model refined in the third step. For the received interface data frames The data frame is parsed to identify the communication command corresponding to the interface data frame, as well as the values ​​of each constituent field. It is single-byte data.

2. The method as described in claim 1, characterized in that, The methods and constraints for defining various fields in the embedded software interface protocol logic model are as follows: (1) Bit field Bit fields are used to describe bit data in the interface protocol; bit field definition method: the corresponding XML tag for a bit field is... <bititem> The attributes include field identifier id, field name name, field length length, field default value defaultValue, and field description description;< / bititem> Bit field definition constraints: Bit fields are simple fields and cannot contain any field type, i.e. <bititem>No sub-tags can be defined within a tag; furthermore, bit fields must be defined within a bit set, i.e., the tag. <bititem>Must be used as a label <bitcollection> It must be defined as a child tag, and cannot be defined independently;< / bitcollection> < / bititem> < / bititem> (2) Byte field Byte fields are used to describe byte data in the interface protocol, including signed and unsigned types, representing a character or integer of 1 byte length; byte field definition method: the corresponding XML tags for signed and unsigned byte fields are respectively... <byteitem>and <ubyteitem> The attributes include field identifier (id), field name (name), field length (length), whether the field is identified (identified), field default value (defaultValue), and field description (description).< / ubyteitem> < / byteitem> Byte field definition constraints: Byte fields are simple fields and cannot contain any field type, i.e. <byteitem>or <ubyteitem> No child tags can be defined within a tag;< / ubyteitem> < / byteitem> (3) Short integer field Short integer fields are used to describe short integer data in the interface protocol, including both signed and unsigned types, representing integers of 2 bytes in length. The definition method for short integer fields is as follows: the corresponding XML tags for signed and unsigned short integer fields are... <shortitem>and <ushortitem> The attributes include field identifier (id), field name (name), field length (length), whether the field is identified (identified), field default value (defaultValue), and field description (description).< / ushortitem> < / shortitem> Short integer field definition constraints: Short integer fields are simple fields and cannot contain any field type, i.e. <shortitem>or <ushortitem> No child tags can be defined within a tag;< / ushortitem> < / shortitem> (4) Integer field Integer fields are used to describe integer data in the interface protocol, including both signed and unsigned types, representing integers of 4 bytes in length. Integer field definition methods: The corresponding XML tags for signed and unsigned integer fields are respectively... <intitem>and <uintitem> The attributes include field identifier (id), field name (name), field length (length), whether the field is identified (identified), field default value (defaultValue), and field description (description).< / uintitem> < / intitem> Integer field definition constraints: Integer fields are simple fields and cannot contain any field type, i.e. <intitem>or <uintitem> No child tags can be defined within a tag;< / uintitem> < / intitem> (5) Long integer field Long integer fields are used to describe long integer data in the interface protocol, including both signed and unsigned types, representing integers of 8 bytes in length. The definition method for long integer fields is as follows: the corresponding XML tags for signed and unsigned long integer fields are... <longitem>and <ulongitem>The attributes include field identifier (id), field name (name), field length (length), whether the field is identified (identified), field default value (defaultValue), and field description (description).< / ulongitem> < / longitem> Long integer field definition constraints: Long integer fields are simple fields and cannot contain any field type, i.e. <longitem>or <ulongitem> No child tags can be defined within a tag;< / ulongitem> < / longitem> (6) Floating-point field The floating-point field is used to describe floating-point numbers in the interface protocol, representing a 4-byte floating-point number; the floating-point field is defined as follows: the corresponding XML tag for the floating-point field is... <floatitem> The attributes include field identifier id, field name name, field length length, field default value defaultValue, and field description description;< / floatitem> Floating-point field definition constraints: Floating-point fields are simple fields and cannot contain any field type, i.e. <floatitem> No child tags can be defined within a tag;< / floatitem> (7) Long floating-point field The long floating-point field is used to describe high-precision floating-point numbers in the interface protocol, representing a floating-point number with a length of 8 bytes. The long floating-point field is defined as follows: the corresponding XML tag for the long floating-point field is... <doubleitem> The attributes include field identifier id, field name name, field length length, field default value defaultValue, and field description description;< / doubleitem> Long floating-point field definition constraints: Long floating-point fields are simple fields and cannot contain any field type, i.e. <doubleitem> No child tags can be defined within a tag;< / doubleitem> (8) Validation fields The check field is used to describe the CRC data in the interface protocol. By defining the check field, the CRC check of the data frame can be automatically calculated. Validation field definition method: The corresponding XML tag for the validation field is <crcitem> The attributes include field identifier id, field name name, field length length, field default value defaultValue, field description description, validation algorithm name algorithm, validation start byte start, and validation end byte end.< / crcitem> Validation field definition constraints: Validation fields must be simple fields and cannot contain any field type, i.e. <crcitem> No child tags can be defined within a tag;< / crcitem> (9) Hexadecimal field Hexadecimal fields are used to describe hexadecimal data in the interface protocol; the definition method for hexadecimal fields is as follows: the corresponding XML tag for a hexadecimal field is... <hexitem> The attributes include field identifier (id), field name (name), field length (length), whether the field is identified (identified), field default value (defaultValue), and field description (description).< / hexitem> Hexadecimal field definition constraints: Hexadecimal fields are simple fields and cannot contain any field type, i.e. <hexitem> No child tags can be defined within a tag;< / hexitem> (10) Fixed-length array Fixed-length arrays are used to describe array data in interface protocols. The dimensions of the array are specified by the field length. Fixed-length arrays are defined using the XML tag: <itemarray> The attributes include field identifier (id), field name (name), field length (length), and field description (description).< / itemarray> Fixed-length array definition constraints: Fixed-length arrays are composite fields. The field itself only defines the dimensions of the array; the data type is specified by defining a simple field, i.e., by defining a label. <itemarray> The sub-tags specify the data type of the array field; the data type of a fixed-length array can only be specified through a simple field, and only one simple field can be defined.< / itemarray> (11) Variable-length array Variable-length arrays are used to describe variable-length array data in the interface protocol. The dimensions of the array are determined by other simple fields in the interface protocol. Variable-length arrays are defined using the XML tag: <itemdimarray> The attributes include field identifier (id), field name (name), associated field ID (ref), and field description (description).< / itemdimarray> Variable-length array definition constraints: Variable-length arrays are composite fields. The dimensions of the array are determined by the associated field specified by the `ref` attribute. The data type is specified by defining a simple field, i.e., by defining a tag. <itemdimarray> The sub-tags specify the data type of the array field; the data type of a variable-length array can only be specified through a simple field, and only one simple field can be defined.< / itemdimarray> (12) Field set Field sets are used to categorize fields in an interface protocol. Multiple adjacent fields can be grouped into a single field set. Field set definition method: The corresponding XML tag for a field set is... <itemcollection> The attributes include field identifier (id), field name (name), and field description (description).< / itemcollection> Field set definition constraints: Field sets can contain simple fields or composite fields, meaning they can be nested, i.e., tags. <itemcollection> You can define both simple field type sub-tags and composite field type sub-tags in the middle;< / itemcollection> (13) Bit set Bit sets are used to maintain bit data in the interface protocol, ensuring that multiple bit fields form a complete byte of data; bit set definition method: the corresponding XML tag for a bit set is... <bitcollection> The attributes include field identifier (id), field name (name), field length (length), and field description (description).< / bitcollection> Bit set definition constraints: The bit set is a composite field and can only and must contain bit fields, i.e., tags. <bitcollection>Only and must define <bititem> Sub-tags;< / bititem> < / bitcollection> (14) Communication commands A communication command describes how a set of simple or composite fields are combined to form a complete communication command; the method for defining a communication command is as follows: the corresponding XML tag for a communication command is... <requestcommand> The attributes include field identifier id, field name name, command byte order byteOrder, and command description;< / requestcommand> Communication command definition constraints: Communication commands belong to composite fields and can contain all simple field types and all composite field types except communication commands, i.e., tags. <requestcommand>You can define any simple field label, or you can define labels other than... <requestcommand> Any other composite field tags besides the tag;< / requestcommand> < / requestcommand> (15) Specification fields Specification field definition method: The XML tag corresponding to the specification field is <discriminator>The attributes include field identifier id, field name name, associated field id ref, and command description description; each communication command is configured using a separate XML configuration file, and each XML configuration file can only define one communication command.< / discriminator> 3. The method as described in claim 2, characterized in that, The second step in constructing the interface protocol model involves validating the XML elements in the XML configuration file, including element structure constraint validation and attribute constraint validation. Element structure constraint validation is performed based on the field definition constraints; attribute constraint validation is performed based on the attribute configuration of the fields. After validating the XML configuration file, the XML configuration file is parsed, and a corresponding entity object is created for each XML element. Following the hierarchical structure of the XML elements, a communication command model is constructed, i.e., based on... <requestcommand> The tree structure with the root node as the element, the set of communication command models is the interface protocol model.< / requestcommand> 4. The method as described in claim 3, characterized in that, The specific process for refining the data frame parsing model in the third step is described below: (1) Initialize the model ,set up , , , ; (2) If From the set of communication command models Extract a communication command model from it. If the data frame parsing model is completed, proceed to step (3) to continue processing; otherwise, the process ends normally. (3) Set up a temporary model ,make Reset the model ; (4) If , For communication command model The number of fields, from Extracting fields Proceed to the next step; otherwise, proceed to step (2) to continue processing. (5) From the model Retrieve the next field Used for field matching, if If the result is empty, proceed to step (6) for processing; otherwise, proceed to step (9) for processing. (6) Communication command model Middle field Add to model List of fields end; (7) If the field It is a simple field and an identifier field (attribute) If so, then create a new specification field. Object and Sub-parse Model object properties Set as a field of Attributes, and specify the associated fields of the specification, and put the fields Adding objects to the model List of fields Finally, the sub-analytic model Add to model Sub-analytic model set In the field Add a new specification condition to the object, i.e., the field To sub-analytic model The association mapping, that is, explaining when the field The value is equal to When dealing with attribute values, a sub-parse model is used. Proceed to the next step of analysis and settings. Reset the model Proceed to step (4) to continue processing; (8) If the field If it is a composite field or a non-identifier field, then...

1. Proceed to step (4) to continue processing; (9) If the field and fields If they are the same, proceed to step (10) to continue processing; Otherwise, if the protocol fails, the system will exit abnormally. (10) If the field If it is a composite field or a non-identifier field, then...

1. If the process continues, proceed to step (4); otherwise, proceed to step (11) to continue. (11) From the model Retrieve the next field ,if Does not exist or If it is not a specification field, the specification fails and the process exits abnormally; otherwise, it jumps to step (12) to continue processing. (12) In the field Using fields of Attribute value, find associated sub-parse model If the sub-analytic model If it exists, then set it. Reset the model ,Will 1. If the process continues, proceed to step (4); otherwise, proceed to step (13) to continue. (13) Create a new sub-analytical model Sub-analytical model Add to model Sub-analytic model set In the field Add a new specification condition, namely the field To sub-analytic model The association mapping, that is, explaining when the field The value is equal to When dealing with attribute values, a sub-parse model is used. Proceed to the next step of analysis and settings. Reset the model Then proceed to step (4) to continue processing.

5. The method as described in claim 4, characterized in that, The specific process of parsing the data frame in step four is described as follows: (1) Initialize the first-in-first-out queue Data parsing result set Data frame parsing model ; (2) Data frame parsing model field list All fields in the middle are added to the queue in index order. middle; (3) If the queue If it is not empty, then proceed to step (4) to continue processing; Otherwise, the data frame parsing is complete, and the process ends normally. (Data frame parsing model) Corresponding communication command frame, data parsing result set Retrieve values ​​from the corresponding fields; (4) From the queue A field pops up If the field If it is a specification field, proceed to step (5) to continue processing; otherwise, follow the field... The data type calls the corresponding field data parser to parse the data. Specific operations include parsing according to field length. From interface data frames Extract the corresponding bytes of data from the data source, and then convert the extracted bytes into the appropriate data type. ; Data obtained from parsing according to Add the format to the data parsing result set Among them For fields The id attribute For from field Data obtained from parsing ; Jump to step (3) to continue processing; (5) Through specification fields Attributes Obtain the specification field Related fields ; through associated fields From the data analysis result set Obtain the data parsing results of related fields ; Parsing results from associated fields Based on specification fields The specification conditions in the data frame parsing model Obtaining the sub-analysis model If the sub-analytic model If the data frame does not exist, parsing the data frame will fail, and the process will exit abnormally. Otherwise, proceed to step (6) to continue processing; (6) Let the data frame parsing model Sub-analytical model field list All fields in the index are added to the queue in index order. In the middle, jump to step (3) to continue processing.

6. The method as described in claim 1, characterized in that, The interface protocol is a servo system interface protocol.

7. An embedded software interface testing method based on the method described in any one of claims 1 to 6.

8. An embedded software interface testing tool based on the method described in any one of claims 1 to 6.

Images