Data identification generation method and device based on communication protocol, and storage medium

Abstract

The application discloses a data identification generation method and device based on a communication protocol and a storage medium, relates to the technical field of power system communication, and discloses a data identification generation method based on a communication protocol, which comprises the following steps: acquiring a data dictionary description file, wherein the data dictionary description file comprises at least one rule description object; determining a basic identification, a variable byte index, an original value and a termination value according to the rule description object; determining a value sequence of a corresponding byte according to the original value and the termination value; and cyclically replacing an original byte corresponding to the variable byte index in the basic identification with a current value in the value sequence, so as to generate a target data identification sequence. The application abstracts data identification into a structured rule description, realizes the definition of a large number of data identifications by a small amount of configuration, solves the problem of low data identification maintenance efficiency in a hard coding or static configuration mode, and significantly improves the development efficiency and the maintainability of a system in a communication protocol iteration process.

Description

Technical Field

[0001] This application relates to the field of power system communication technology, and in particular to a data identifier generation method, device and storage medium based on communication protocols. Background Technology

[0002] In the development of terminal products in the field of power system communication, communication protocols define a large number of data identifiers as unique identifiers for accessing business data units, and these data identifiers exhibit predictable coding patterns within local scopes. Currently, data identifiers are mainly hard-coded into the business code or configured in parameter files as static lists. However, given the large number of data identifiers with local coding patterns, these methods result in lengthy code or configuration files and low maintenance efficiency. When communication protocol versions are updated, leading to the addition or removal of data identifiers, manual searching and modification of each item in the code or configuration file is required, failing to achieve effective decoupling between business code and communication protocol data identifier management.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main purpose of this application is to provide a data identifier generation method, device and storage medium based on communication protocol, which aims to solve the technical problem of low maintenance efficiency of the current data identifier management method.

[0005] To achieve the above objectives, embodiments of this application provide a data identifier generation method based on a communication protocol, the data identifier generation method based on a communication protocol including:

[0006] Obtain a data dictionary description file, wherein the data dictionary description file includes at least one rule description object;

[0007] Based on the object described by the rules, determine the basic identifier, variable byte index, original value, and termination value;

[0008] Based on the original value and the termination value, determine the value sequence of the corresponding byte;

[0009] The original byte corresponding to the variable byte index in the basic identifier is replaced with the current value in the value sequence in a loop, thereby generating the target data identifier sequence.

[0010] In one embodiment, prior to the step of obtaining the data dictionary description file, the data identifier generation method based on the communication protocol further includes:

[0011] Obtain the historical data identifier set defined by the communication protocol;

[0012] The encoding rules are extracted from the historical data identifier set to generate at least one rule description object, which includes a basic identifier, a variable byte index, an original value, and a termination value.

[0013] The data dictionary description file is generated based on the described rules.

[0014] In one embodiment, the step of extracting encoding rules from the historical data identifier set to generate at least one rule description object includes:

[0015] The historical data identifier set is clustered to obtain one or more data identifier groups;

[0016] The data identifiers in each of the data identifier groups are byte-aligned to form a corresponding byte matrix, wherein each row corresponds to a data identifier and each column corresponds to a byte position;

[0017] Based on the byte matrix, determine the fixed byte columns and the variable byte columns;

[0018] Based on the fixed byte column and the variable byte column, determine the corresponding basic identifier and the variable byte index, and use the minimum and maximum values ​​of the variable byte column in the byte matrix as the original value and the termination value, respectively.

[0019] The rule description object is generated based on the base identifier, the variable byte index, the original value, and the termination value.

[0020] In one embodiment, the step of determining the fixed byte column and the variable byte column based on the byte matrix includes:

[0021] Determine the number of distinct byte values ​​contained in each column of the byte matrix;

[0022] If the number of different byte values ​​is greater than a preset threshold, the corresponding column is determined as the variable byte column; otherwise, the corresponding column is determined as the fixed byte column.

[0023] In one embodiment, the step of determining the value sequence of the corresponding byte based on the original value and the termination value includes:

[0024] Obtain the byte encoding type and preset step size of the original byte corresponding to the variable byte index;

[0025] Based on the byte encoding type, starting from the original value, intermediate values ​​are generated sequentially towards the termination value according to the preset step size until the termination value is covered, thus obtaining the initial value sequence.

[0026] Each intermediate value in the initial value sequence is encoded and converted to obtain the value sequence, wherein the first and last values ​​of the value sequence are the same as the original value and the termination value, respectively.

[0027] If the original value is equal to the termination value, then the original value is used as a unique element to obtain the value sequence of a single element.

[0028] In one embodiment, the step of replacing the original byte corresponding to the variable byte index in the basic identifier with the current value in the value sequence to generate the target data identifier sequence includes:

[0029] Traverse the value sequence corresponding to the rule description object and set the current value pointer, which initially points to the starting element of the value sequence;

[0030] Based on the variable byte index, locate the variable byte position in the basic identifier, read the current value pointed to by the current value pointer in a loop, and replace the original byte at the variable byte position in the basic identifier with the current value to obtain the target data identifier;

[0031] Move the current value pointer to the next element of the value sequence until the current value pointer points to the boundary of the value sequence, then terminate the loop to generate the target data identifier sequence corresponding to the rule description object.

[0032] In one embodiment, the step of moving the current value pointer to the next element of the value sequence until the current value pointer points to the boundary of the value sequence and terminating the loop to generate the target data identifier sequence corresponding to the rule description object includes:

[0033] If the rule description object contains a data block parameter, then after the loop ends, a corresponding data block data identifier is generated based on the value of the data block parameter and the basic identifier.

[0034] The data block identifier is appended to the target data identifier sequence.

[0035] In one embodiment, after the steps of locating the variable byte position in the basic identifier based on the variable byte index, cyclically reading the current value pointed to by the current value pointer, and replacing the original byte at the variable byte position in the basic identifier with the current value to obtain the target data identifier, the data identifier generation method based on the communication protocol further includes:

[0036] If the rule description object contains nested level parameters, the nested level parameters are parsed into sub-loop parameters, which include an independent sub-loop variable byte index, a sub-loop original value, and a sub-loop termination value.

[0037] In each iteration, the target data identifier is generated before the inner loop is executed. The pointer of the current value of the sub-loop is moved according to the sub-loop parameter until the sub-loop value sequence determined by the original value of the sub-loop and the termination value of the sub-loop is traversed. Thus, a second target data identifier is generated based on the current target data identifier.

[0038] When the inner loop ends, the current value pointer is moved to the next element of the value sequence until the current value pointer points to the boundary of the value sequence, and the loop terminates when the inner loop ends.

[0039] Based on the second target data identifier, a target data identifier sequence corresponding to the rule description object is generated.

[0040] This application embodiment also provides a data identifier generation device based on a communication protocol. The data identifier generation device based on a communication protocol includes: a memory, a processor, and a computer program stored in the memory and executable on the processor. The computer program is configured to implement the steps of the data identifier generation method based on the communication protocol as described above.

[0041] This application embodiment also provides a storage medium, which is a computer-readable storage medium, and stores a computer program on the storage medium. When the computer program is executed by a processor, it implements the steps of the data identifier generation method based on the communication protocol as described above.

[0042] One or more technical solutions proposed in this application have at least the following technical effects:

[0043] This application abstractly models the encoding patterns of data identifiers through rule description objects, describing the data dictionary as a structured rule containing basic identifiers, variable byte indices, original values, and termination values. This solves the problems of code redundancy and maintenance difficulties inherent in traditional hard-coding or static configuration methods. Traditional methods require individual configuration for each data identifier, resulting in a huge workload and lack of scalability when dealing with hundreds or thousands of regularly increasing identifiers (such as rates, time periods, and measurement points). This application, however, extracts commonalities in encoding, requiring only a few rules to define a large number of data identifiers, achieving automated batch generation of data identifiers. Furthermore, by determining the value sequence and cyclically replacing the variable bytes in the basic identifier, the accuracy and controllability of the generation process are ensured, significantly reducing the configuration complexity and maintenance cost of the data dictionary, improving development efficiency and the maintainability of the system during communication protocol iteration, making it suitable for the rapid generation and management of large-scale, structured data identifiers in power systems. Attached Figure Description

[0044] Figure 1 This is a flowchart illustrating the first embodiment of the data identifier generation method based on communication protocols involved in the embodiments of this application;

[0045] Figure 2 This is a flowchart illustrating the second embodiment of the data identifier generation method based on communication protocols involved in the embodiments of this application;

[0046] Figure 3 This is a flowchart illustrating the third embodiment of the data identifier generation method based on communication protocols involved in the embodiments of this application;

[0047] Figure 4 This is a flowchart illustrating the fourth embodiment of the data identifier generation method based on communication protocols involved in the embodiments of this application;

[0048] Figure 5 This is a schematic diagram of the structure of a data identifier generation device based on a communication protocol involved in the embodiments of this application.

[0049] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0050] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0051] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0052] In the development of terminal products in the field of power system communication, communication protocols define a large number of data identifiers as unique identifiers for accessing business data units, and these data identifiers exhibit predictable coding patterns within local scopes. Currently, data identifiers are mainly hard-coded into the business code or configured in parameter files as static lists. However, given the large number of data identifiers with local coding patterns, these methods result in lengthy code or configuration files and low maintenance efficiency. When communication protocol versions are updated, leading to the addition or removal of data identifiers, manual searching and modification of each item in the code or configuration file is required, failing to achieve effective decoupling between business code and communication protocol data identifier management.

[0053] In view of the above problems, this application proposes a data identifier generation method based on a communication protocol. The method involves obtaining a data dictionary description file, which includes at least one rule description object; determining a base identifier, a variable byte index, a raw value, and a termination value based on the rule description object; determining a value sequence for the corresponding byte based on the raw value and the termination value; and iteratively replacing the raw byte corresponding to the variable byte index in the base identifier with the current value in the value sequence to generate a target data identifier sequence.

[0054] This application provides a solution that abstractly models the encoding patterns of data identifiers through rule description objects. The data dictionary is described as a structured rule containing basic identifiers, variable byte indices, original values, and terminating values, solving problems such as code redundancy and maintenance difficulties inherent in traditional hard-coding or static configuration methods. Traditional methods require individual configuration for each data identifier. When dealing with hundreds or thousands of regularly increasing identifiers (such as rates, time periods, and measurement points), the configuration workload is enormous and lacks scalability. This application, by extracting common encoding characteristics, requires only a few rules to define a large number of data identifiers, achieving automated batch generation of data identifiers. Furthermore, by determining the value sequence and cyclically replacing the variable bytes in the basic identifier, the accuracy and controllability of the generation process are ensured, significantly reducing the configuration complexity and maintenance cost of the data dictionary, improving development efficiency and the maintainability of the system during communication protocol iteration. This is suitable for the rapid generation and management of large-scale, structured data identifiers in power systems.

[0055] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a power communication monitoring terminal, a substation back-end host, a power data server, etc., or an electronic device, industrial control device, smart terminal, etc., capable of realizing the above functions. The following uses a power communication system as an example to describe this embodiment and the subsequent embodiments.

[0056] The data identifier generation method based on communication protocol proposed in the first embodiment of this application can be found in [reference needed]. Figure 1 The method includes steps S10 to S40:

[0057] Step S10: Obtain a data dictionary description file, which includes at least one rule description object.

[0058] It should be noted that a data dictionary description file is a structured configuration file used to describe the rules for generating data identifiers (DI) in a communication protocol. It uses JSON (JavaScript Object Notation) format for easy parsing and expansion. This data dictionary description file does not directly list all data identifiers; instead, it defines a continuous or regularly changing range of data identifiers through abstract rule description objects. This significantly reduces the size of the configuration file and improves the maintainability of the data identifiers.

[0059] The rule description object is a JSON object in the data dictionary description file, used to describe the generation rules of data identifiers with the same encoding pattern. It includes fields such as base identifier (BaseID), variable byte index (Ind), original value (From), terminating value (To), whether it has a data block (Blok), and whether it has inner nesting (Subcycle).

[0060] Understandably, since products need to explicitly define their supported data identifier sets during startup or operation, directly writing all data identifiers into business code or configuration parameter files would result in verbose code, large configuration file sizes, and poor maintainability. It would also increase the complexity of version management and upgrades. Furthermore, directly maintaining all data identifiers is inefficient and error-prone. Therefore, by reading the data dictionary description file and dynamically generating the required data identifier set during product startup or operation, the efficiency and maintainability of data identifier management can be improved, thereby effectively decoupling business code from communication protocol data identifier management.

[0061] In this embodiment, the data dictionary description file can be loaded into the terminal device's memory via external storage media (such as Flash, EEPROM) or network interfaces (such as FTP, HTTP). It is read and cached by the corresponding processing flow during system startup for use in subsequent data identifier generation processes. The data dictionary description file uses JSON format, ensuring good cross-platform and operating system compatibility. During the parsing of the data dictionary description file, syntax validation and object extraction can be performed using JSON parsing libraries (such as Gson, FastJson, JackSon) to ensure the integrity of the rule description objects.

[0062] As a feasible implementation, the data dictionary description file can also be implemented using other structured formats, such as XML, YAML, or Protocol Buffers binary format, to adapt to the different system requirements for parsing performance or storage space. Furthermore, this data dictionary description file can be pre-installed on the terminal device at the factory, or it can be dynamically updated during operation via remote upgrades to support communication protocol version iterations.

[0063] Step S20: Determine the basic identifier, variable byte index, original value, and termination value according to the object described by the rules.

[0064] In this embodiment, to facilitate understanding of the meaning and function of each field in the rule description object, the key parameters in the rule description object are defined and explained as follows, referring to Table 1:

[0065] Table 1. Definition of Key Parameters for Rule Description Objects

[0066]

[0067] Based on the definition table of key parameters of the rule description object shown in Table 1, the base identifier (BaseID) refers to the starting data encoding value of the data identifier range corresponding to the rule description object, which serves as the basis for generating the data identifier sequence.

[0068] The variable byte index (Ind) is used to indicate the position of a byte that changes regularly during the data identifier generation process. According to the communication protocol definition, the data identifier encoding consists of four bytes (DI3, DI2, DI1, DI0), each byte being a hexadecimal code, where DI3 is the most significant byte and DI0 is the least significant byte. The variable byte index ranges from 0 to 3, corresponding to DI0 to DI3 respectively, i.e., numbered sequentially from the least significant byte to the most significant byte. For ease of calculation, Ind needs to be converted into the weight of the corresponding byte, used to locate the target byte in numerical operations. Therefore, when the variable byte index ranges from 0 to 3, its corresponding weights are (hexadecimal numbers) 0x01, 0x100, 0x10000, and 0x1000000.

[0069] The original value (From) and the ending value (To) together define the value range of the variable byte, representing the starting and ending values ​​of the variable byte, respectively.

[0070] The Blok field indicates whether a data block identifier (such as FF or 0F) should be appended to the end of the data identifier after the current loop ends, to support access to consecutive data blocks. This Blok field is dedicated to data blocks, and the data block identifier is the content of the logical OR Blok at a variable byte (associated Ind) position based on the most recently calculated data identifier.

[0071] The Subcycle field is used to indicate whether there is a nested sub-loop. If it exists, it means that the current loop needs to contain a sub-loop and extract the sub-loop parameter value as the inner loop to achieve multi-level progressive data identifier generation.

[0072] In this embodiment, the system extracts the values ​​of fields such as BaseID, Ind, From, To, BLOCK, and Subcycle by parsing the JSON fields of the rule description object. If any required field is missing or incorrectly formatted, the system will log the error and skip the rule description object to prevent program errors.

[0073] As a viable implementation, variable byte indexes can also be described using byte names (such as "DI0", "DI1") instead of numeric indices to improve readability; in addition, From and To support defining non-contiguous values ​​using expressions (such as "0x01:0x0A") or arrays to accommodate more complex encoding patterns.

[0074] Step S30: Determine the value sequence of the corresponding byte based on the original value and the termination value.

[0075] It should be noted that the value sequence refers to a list of all integer values ​​generated by the variable byte in ascending order from From to To, with a step size of 1 by default, including both From and To endpoints.

[0076] In this embodiment, an incrementing integer sequence is constructed, starting with From and ending with To. This sequence is used to sequentially replace the corresponding bytes in the basic identifier to generate a complete data identifier. The sequence generation is implemented using a cyclic accumulation method, supporting automatic carry-over processing for hexadecimal values.

[0077] For example, the data identifier for a single byte change is defined as follows:

[0078] {

[0079] "BaseID": "E0000100",

[0080] "Ind": "0",

[0081] "From": "00",

[0082] "To": "0B",

[0083] "Blok": "0F"

[0084] The rule description object fully defines a list of 13 consecutive data identifiers: E0000100, E0000101...E0000109, E000010A, E000010B, E000010F (data block identifier).

[0085] As a feasible implementation method, the value sequence can also support non-continuous modes, such as controlling the increment interval through the step parameter (Step) (e.g., incrementing once every 2), or excluding specific values ​​through a mask; in addition, the value sequence can be pre-generated and cached to balance memory usage and computational overhead.

[0086] Step S40: Repeatedly replace the original byte corresponding to the variable byte index in the basic identifier with the current value in the value sequence to generate the target data identifier sequence.

[0087] It should be noted that the target data identifier sequence refers to a complete set of data identifiers that conforms to the communication protocol definition and is restored according to the rule description object, which is used by subsequent business modules for data access or response.

[0088] In this embodiment, the system dynamically generates data identifiers by traversing the value sequence. The specific implementation process is as follows: First, the basic identifier is converted into a 4-byte array format. Then, based on the variable byte index (Ind), the position of the byte to be modified in the byte array (i.e., the variable byte position) is determined. Since the data identifier is stored in big-endian order (byte order is DI3, DI2, DI1, DI0), and the variable byte index is numbered from low to high (Ind=0 corresponds to DI0, Ind=3 corresponds to DI3), the actual operation position needs to be determined through index conversion. The specific mapping relationship is: Ind=0 corresponds to byte[3] (i.e., DI0), Ind=1 corresponds to byte[2] (i.e., DI1), Ind=2 corresponds to byte[1] (i.e., DI2), and Ind=3 corresponds to byte[0] (i.e., DI3). That is to say, Ind corresponds to the subscript of DIx, and the actual operation position is byte[3-Ind].

[0089] During the traversal, the current value in the value sequence will be written to the variable byte position in turn, and the byte array will be reassembled into a complete data identifier immediately after each modification. Taking BaseID=E0000100 (byte array [0xE0, 0x00, 0x01, 0x00]) as an example, when Ind=1 (corresponding to DI1, i.e. byte[2]), From=00, To=0B (i.e., when the value sequence is 0x00-0x0B), the system will modify the value at the byte[2] position in turn to generate the target data identifier sequence: E0000100, E0000101...E0000109, E000010A, E000010B.

[0090] As a feasible implementation method, byte replacement can be directly achieved through bitwise operations. The original byte content is cleared by shifting and masking operations, and then the new value is filled in by bitwise OR, avoiding the overhead of array conversion. In addition, when generating data identifiers, a generator pattern can be used to output them one by one, avoiding the generation of all data identifiers at once, which would lead to excessively high memory peaks.

[0091] This implementation introduces a JSON-formatted data dictionary description file, replacing traditional hard-coded or statically configured data identifiers with dynamically parsed and restored rules, thus achieving efficient management of massive data identifiers in the communication protocol. This implementation can compress thousands of data identifiers into a JSON description file of a few hundred lines, significantly reducing storage overhead and configuration complexity, and improving development efficiency and maintainability. Simultaneously, this implementation decouples business logic from protocol details, allowing the system to synchronously upgrade the data dictionary by adding, deleting, or modifying only a few rule descriptions when the communication protocol version is updated, enhancing the system's flexibility and scalability.

[0092] Based on the above embodiments of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 Before step S10, the data identifier generation method based on the communication protocol further includes steps S101 to S103:

[0093] Step S101: Obtain the set of historical data identifiers defined by the communication protocol.

[0094] It should be noted that the historical data identifier set refers to a collection of all or part of the data identifiers explicitly defined in the communication protocol. It typically exists in the form of tables, documents, or databases, and includes information such as the encoded value (e.g., E0000130), name, functional description, data type, and object class of each data identifier. This set is the original input source for generating the structured data dictionary description file.

[0095] In this embodiment, the historical data identifier set is obtained by parsing the data identifier definition table in the communication protocol document. Specifically, the protocol document is converted into structured text, and regular expressions are used to extract all data identifier codes and their context information, or a standard data identifier list is directly exported from an existing protocol database. During the extraction process, the data identifiers are sorted according to their encoded values ​​to facilitate subsequent analysis of their encoding patterns.

[0096] As a feasible implementation method, historical data identifier sets can also be obtained through manual input, importing from Excel spreadsheets, or reverse parsing from existing terminal device firmware. Furthermore, if the communication protocol provides standard APIs or XML format definition files, these can also be obtained directly through the interface, improving the automation and accuracy of data acquisition.

[0097] Step S102: Extract encoding rules from the historical data identifier set to generate at least one rule description object, wherein the rule description object includes a basic identifier, a variable byte index, an original value, and a termination value.

[0098] In this embodiment, encoding rule extraction refers to performing pattern recognition on a sorted set of historical data identifiers to identify data identifier segments with continuous increasing or local regularity, and abstracting them into rule description objects. Specifically, the sorted data identifier sequence is traversed, and the difference pattern between adjacent data identifiers is detected. If it is found that only one byte (such as DI1) of a certain data identifier segment changes in increment among multiple consecutive items, while the other bytes remain unchanged, it is determined that the data identifier segment conforms to the "single byte increasing" rule. Its starting data identifier is recorded as the base identifier (BaseID), the position of the changed byte is determined as the variable byte index (Ind), and the start and end values ​​of the changed byte positions in the data identifier segment are extracted as the original value (From) and the termination value (To), thereby generating a rule description object.

[0099] For scenarios with nested patterns (such as multi-dimensional structures like rates and time periods), further analysis is performed to determine if a two-layer change pattern exists. For example, if DI1 increases cyclically with DI0, a nested rule object containing a Subcycle field can be generated. Additionally, during rule extraction, the system will also identify whether data block access is required and mark the Block field accordingly.

[0100] As a feasible implementation method, encoding rule extraction can automatically discover the grouping patterns of data identifiers through machine learning clustering algorithms (such as K-means based on byte bit difference); it can also quickly identify common encoding patterns through predefined template matching methods (such as regular expression rule base); in addition, the encoding rule extraction process can also be completed with the assistance of software tools, and the accuracy and completeness of the generated rules can be ensured through manual verification and adjustment.

[0101] Step S103: Generate the data dictionary description file according to the rule description object.

[0102] In this embodiment, all rule description objects generated in step S102 are integrated into a self-describing file in standard JSON format. Each rule description object is an element in a JSON array, containing fields such as BaseID, Ind, From, To, BLOCK (optional), and Subcycle (optional). After generating the data dictionary description file, the system can perform syntax validation and logical consistency checks on the description file to prevent errors such as From>To or Ind being out of range.

[0103] As a viable implementation method, the data dictionary description file can also be generated in other formats, such as YAML, XML, or binary formats (such as Protocol Buffers).

[0104] In this implementation, encoding rules are extracted from historical data identifier sets, and a data dictionary description file is generated. This achieves automated conversion from raw specification data identifiers to structured self-describing files, reducing the risk of errors from manually writing data dictionaries and significantly improving specification adaptation efficiency. This allows new terminal products to quickly build a complete and standardized data identifier management system from the early stages of development. Furthermore, by transforming communication specification semantics into programmable rule objects, the maintainability of data identifier management is further enhanced.

[0105] As one possible implementation, step S102 includes steps S1021 to S1025:

[0106] Step S1021: Perform clustering processing on the historical data identifier set to obtain one or more data identifier groups.

[0107] In this embodiment, clustering refers to grouping data identifiers with the same high-order byte or similar numerical distributions into the same group based on the encoding similarity between them, so that rules can be generated by grouping them subsequently. Specifically, each data identifier is converted into a 4-byte array representation. A similarity measurement method based on byte differences (such as Hamming distance or byte prefix matching) is used to group all data identifiers.

[0108] As a feasible implementation method, clustering can be achieved through predefined rules, such as hash grouping based on the first two bytes (DI3 and DI2), or manual classification based on the functional categories defined in the communication protocol (such as "battery power" or "time").

[0109] Step S1022: Align the data identifiers in each of the data identifier groups by bytes to form a corresponding byte matrix, wherein each row corresponds to a data identifier and each column corresponds to a byte position.

[0110] In this embodiment, byte alignment refers to uniformly representing all data identifiers within the same data identifier group as a 4-byte sequence (DI3, DI2, DI1, DI0), forming a byte matrix. Each row of the matrix represents a data identifier, and each column corresponds to a byte position (column 0 is DI3, column 1 is DI2, column 2 is DI1, and column 3 is DI0). For example, if a group contains data identifiers E0000100, E0000101, E0000103, and E0000104, then its byte matrix is ​​as follows:

[0111] [[E0, 00, 01, 00],

[0112] [E0, 00, 01, 01],

[0113] [E0, 00, 01, 03],

[0114] [E0, 00, 01, 04]], this byte matrix can provide a structured data foundation for subsequent analysis of byte change patterns.

[0115] Step S1023: Based on the byte matrix, determine the fixed byte column and the variable byte column.

[0116] It should be noted that a fixed byte column refers to a column in a byte matrix where all values ​​are the same, indicating that the value corresponding to that byte position remains unchanged within that group of data identifiers. A variable byte column refers to a column where at least two values ​​exist, indicating that the value corresponding to that byte position is either increasing or changing.

[0117] In this embodiment, each column of the byte matrix (i.e., each byte position) is traversed, and it is checked whether all elements in that column are consistent. If they are consistent, it is marked as a fixed byte column; if there are differences, it is marked as a variable byte column. Typically, there is only one variable byte column in a valid data identifier group (e.g., only DI0 changes). If multiple variable columns appear, it is necessary to further determine whether there is a nested pattern.

[0118] As a feasible implementation method, variable byte columns can be identified by statistical variance or entropy calculation. If the entropy value of a column is close to 0, it is a fixed column; if the entropy value is high, it is a variable column. Variable byte columns can also be determined by difference analysis (calculating the byte difference between adjacent rows in the same column).

[0119] As another feasible implementation, step S1023 includes steps S10231~S10232:

[0120] Step S10231: Determine the number of different byte values ​​contained in each column of the byte matrix.

[0121] Step S10232: If the number of different byte values ​​is greater than a preset threshold, the corresponding column is determined as the variable byte column; otherwise, the corresponding column is determined as the fixed byte column.

[0122] In this embodiment, since the data identifier group has undergone clustering, the data identifiers within it are highly similar in encoding. Therefore, by counting the number of different byte values ​​contained in each column of the byte matrix, the change pattern of the byte position can be effectively determined. If a column contains only one byte value, it is considered that the byte remains unchanged throughout the entire data identifier group, and is therefore determined to be a fixed byte column. If the number of different byte values ​​contained in the column exceeds a preset threshold (e.g., greater than 1), it indicates that the byte position has changed, and is thus determined to be a variable byte column. This preset threshold can be flexibly set according to the needs of the actual application scenario, and is usually set to 1.

[0123] Step S1024: Determine the corresponding basic identifier and the variable byte index based on the fixed byte column and the variable byte column, and use the minimum and maximum values ​​of the variable byte column in the byte matrix as the original value and the termination value, respectively.

[0124] In this embodiment, the base identifier (BaseID) is composed of the values ​​of each fixed byte column and the starting value of the variable byte column. Typically, the complete code of the first data identifier in the same data identifier group is taken as the BaseID. The variable byte index (Ind) is determined by the column index of the variable byte column; for example, column 3 is DI0 (Ind=0), and column 0 is DI3 (Ind=3). The original value (From) is the minimum value in the variable byte column, and the terminating value (To) is the maximum value; both are represented in hexadecimal. For example, if the variable byte column is DI2 (column 1), and its value range is 00~04, then From = "00", To = "04".

[0125] As a feasible implementation, before step S1024, after identifying the variable byte column, its numerical change pattern is further verified. Specifically, all byte values ​​of the variable byte column are extracted and sorted by numerical value. The change pattern of the variable byte column is determined by calculating the difference between adjacent values. If the difference is a fixed constant 1, it is determined to be a continuous sequence; if the difference is another fixed constant k, it is determined to be an arithmetic sequence. When the sequence satisfies any of the above patterns (continuous sequence or arithmetic sequence), the data identifier group is determined to have the conditions for regularization description, and step S1024 continues; if the sequence change has no definite pattern, the subsequent encoding rule extraction process is not performed, and the data identifier group is marked as requiring manual review. This implementation can effectively filter data identifier data that does not conform to the standard encoding pattern, ensuring that the generated rule description objects all have clear encoding patterns, thereby improving the accuracy of data dictionary construction.

[0126] As another feasible implementation, a basic identifier is generated by obtaining the byte sequence common to all data identifiers in the same data identifier group as a basic prefix and filling the variable byte positions with zero values. The original value and the termination value can be obtained by sorting the value sequence of the variable byte column and taking the first and last elements, or by directly calculating using built-in functions (such as min / max). Furthermore, when a non-continuous change in the variable byte column is detected (e.g., 01, 03, 05), the variable byte column can be automatically identified as a non-standard step size pattern, and the rule description object can be expanded by adding a step field to define the specific step size.

[0127] Step S1025: Generate the rule description object based on the base identifier, the variable byte index, the original value, and the termination value.

[0128] In this embodiment, the parameters corresponding to each data identifier group extracted in step S1024 are encapsulated into a JSON-formatted rule description object. If a data block data identifier is detected in the data identifier group, a Blok field is added to the rule description object. Then, all the generated rule description objects are integrated to generate a data dictionary description file.

[0129] Based on the above embodiments of this application, in the third embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 In the data identifier generation method based on the communication protocol, step S30 includes steps S310 to S340:

[0130] Step S310: Obtain the byte encoding type and preset step size of the original byte corresponding to the variable byte index.

[0131] It should be noted that byte encoding type refers to the numerical representation format used by variable bytes in the communication protocol. Common types include binary, decimal (BCD code), and hexadecimal. Preset step size refers to the fixed increment between two adjacent values ​​when generating the value sequence.

[0132] Since different data fields in the communication protocol may use different encoding formats, direct numerical calculation may result in the generation of invalid identifiers that do not conform to the communication protocol. Therefore, by determining the calculation rules for the subsequent value sequence through different byte encoding types, the accuracy of the final generated data identifier can be ensured.

[0133] In this embodiment, the encoding type and step size can be obtained by querying the metadata configuration table associated with the variable byte index. The metadata configuration table stores the static parameter mapping relationship related to data identifier encoding, and it is usually loaded into memory during the system initialization phase according to the communication protocol version. Through the table lookup mechanism, the system can dynamically adapt to the encoding constraints of different communication protocol versions or different data fields, providing an accurate calculation basis for subsequent sequence generation.

[0134] Step S320: Based on the byte encoding type, starting from the original value, generate intermediate values ​​sequentially towards the termination value according to the preset step size until the termination value is covered, thus obtaining the initial value sequence.

[0135] In this embodiment, the initial value sequence is generated in the direction from the starting value (From) to the ending value (To), and increases by a preset step size.

[0136] Step S330: Convert the encoding format of each intermediate value in the initial value sequence to obtain the value sequence, wherein the first and last values ​​of the value sequence are the same as the original value and the termination value, respectively.

[0137] In this embodiment, the encoding format conversion aims to ensure that each generated intermediate value conforms to the format requirements of the target byte position in the communication protocol. Therefore, this step, based on the byte encoding type, normalizes each value in the initial sequence, ensuring that all values ​​in the value sequence are consistent with the encoding specification of the original byte values, thereby guaranteeing that the subsequently generated data identifiers can be correctly parsed by both communicating parties.

[0138] Step S340: If the original value is equal to the termination value, then the original value is used as a unique element to obtain the value sequence of a single element.

[0139] In this embodiment, when From and To are equal, it means that the rule description object corresponds to only one fixed data identifier, and there is no need to generate an increasing sequence. At this time, the value is directly used as the unique element of the value sequence.

[0140] For example, for the definition of an independent data identifier, it can be defined according to the single byte change rule, that is, the values ​​of From and To are both 00, as shown below:

[0141] {

[0142] "BaseID": "E0000000"

[0143] "Ind": "0", / / Any value between 0 and 3

[0144] "From": "00",

[0145] "To": "00"

[0146] The rule describes an object that defines only one independent data identifier code, E0000000.

[0147] This embodiment achieves accurate modeling of complex encoding rules and ordered generation of value sequences by identifying byte encoding types and preset step sizes. This method not only supports multiple encoding formats but also accommodates non-unit step size variations, significantly improving the adaptability and accuracy of data identifier generation. Furthermore, through conditional judgments and format conversions, it ensures that all output values ​​conform to the semantic specifications of the communication protocol, avoiding the output of illegal or invalid values, thus enhancing data legitimacy. It also significantly reduces manual intervention and configuration costs, providing reliable technical support for the engineering application of communication protocols.

[0148] Based on the above embodiments of this application, in the fourth embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 4 The data identifier generation method based on the communication protocol includes steps S410 to S430 in step S40:

[0149] Step S410: Traverse the value sequence corresponding to the rule description object and set the current value pointer, which initially points to the starting element of the value sequence.

[0150] In this embodiment, the current value pointer is an index or reference variable used to traverse the sequence, initially pointing to the first element of the value sequence. A loop structure controls the movement of the current value pointer, ensuring that each value in the value sequence is processed sequentially.

[0151] Step S420: Based on the variable byte index, locate the variable byte position in the basic identifier, read the current value pointed to by the current value pointer in a loop, and replace the original byte at the variable byte position in the basic identifier with the current value to obtain the target data identifier.

[0152] In this embodiment, the variable byte position is determined based on Ind, and then the current value pointed to by the pointer is written to that variable byte position. For example, if BaseID is E0000000 (i.e., [0xE0, 0x00, 0x00, 0x00]), Ind=1 (replacing DI1), and the current value=0x03, then after replacement, we get [0xE0, 0x00, 0x03, 0x00], and the corresponding data identifier is E0000300.

[0153] Step S430: Move the current value pointer to the next element of the value sequence until the current value pointer points to the boundary of the value sequence, and terminate the loop to generate the target data identifier sequence corresponding to the rule description object.

[0154] In this embodiment, after each target data identifier is generated, the current value pointer is moved one position forward to continue processing the next value in the value sequence. When the pointer exceeds the range of the value sequence (i.e., i>=length), the loop ends, thus completing the generation of all data identifiers corresponding to the current rule description object.

[0155] As one possible implementation, step S430 includes steps S4310 to S4320:

[0156] Step S4310: If the rule description object contains a data block parameter, then after the loop ends, generate the corresponding data block data identifier based on the value of the data block parameter and the basic identifier.

[0157] Step S4320: Append the data block identifier to the target data identifier sequence.

[0158] In this implementation, the data block parameter (Blok field) is used to indicate whether the current rule description object needs to generate a corresponding data block data identifier. When the rule description object contains the Blok parameter, a data block data identifier is appended after the data identifier of the current loop is generated.

[0159] For example, the following rule description object contains BLOK field definitions:

[0160] {

[0161] "BaseID": "E0000100",

[0162] "Ind": "0",

[0163] "From": "00",

[0164] "To": "0B",

[0165] "Blok": "0F"

[0166] The rule description object first generates 12 consecutive basic data identifiers (E0000100, E0000101...E0000109, E000010A, E000010B). Then, based on the Blok field value "0F", an additional data block identifier E000010F is appended to the end of the variable byte position. Therefore, the rule description object fully defines a list of 13 consecutive data identifiers. This method automatically expands and generates the data block access identifiers required by the specification without the need for additional rule definitions, ensuring the integrity of the data dictionary and significantly improving compatibility with the communication specification.

[0167] As another feasible implementation, steps S421 to S424 are included after step S420:

[0168] Step S421: If there are nested level parameters in the rule description object, then the nested level parameters are parsed into sub-loop parameters. The sub-loop parameters include an independent sub-loop variable byte index, a sub-loop original value, and a sub-loop termination value.

[0169] In this embodiment, the nesting level parameter is represented in the rule description object as a structured field (such as Subcycle), which includes the variable byte position of the sub-loop (sub-loop variable byte index) and the value range (determined based on the original value of the sub-loop and the sub-loop termination value).

[0170] Step S422: In each loop, after generating the current target data identifier, the inner loop is performed. According to the sub-loop parameters, the pointer of the current value of the sub-loop is moved until the sub-loop value sequence determined by the original value of the sub-loop and the termination value of the sub-loop is traversed, thereby generating the second target data identifier based on the current target data identifier.

[0171] Step S423: When the inner loop ends, move the current value pointer to the next element of the value sequence until the current value pointer points to the boundary of the value sequence, and terminate the loop when the inner loop ends.

[0172] Step S424: Based on the second target data identifier, generate the target data identifier sequence corresponding to the rule description object.

[0173] In this embodiment, the specific implementation of the sub-loop can refer to the relevant processing logic of the aforementioned single-layer loop (only a single byte changes), and will not be repeated here.

[0174] For example, in order to help understand the implementation process of the data identifier generation method based on the communication protocol in this embodiment, the definition of the two-byte nested variable data identifier is explained below with reference to Table 2.

[0175] Specifically, for a two-byte nested variable data identifier definition, such as the current energy data identifier list for a measurement point, it can be defined as:

[0176] {

[0177] "BaseID": "00000000"

[0178] "Ind": "2",

[0179] "From": "00",

[0180] "To": "03",

[0181] "Subcycle": {

[0182] "Ind": "1",

[0183] "From": "00",

[0184] "To": "04", / / Number of electricity rates

[0185] "Blok": "FF"

[0186] }

[0187] The list of nested data identifiers defined by} is shown in Table 2.

[0188] Table 2. List of data identifiers with two-byte nested variations

[0189]

[0190] As shown in Table 2, the above rule description object defines 24 double-nested changing data identifiers (current electricity data, rate number is 1). The changing pattern of the data identifiers is as follows: the initial data code is 00000000, the inner loop is DI1 which increases from 00 to 04 and includes data block FF, and the outer loop is DI2 which increases from 00 to 03 and does not include data block.

[0191] This application provides a data identifier generation device based on a communication protocol. The data identifier generation device based on a communication protocol includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the data identifier generation method based on the communication protocol in the first embodiment described above.

[0192] The following is for reference. Figure 5 The diagram illustrates a structural schematic of a data identifier generation device based on a communication protocol suitable for implementing embodiments of this application. The data identifier generation device based on a communication protocol in the embodiments of this application may include various hardware and software components for implementing a data identifier generation method based on a communication protocol. Figure 5 The data identifier generation device based on the communication protocol shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0193] like Figure 5 As shown, the data identifier generation device based on the communication protocol may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the data identifier generation device based on the communication protocol. The processing unit 1001, the ROM 1002, and the RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the data identifier generation device based on the communication protocol to communicate wirelessly or wiredly with other devices to exchange data. Although the figures show data identifier generation devices based on the communication protocol with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0194] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0195] The data identifier generation device based on communication protocols provided in this application, employing the data identifier generation method based on communication protocols in the above embodiments, can solve the technical problem of low maintenance efficiency in current data identifier management methods. Compared with the prior art, the beneficial effects of the data identifier generation device based on communication protocols provided in this application are the same as those of the data identifier generation method based on communication protocols provided in the above embodiments, and other technical features in this data identifier generation device based on communication protocols are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0196] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

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

[0198] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the data identifier generation method based on the communication protocol in the above embodiments.

[0199] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0200] The aforementioned computer-readable storage medium may be included in a data identifier generation device based on a communication protocol; or it may exist independently and not be assembled into a data identifier generation device based on a communication protocol.

[0201] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a data identifier generation device based on a communication protocol, the data identifier generation device based on the communication protocol: acquires a data dictionary description file, the data dictionary description file including at least one rule description object; determines a base identifier, a variable byte index, a raw value, and a termination value based on the rule description object; determines a value sequence of corresponding bytes based on the raw value and the termination value; and iteratively replaces the raw byte corresponding to the variable byte index in the base identifier with the current value in the value sequence, thereby generating a target data identifier sequence.

[0202] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0203] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0204] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0205] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described data identifier generation method based on the communication protocol, thereby solving the technical problem of low maintenance efficiency in current data identifier management methods. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the data identifier generation method based on the communication protocol provided in the above embodiments, and will not be repeated here.

[0206] This application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the data identifier generation method based on the communication protocol as described above.

[0207] The computer program product provided in this application can solve the technical problem of low maintenance efficiency in current data identifier management methods. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the data identifier generation method based on communication protocols provided in the above embodiments, and will not be repeated here.

[0208] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent scope of this application.

[0209] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0210] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0211] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for generating data identification based on communication protocol, characterized in that, The method comprises the following steps: obtaining a data dictionary description file, the data dictionary description file comprising at least one rule description object; determining a basic identifier, a variable byte index, an original value and a termination value according to the rule description object; determining a value sequence of a corresponding byte according to the original value and the termination value; replacing the original byte corresponding to the variable byte index in the basic identifier with a current value in the value sequence in a loop, thereby generating a target data identifier sequence.

2. The method of claim 1, wherein the data identification is generated based on a communication protocol. Before the step of obtaining the data dictionary description file, the method further comprises the following steps: obtaining a historical data identifier set defined by a communication protocol; extracting an encoding rule from the historical data identifier set to generate at least one rule description object, the rule description object comprising a basic identifier, a variable byte index, an original value and a termination value; generating the data dictionary description file according to the rule description object.

3. The method of claim 2, wherein the data identification is generated based on a communication protocol. The step of extracting the encoding rule from the historical data identifier set to generate at least one rule description object comprises the following steps: performing clustering processing on the historical data identifier set to obtain one or more data identifier groups; aligning the data identifiers in each data identifier group with bytes respectively to form a corresponding byte matrix, wherein each row corresponds to a data identifier and each column corresponds to a byte position; determining a fixed byte column and a variable byte column based on the byte matrix; determining the basic identifier and the variable byte index according to the fixed byte column and the variable byte column, and taking the minimum value and the maximum value of the variable byte column in the byte matrix as the original value and the termination value respectively; generating the rule description object based on the basic identifier, the variable byte index, the original value and the termination value.

4. The method of claim 3, wherein the data identification is generated based on a communication protocol. The step of determining the fixed byte column and the variable byte column based on the byte matrix comprises the following steps: determining the number of different byte values contained in each column of the byte matrix; if the number of different byte values is greater than a preset threshold, determining the corresponding column as the variable byte column, otherwise, determining the corresponding column as the fixed byte column.

5. The method of claim 1, wherein the data identification is generated based on a communication protocol. The step of determining a value sequence of a corresponding byte according to the original value and the termination value comprises the following steps: obtaining a byte encoding type and a preset step length of the original byte corresponding to the variable byte index; generating intermediate values in the direction of the termination value from the original value as a starting reference according to the preset step length based on the byte encoding type, until covering the termination value, to obtain an initial value sequence; performing encoding format conversion on each intermediate value in the initial value sequence to obtain the value sequence, the first and last values of the value sequence being the same as the original value and the termination value respectively; if the original value is equal to the termination value, taking the original value as the only element to obtain a single-element value sequence.

6. The method of claim 1, wherein the data identification is generated based on a communication protocol. The step of replacing the original byte corresponding to the variable byte index in the basic identifier with a current value in the value sequence in a loop, thereby generating a target data identifier sequence, comprises the following steps: traverse the value sequence corresponding to the rule description object, and set a current value pointer, the current value pointer initially pointing to a starting element of the value sequence; based on the variable byte index, locate a variable byte position in the base identifier, loop to read the current value pointed to by the current value pointer, and replace the original byte at the variable byte position in the base identifier with the current value, to obtain a target data identifier; move the current value pointer to a next element of the value sequence, until the current value pointer points to a boundary of the value sequence, to terminate the loop, and generate the target data identifier sequence corresponding to the rule description object.

7. The method of claim 6, wherein the data identification is generated based on a communication protocol. The step of moving the current value pointer to a next element of the value sequence, until the current value pointer points to a boundary of the value sequence, to terminate the loop, and generate the target data identifier sequence corresponding to the rule description object includes: If there is a data block parameter in the rule description object, after the loop ends, generate a corresponding data block data identifier according to the value of the data block parameter and the base identifier; append the data block data identifier to the target data identifier sequence.

8. The method of claim 6, wherein the data identification is generated based on a communication protocol. After the step of based on the variable byte index, locating a variable byte position in the base identifier, loop to read the current value pointed to by the current value pointer, and replace the original byte at the variable byte position in the base identifier with the current value, to obtain a target data identifier, the communication protocol based data identifier generation method further includes: If there is a nesting level parameter in the rule description object, parse the nesting level parameter into a sub-loop parameter, the sub-loop parameter including an independent sub-loop variable byte index, a sub-loop original value, and a sub-loop termination value; in each round of loop, after generating the current target data identifier, perform an inner loop, move a sub-loop current value pointer according to the sub-loop parameter, until traverse a sub-loop value sequence determined by the sub-loop original value and the sub-loop termination value, to generate a second target data identifier based on the current target data identifier; when the inner loop ends, move the current value pointer to a next element of the value sequence, until the current value pointer points to a boundary of the value sequence, and terminate the loop corresponding to the end of the inner loop; generate the target data identifier sequence corresponding to the rule description object based on the second target data identifier.

9. A data identification generating apparatus based on a communication protocol, characterized by The communication protocol based data identifier generation device includes a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the communication protocol based data identifier generation method according to any one of claims 1 to 8.

10. A storage medium, characterized by The storage medium is a computer readable storage medium, and the storage medium stores a computer program, the computer program being executed by the processor to implement the steps of the communication protocol based data identifier generation method according to any one of claims 1 to 8.

Images