Register multi-byte sequence conversion and encoding method, device and electronic equipment

Abstract

This application provides a register multi-byte order conversion and encoding method, apparatus, and electronic device, applicable to the Industrial Internet of Things (IIoT) field. The method reads descriptor strings of each data object from a configuration database to obtain data type and byte order identifiers; determines the required number of registers and caches the parsing results in memory objects; during uplink encoding, the string values ​​of the device's uplink data are parsed into native type variables; the memory byte representation of the native type variables is obtained, and according to the byte order identifier, a preset unified byte order conversion function is called to perform byte position permutation on the memory byte representation, resulting in a converted byte stream conforming to the target byte order; during downlink decoding, the byte stream to be decoded is read, and the unified byte order conversion function is called again to perform byte position permutation on the byte stream; the unified byte order conversion function performs this permutation twice on the same input, resulting in an output that is identical to the input, thereby improving the encoding and decoding efficiency of the byte order.

Description

Technical Field

[0001] This application relates to the field of industrial Internet of Things (IoT) technology, and in particular to a register multi-byte order conversion and encoding method, apparatus and electronic device. Background Technology

[0002] In communication protocols used in industrial automation, registers typically store data in 16-bit units. When representing multiple register data types, such as 32-bit integers, 32-bit floating-point numbers, and 64-bit double-precision floating-point numbers, multiple 16-bit registers need to be combined according to a specific byte order. However, in related technologies, communication protocols only define the read and write operations of registers, without specifying their byte order. This leads to different types of devices potentially using different byte orders, resulting in low encoding and decoding efficiency. Summary of the Invention

[0003] The purpose of this application is to provide a method, apparatus, and electronic device for register multi-byte order conversion and encoding, so as to improve the encoding and decoding efficiency of byte order. The specific technical solution is as follows: In a first aspect of this application, a register multi-byte order conversion and encoding method is provided, the method comprising: When the gateway starts up or receives a device configuration update instruction, it reads the descriptor string of each data object from the configuration database, wherein the descriptor string includes a data type identifier and a byte order identifier; The descriptor string is parsed to obtain the data type identifier and the byte order identifier of the data object; The required number of registers is determined according to the data type identifier, and the data type identifier, the byte order identifier, and the number of registers are cached as parsing results in a memory object for direct reference in subsequent encoding and decoding processes. When receiving uplink data from the device and performing uplink encoding, the string value of the uplink data is parsed into a primitive type variable corresponding to the data type identifier; the memory byte representation of the primitive type variable is obtained; according to the byte order identifier cached in the memory object, a preset unified byte order conversion function is called to perform byte position substitution on the memory byte representation to obtain a converted byte stream that conforms to the target byte order; and the converted byte stream is written into the register mapping area according to the number of registers occupied. When performing downlink decoding, the byte stream to be decoded is read from the register mapping area, and the unified byte order conversion function is called again to perform the byte position substitution on the byte stream to restore the byte stream to a native type variable of host byte order; The unified byte order conversion function performs a deterministic byte position permutation for each byte order identifier, and the output is the same as the input after the permutation is performed twice consecutively on the same input, so that the uplink encoding and downlink decoding share the conversion function and structurally ensure the round-trip consistency of encoding and decoding.

[0004] In one possible implementation, the format of the descriptor string is: {data type identifier}_{byte order identifier}, wherein the data type identifier and the byte order identifier are separated by an underscore; The parsing of the descriptor string includes: The descriptor string is split using underscores as delimiters to obtain the data type identifier and the byte order identifier.

[0005] In one possible implementation, obtaining the memory byte representation of the primitive type variable involves calling a preset unified byte order conversion function according to the byte order identifier cached in the memory object to perform byte position substitution on the memory byte representation, including: When the data type identifier indicates that the data type is a floating-point type, the primitive type variable is formatted into a string with a specified precision according to the specified precision format; The string with the specified precision is parsed into a floating-point variable. According to the byte order identifier cached in the memory object, a preset unified byte order conversion function is called to perform byte position substitution on the floating-point variable.

[0006] In one possible implementation, the preset unified byte order conversion function includes: When the byte order identifier is AB / ABCD / BADC / CDAB / BE, the byte position permutation is performed on the memory byte representation according to the inverse permutation; When the byte order identifier is BA / DCBA / LE, byte position permutation is performed on the memory byte representation according to the identity mapping.

[0007] In one possible implementation, formatting the primitive type variable into a string with a specified precision according to a specified precision format includes: For the primitive type variable whose data type is identified as float32, format it as a string with 3 decimal places; For the primitive type variable whose data type is identified as float64, format it as a string with 6 decimal places.

[0008] In one possible implementation, determining the required register usage based on the data type identifier includes: When the data type identifier indicates a 16-bit type, the required number of registers is determined to be 1; When the data type identifier is represented as a 32-bit type, the required number of registers is determined to be 2; When the data type identifier is represented as a 64-bit type, the required number of registers is determined to be 4.

[0009] In one possible implementation, after writing the converted byte stream into the register mapping area, the method further includes: The converted byte stream is then converted into a hexadecimal string for storage.

[0010] In one possible implementation, the register is a register in any of the following industrial communication protocols: Modbus protocol, BACnet protocol, OPC UA protocol, or EtherNet / IP protocol; the byte position permutation and the unified byte order conversion function are independent of the protocol type and adapt to the byte order conversion of multi-byte data in each protocol.

[0011] In a second aspect of this application, a register multi-byte order conversion and encoding apparatus is provided, the apparatus comprising: The descriptor reading module is used to read the descriptor strings of each data object from the configuration database when the gateway starts up or receives a device configuration update instruction. The descriptor strings include data type identifiers and byte order identifiers. The descriptor parsing module is used to parse the descriptor string to obtain the data type identifier and the byte order identifier of the data object; The register usage quantity determination module is used to determine the required register usage quantity according to the data type identifier, and cache the data type identifier, the byte order identifier, and the register usage quantity as parsing results in a memory object for direct reference in subsequent encoding and decoding processes; The uplink encoding module is used to, when receiving uplink data from the device for uplink encoding, parse the string value of the uplink data from the device into a primitive type variable corresponding to the data type identifier; obtain the memory byte representation of the primitive type variable; call a preset unified byte order conversion function according to the byte order identifier cached in the memory object; perform byte position substitution on the memory byte representation to obtain a converted byte stream that conforms to the target byte order; and write the converted byte stream into the register mapping area according to the number of registers occupied. The downlink decoding module is used to read the byte stream to be decoded from the register mapping area when performing downlink decoding, and call the unified byte order conversion function again to perform the byte position substitution on the byte stream so as to restore the byte stream to the host byte order native type variable; The unified byte order conversion function performs a deterministic byte position permutation for each byte order identifier, and the output is the same as the input after the permutation is performed twice consecutively on the same input, so that the uplink encoding and downlink decoding share the conversion function and structurally ensure the round-trip consistency of encoding and decoding.

[0012] In one possible implementation, the format of the descriptor string is: {data type identifier}_{byte order identifier}, wherein the data type identifier and the byte order identifier are separated by an underscore; The descriptor parsing module is specifically used to split the descriptor string using underscores as delimiters to obtain the data type identifier and the byte order identifier.

[0013] In one possible implementation, the uplink encoding module includes: The floating-point number formatting submodule is specifically used to format the primitive type variable into a string with a specified precision according to the specified precision format when the data type identifier indicates that the data type is a floating-point type; The floating-point re-parsing submodule is specifically used to parse the string of the specified precision into a floating-point variable, and according to the byte order identifier cached in the memory object, call a preset unified byte order conversion function to perform byte position substitution on the floating-point variable.

[0014] In one possible implementation, the preset unified byte order conversion function includes: When the byte order identifier is AB / ABCD / BADC / CDAB / BE, the byte position permutation is performed on the memory byte representation according to the inverse permutation; When the byte order identifier is BA / DCBA / LE, byte position permutation is performed on the memory byte representation according to the identity mapping.

[0015] In one possible implementation, the floating-point formatting submodule includes: The 32-bit floating-point formatting unit is specifically used to format native type variables whose data type is identified as float32 into strings that retain 3 decimal places. The 64-bit floating-point formatting unit is specifically used to format native type variables whose data type is identified as float64 into strings that retain 6 decimal places.

[0016] In one possible implementation, the register occupancy determination module includes: The 16-bit data register occupancy determination submodule is specifically used to determine that the required number of registers is 1 when the data type identifier represents a 16-bit type. The 32-bit data register occupancy determination submodule is specifically used to determine that the required number of registers is 2 when the data type identifier is represented as 32-bit. The 64-bit data register occupancy determination submodule is specifically used to determine that the required number of registers is 4 when the data type identifier is represented as 64-bit.

[0017] In one possible implementation, the device further includes: The byte stream storage module is used to convert the converted byte stream into a hexadecimal string for storage.

[0018] In one possible implementation, the register is a register in any of the following industrial communication protocols: Modbus protocol, BACnet protocol, OPC UA protocol, or EtherNet / IP protocol; the byte position permutation and the unified byte order conversion function are independent of the protocol type and adapt to the byte order conversion of multi-byte data in each protocol.

[0019] In a third aspect of this application, an electronic device is provided, comprising: Memory, used to store computer programs; When a processor executes a program stored in memory, it implements the method described in the first aspect of the embodiments of this application.

[0020] In a fourth aspect of the present application, a computer-readable storage medium is provided, wherein a computer program is stored therein, and the computer program, when executed by a processor, implements the method described in the first aspect of the present application.

[0021] Compared with the prior art, the embodiments of this application have at least the following technical effects: This application provides a register multi-byte order conversion and encoding method, apparatus, and electronic device. The method includes: when a gateway is started or a device configuration update instruction is received, reading descriptor strings of each data object from a configuration database, wherein the descriptor string includes a data type identifier and a byte order identifier; parsing the descriptor string to obtain the data type identifier and the byte order identifier of the data object; determining the required register occupancy according to the data type identifier, and caching the data type identifier, the byte order identifier, and the register occupancy as parsing results in a memory object for direct reference in subsequent encoding and decoding processes; when receiving uplink data from the device for uplink encoding, parsing the string value of the uplink data from the device into a primitive type variable corresponding to the data type identifier; and obtaining the... The memory byte representation of the raw type variable is processed by calling a preset unified byte order conversion function according to the byte order identifier cached in the memory object. This function performs byte position permutation on the memory byte representation to obtain a converted byte stream that conforms to the target byte order. The converted byte stream is then written to the register mapping area according to the number of registers occupied. When performing downlink decoding, the byte stream to be decoded is read from the register mapping area, and the unified byte order conversion function is called again to perform the byte position permutation on the byte stream, thereby restoring the byte stream to the raw type variable in host byte order. The unified byte order conversion function performs deterministic byte position permutation for each byte order identifier, and the output is the same as the input after performing the permutation twice consecutively on the same input. This ensures that uplink encoding and downlink decoding share the conversion function and structurally guarantees round-trip consistency between encoding and decoding.

[0022] The method described in this application uses the same byte order conversion function for both uplink and downlink. Leveraging the reversibility of byte substitution operations (performing the same substitution twice on the same data to restore the original value), it structurally ensures round-trip consistency during encoding and decoding. The eight byte order variants require only eight conversion branches (instead of 16 independent functions), and the correctness of each branch only needs to be verified once. This reduces system maintenance costs while ensuring data encoding and decoding consistency and improving byte order conversion efficiency. Furthermore, by merging data type identifiers and byte order identifiers into a single atomic descriptor stored in the configuration database and dynamically parsed at runtime, adding new devices only requires configuring the descriptor field in the database without modifying any code, further reducing conversion efficiency during byte order conversion.

[0023] Of course, implementing any method of the embodiments of this application does not necessarily require achieving all of the advantages described above at the same time. Attached Figure Description To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0024] Figure 1 A flowchart of a register multi-byte order conversion and encoding method provided in an embodiment of this application; Figure 2 A timing diagram for uplink encoding of device uplink data provided in this application embodiment; Figure 3 This is a timing diagram for register multi-byte order conversion provided in an embodiment of this application; Figure 4 A schematic diagram of a register multi-byte order conversion and encoding device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0025] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art based on this application are within the scope of protection of this application.

[0026] In communication protocols used in industrial automation, registers typically store data in 16-bit units. When representing multiple register data types, such as 32-bit integers, 32-bit floating-point numbers, and 64-bit double-precision floating-point numbers, multiple 16-bit registers need to be combined according to a specific byte order. However, in related technologies, communication protocols only define the read and write operations of registers, without specifying their byte order. This leads to different types of devices potentially using different byte orders, resulting in low encoding and decoding efficiency.

[0027] In related technologies, byte order conversion can be achieved in the following ways: Solution A: Application layer hard-coded conversion.

[0028] For each device model, developers hard-code byte order conversion logic in the application code. For example, when interfacing with Siemens S7 series, they write an ABCD big-endian conversion function, and when interfacing with Schneider M340, they write a CDAB word swapping function.

[0029] However, in this approach, when the gateway needs to connect to more than eight different PLC devices from various manufacturers, each device requires independently written byte order conversion code. Adding a new device model requires modifying the source code and recompiling and deploying it, with a single connection taking 2.5 to 8 hours. In scenarios where the gateway manages 200+ device objects, this approach leads to code bloat, and maintenance costs increase linearly with the number of device types, resulting in low byte order conversion efficiency.

[0030] Option B: Built-in conversion in the Modbus protocol library.

[0031] Data reading interfaces provided by open-source libraries such as libmodbus and pymodbus rely on the library's internal byte order processing. These libraries typically only support a single byte order determined at compile time (usually network byte order / big endianness).

[0032] However, this method does not support dynamic switching based on the device at runtime. For 32-bit data, it only supports one byte order, ABCD, and cannot handle the three common industrial variants: BADC, CDAB, and DCBA. For 64-bit data types (float64, int64, uint64), these libraries do not provide any encoding or decoding support, while high-precision metering scenarios (electricity metering, flow accumulation) require 64-bit precision. This makes it impossible to convert the byte order of 64-bit data, resulting in low conversion efficiency.

[0033] Option C: Uplink and downlink separate encoding and decoding.

[0034] Uplink (device → platform) and downlink (platform → device) implement independent encoding and decoding functions, each handling byte order conversion. libmodbus provides two independent functions: modbus_set_float_abcd() (encoding write) and modbus_get_float_abcd() (decoding read), with their internal byte operation logic implemented separately. pymodbus provides two independent classes: BinaryPayloadBuilder (encoding class) and BinaryPayloadDecoder (decoding class), with byte order processing code for encoding and decoding distributed across different class methods.

[0035] However, in this scheme, if the uplink encoding function and the downlink decoding function are written by different developers or at different times, slight differences in the byte order conversion logic can lead to inconsistencies between the values ​​written uplink and read downlink. The two functions implement byte order conversion logic independently, with consistency verified only through testing. When the number of byte order variants increases from 1 to 8, 8 pairs (16 independent functions) need to be maintained, and the consistency risk increases linearly with the number of functions. In the float32 type scenario, floating-point precision drift causes the uplink value 123.456 to become 123.45600128 after encoding and decoding, triggering false change alarms in the SCADA system, generating approximately 1700 redundant alarms per day in gateways with 200 floating-point objects. Therefore, not only is the byte order conversion inefficient, but the maintenance cost is also correspondingly high, and there are numerous redundant alarms.

[0036] To address at least one of the aforementioned problems, a first aspect of this application provides a register multi-byte order conversion and encoding method, the method comprising: Figure 1 The steps shown are as follows: Step S101: When the gateway starts up or receives a device configuration update instruction, read the descriptor strings of each data object from the configuration database.

[0037] Upon gateway startup or receipt of a device configuration update command, the system enters the initialization phase. This phase involves loading atomic descriptors, parsing the data type and byte order of each data object, generating descriptor strings, and storing them in the configuration database for later retrieval. The device configuration update command is triggered by detecting changes in the device's configuration information. This device refers to any device integrated with the communication protocol, such as a PLC (Programmable Logic Controller) or a SCADA (Supervisory Control and Data Acquisition) system. The gateway is used for data encoding and decoding, enabling uplink or downlink data transmission.

[0038] The descriptor string includes a data type identifier and a byte order identifier. The data type identifier indicates the data type and bit width of the data object. For example, a data type identifier of 32-bit integer indicates that the data object is an integer and has a bit width of 32 bits. The byte order identifier indicates the order of bytes in memory or network transmission for multi-byte data types (such as int (32-bit signed integer), short (16-bit signed integer), and float (floating-point number)). Examples of byte order identifiers include AB (most significant byte first), BA (least significant byte first), ABCD (most significant byte first), BADC (big-endian byte order), CDAB (byte order swapped first, then reversed within the word), DCBA (least significant byte first), BE (big-endian standard byte order), and LE (little-endian standard byte order).

[0039] Step S102: Parse the descriptor string to obtain the data type identifier and byte order identifier of the data object.

[0040] In practical applications, the format of a descriptor string is: {data type identifier}_{byte order identifier}, where the data type identifier and the byte order identifier are separated by an underscore. When parsing the descriptor string, it can be split using an underscore as the delimiter to obtain the data type identifier and the byte order identifier separately. For example, if the obtained descriptor string is {float32}_{ABCD}, then splitting it with an underscore yields the data type identifier as float32 (32-bit floating-point number) and the byte order identifier as ABCD.

[0041] In practical applications, if the byte order identifier of a data object is not obtained in advance, it can be matched using a known checksum. For example, the gateway writes π=3.14159 of float32 to the device, reads back the returned value, performs byte order decoding and matching one by one, determines the successfully matched byte order, and fills it into the byte order identifier in the descriptor string.

[0042] Step S103: Determine the required number of registers according to the data type identifier, and cache the data type identifier, byte order identifier, and number of registers as parsing results in a memory object for direct reference in subsequent encoding and decoding processes.

[0043] When determining the required number of registers based on the data type identifier, the number of registers can be determined according to the bit width attribute in the data type identifier. In one possible implementation, if the data type identifier represents a 16-bit type, the required number of registers is determined to be 1; if the data type identifier represents a 32-bit type, the required number of registers is determined to be 2; and if the data type identifier represents a 64-bit type, the required number of registers is determined to be 4.

[0044] Step S104: When receiving uplink data from the device and performing uplink encoding, the string value of the uplink data from the device is parsed into a primitive type variable corresponding to the data type identifier; the memory byte representation of the primitive type variable is obtained; according to the byte order identifier cached in the memory object, a preset unified byte order conversion function is called to perform byte position substitution on the memory byte representation to obtain a converted byte stream that conforms to the target byte order; and the converted byte stream is written to the register mapping area according to the number of registers occupied.

[0045] The upstream data from the device is in string format, and this string format is parsed into the corresponding primitive type variable. That is, the text-formatted numbers (such as "123", "3.14", "0x1A") are converted into primitive data types such as integers and floating-point numbers that can be directly calculated by the program. For example, it is parsed into the corresponding primitive type in C language. The memory byte representation of the primitive type variable can include the byte order of the primitive type variable in the host (the device sending the upstream data). According to its byte order identifier, a preset unified byte order conversion function is called to rearrange the bytes according to the target byte order corresponding to the byte order identifier, perform byte position substitution, and obtain a converted byte stream that conforms to the target byte order. This byte stream is then written to the register mapping area.

[0046] In addition, the converted byte stream can be stored in hexadecimal string format to enable change detection of the byte stream.

[0047] Step S105: When performing downlink decoding, read the byte stream to be decoded from the register mapping area, call the unified byte order conversion function again, perform byte position substitution on the byte stream, and restore the byte stream to the host byte order native type variable.

[0048] The unified byte order conversion function performs a deterministic byte position permutation for each byte order identifier, and the output is identical to the input after performing the permutation twice consecutively on the same input. This ensures that uplink encoding and downlink decoding share the conversion function and structurally guarantees round-trip consistency between encoding and decoding. In one example, the unified byte order conversion function can be generated using a constant mapping (f(x)=x) and / or a reversible permutation (f(f(x))=x), ensuring that the output is identical to the input after performing the permutation twice consecutively on the same input.

[0049] In another example, the unified byte order conversion function can be generated according to Table 1 below: Table 1

[0050] In the aforementioned unified byte order conversion function, for byte order identifiers of AB / ABCD / BADC / CDAB / BE, the input memory byte representation is subjected to byte position permutation according to the inverse permutation method; for byte order identifiers of BA / DCBA / LE, the input memory byte representation is subjected to byte position permutation according to the identity mapping method. This allows unified data to be restored to its original byte order after performing the same permutation operation twice, ensuring round-trip consistency during uplink and downlink encoding and decoding. Furthermore, the byte order conversion function in this embodiment fully supports three 64-bit data types: float64 (6 decimal places), int64, and uint64. It uses four consecutive registers for storage and supports both big-endian and little-endian byte orders, increasing data type coverage from approximately 70% (16 / 32 bits only) to 100% (including 64 bits), filling the technical gap in 64-bit Modbus encoding and decoding for industrial gateways.

[0051] In this process, step S104 corresponds to the uplink encoding process and step S105 corresponds to the downlink decoding process. In practical applications, steps S104 and S105 can be performed in any order. For example, in practical applications, the byte stream to be decoded can be read directly from the register mapping area for decoding.

[0052] The method described in this application uses the same byte order conversion function for both uplink and downlink. Leveraging the reversibility of byte substitution operations (performing the same substitution twice on the same data to restore the original value), it structurally ensures round-trip consistency during encoding and decoding. The eight byte order variants require only eight conversion branches (instead of 16 independent functions), and the correctness of each branch only needs to be verified once. This reduces system maintenance costs while ensuring data encoding and decoding consistency and improving byte order conversion efficiency. Furthermore, by merging data type identifiers and byte order identifiers into a single atomic descriptor stored in the configuration database and dynamically parsed at runtime, adding new devices only requires configuring the descriptor field in the database without modifying any code, further reducing conversion efficiency during byte order conversion.

[0053] In one possible implementation, after parsing the string value into a primitive type variable, if the data type is a floating-point type, the floating-point data can be processed by the following steps before byte position substitution: Step 1: When the data type identifier indicates that the data type is a floating-point type, format the primitive type variable into a string with the specified precision according to the specified precision format.

[0054] Step 2: Parse the string of specified precision into a floating-point variable, and call the preset unified byte order conversion function according to the byte order identifier cached in the memory object to perform byte position substitution on the floating-point variable.

[0055] The specified precision format can be determined based on the data type identifier. For example, for a primitive type variable with a data type identifier of float32, it is formatted as a string retaining 3 decimal places; for a primitive type variable with a data type identifier of float64, it is formatted as a string retaining 6 decimal places. That is, for a floating-point number with a bit width of 32 bits, the specified precision format is to retain 3 decimal places; for a floating-point number with a bit width of 64 bits, the specified precision format is to retain 6 decimal places.

[0056] In one example, floating-point number processing can be achieved through the following steps: Step 1: Parse the string value into a floating-point variable.

[0057] For example, the string value "123.456789" is parsed as the floating-point variable "123.456787109375". In this case, binary floating-point representation error is introduced.

[0058] Step 2: Format the floating-point variable as a string with the specified precision and truncate any excess precision.

[0059] Using the above data as an example, if the specified precision is to retain 3 decimal places, then "123.456787109375" will be truncated of the extra precision and formatted as "123.457".

[0060] Step 3: Re-parse the formatted string into floating-point variables. At this point, the floating-point values ​​are locked at the specified precision.

[0061] Using the above data as an example, the formatted "123.457" will be re-parsed as "123.457000".

[0062] In one possible implementation, the specified precision may not be fixed, but rather set as a parameter in the descriptor string. In this case, the descriptor string can be {data type identifier}_{byte order identifier}_{specified precision}. For example, if the descriptor string is float32_cdab_5, it means that the specified precision is to retain 5 decimal places.

[0063] By applying the method of this application embodiment, the floating-point value is precision locked to meet the specified precision and excess precision is truncated, thereby eliminating floating-point precision drift, ensuring that the value after encoding and decoding is completely consistent, and avoiding alarms caused by false changes.

[0064] In one example, such as Figure 2 The diagram shows the timing of uplink encoding of device data. The type resolver retrieves the device's uplink data (string-formatted numeric values), such as the string value "123.456," from the uplink data source and parses it into primitive type variables using the `sscanf` function (a function used to read formatted data from a string and parse it into primitive variables). In the case of floating-point values, the precision locker formats and reparses the raw floating-point value, locking its precision to a specified level, and sends the precision-locked byte representation to the byte order converter. The byte order converter calls a unified byte order conversion function to perform byte position substitution according to the target byte order, writes the generated converted byte stream into a register mapping area, and stores the converted byte stream as a hexadecimal string.

[0065] In practical applications, the registers in this embodiment can be registers in any of the following industrial communication protocols: Modbus (Modbus Application Protocol), BACnet (A Data Communication Protocol for Building Automation and Control Networks), OPC UA (Open Platform Communications Unified Architecture), or EtherNet / IP (Ethernet Industrial Protocol); the byte position permutation and the unified byte order conversion function are independent of the protocol type and adapt to the byte order conversion of multi-byte data in each protocol.

[0066] like Figure 3 The diagram shown is a timing diagram of register multi-byte order conversion in an embodiment of this application. The configuration database stores the descriptor string of the data object. The gateway codec engine is used to parse the descriptor string to obtain the data type identifier and byte order identifier, determine the number of registers occupied, and cache the parsing result in the memory object.

[0067] When IoT (Internet of Things) devices send uplink data, the gateway codec engine performs byte order conversion on the uplink data, writes the converted byte stream into the register mapping area, and stores a hex (Hexadecimal string) so that the client can read the converted byte stream from the register mapping area. If the uplink data is a floating-point number, the gateway codec engine also performs precision locking on the data.

[0068] During the downlink decoding process, the register is written to restore the downlink data from hex to byte stream, and the same preset unified byte order conversion function is called to perform reverse decoding, finally obtaining the downlink data and sending it to the IoT device.

[0069] When the data type of the uplink data is not identified, the gateway codec engine does not perform byte order conversion on the data, keeps the original value of the register, and records the alarm log to issue an alarm.

[0070] In a second aspect of this application, a register multi-byte order conversion and encoding apparatus is provided, the apparatus comprising as follows: Figure 4 The structure shown is as follows: The descriptor reading module 401 is used to read the descriptor strings of each data object from the configuration database when the gateway starts up or receives a device configuration update instruction. The descriptor strings include data type identifiers and byte order identifiers.

[0071] The descriptor parsing module 402 is used to parse the descriptor string to obtain the data type identifier and byte order identifier of the data object.

[0072] The register usage quantity determination module 403 is used to determine the required number of registers according to the data type identifier, and cache the data type identifier, byte order identifier and register usage quantity as parsing results in a memory object for direct reference in subsequent encoding and decoding processes.

[0073] The uplink encoding module 404 is used to parse the string value of the device uplink data into a primitive type variable corresponding to the data type identifier when receiving uplink data from the device for uplink encoding; obtain the memory byte representation of the primitive type variable; call the preset unified byte order conversion function according to the byte order identifier cached in the memory object; perform byte position substitution on the memory byte representation to obtain the converted byte stream that conforms to the target byte order; and write the converted byte stream into the register mapping area according to the number of registers occupied.

[0074] Downlink decoding module 405 is used to read the byte stream to be decoded from the register mapping area when performing downlink decoding, and then call the unified byte order conversion function again to perform byte position substitution on the byte stream to restore the byte stream to the host byte order native type variable.

[0075] The unified byte order conversion function performs a deterministic byte position permutation for each byte order identifier, and the output is the same as the input after the permutation is performed twice consecutively on the same input, so that the uplink encoding and downlink decoding share the conversion function and structurally ensure the consistency of encoding and decoding round trip.

[0076] In one possible implementation, the descriptor string is formatted as: {data type identifier}_{byte order identifier}, where the data type identifier and the byte order identifier are separated by an underscore; The descriptor parsing module is specifically used to split the descriptor string using underscores as delimiters to obtain the data type identifier and byte order identifier.

[0077] In one possible implementation, the uplink encoding module includes: The floating-point number formatting submodule is specifically used to format primitive type variables into strings of a specified precision when the data type identifier indicates that the data type is floating-point. The floating-point re-parsing submodule is specifically used to parse strings of a specified precision into floating-point variables. According to the byte order identifier cached in the memory object, it calls a preset unified byte order conversion function to perform byte position substitution on the floating-point variables.

[0078] In one possible implementation, a predefined unified byte order conversion function is provided, including: When the byte order is identified as AB / ABCD / BADC / CDAB / BE, the byte position is replaced by the memory byte representation according to the self-reverse permutation. When the byte order identifier is BA / DCBA / LE, byte position permutation is performed on the memory byte representation according to the identity mapping.

[0079] In one possible implementation, the floating-point formatting submodule includes: The 32-bit floating-point formatting unit is specifically used to format native type variables with the data type identifier of float32 into strings that retain 3 decimal places. The 64-bit floating-point formatting unit is specifically used to format primitive type variables with the data type identifier float64 into strings that retain 6 decimal places.

[0080] In one possible implementation, the register occupancy determination module includes: The 16-bit data register usage determination submodule is specifically used to determine that the required number of registers is 1 when the data type identifier indicates a 16-bit type. The 32-bit data register usage determination submodule is specifically used to determine that the required number of registers is 2 when the data type identifier is represented as 32-bit. The 64-bit data register usage determination submodule is specifically used to determine the required number of registers to be 4 when the data type identifier is represented as 64-bit.

[0081] In one possible implementation, the device further includes: The byte stream storage module is used to convert the byte stream into a hexadecimal string for storage.

[0082] In one possible implementation, the register is a register in any of the following industrial communication protocols: Modbus, BACnet, OPC UA, or EtherNet / IP; the byte position permutation and unified byte order conversion functions are independent of the protocol type and adapt to the byte order conversion of multi-byte data in each protocol.

[0083] In a third aspect of the embodiments of this application, an electronic device is provided, see [link to relevant documentation]. Figure 5 ,include: Memory 501 is used to store computer programs; Processor 502, when executing a program stored in memory, implements: When the gateway starts up or receives a device configuration update instruction, it reads the descriptor string of each data object from the configuration database. The descriptor string includes a data type identifier and a byte order identifier. Parse the descriptor string to obtain the data type identifier and byte order identifier of the data object; The required number of registers is determined according to the data type identifier. The data type identifier, byte order identifier, and number of registers are cached as parsing results in a memory object for direct reference in subsequent encoding and decoding processes. When receiving uplink data from the device and performing uplink encoding, the string value of the uplink data is parsed into a primitive type variable corresponding to the data type identifier; the memory byte representation of the primitive type variable is obtained; according to the byte order identifier cached in the memory object, a preset unified byte order conversion function is called to perform byte position substitution on the memory byte representation, so as to obtain a converted byte stream that conforms to the target byte order, and the converted byte stream is written to the register mapping area according to the number of registers occupied; When performing downlink decoding, the byte stream to be decoded is read from the register mapping area, and the unified byte order conversion function is called again to perform byte position substitution on the byte stream in order to restore the byte stream to a native type variable in host byte order; The unified byte order conversion function performs a deterministic byte position permutation for each byte order identifier, and the output is the same as the input after the permutation is performed twice consecutively on the same input, so that the uplink encoding and downlink decoding share the conversion function and structurally ensure the consistency of encoding and decoding round trip.

[0084] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0085] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0086] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0087] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0088] In a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when the computer program is executed by a processor, it implements the method of the first aspect of the embodiments of this application.

[0089] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to implement the method of the first aspect of the embodiments of this application.

[0090] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a solid-state drive (SSD), etc.

[0091] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus 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 apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0092] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. Related parts can be found in the descriptions of the system embodiments.

[0093] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.

Claims

1. A method for register multi-byte order conversion and encoding, characterized in that, The method includes: When the gateway starts up or receives a device configuration update instruction, it reads the descriptor string of each data object from the configuration database, wherein the descriptor string includes a data type identifier and a byte order identifier; The descriptor string is parsed to obtain the data type identifier and the byte order identifier of the data object; The required number of registers is determined according to the data type identifier, and the data type identifier, the byte order identifier, and the number of registers are cached as parsing results in a memory object for direct reference in subsequent encoding and decoding processes. When receiving uplink data from the device and performing uplink encoding, the string value of the uplink data is parsed into a primitive type variable corresponding to the data type identifier; the memory byte representation of the primitive type variable is obtained; according to the byte order identifier cached in the memory object, a preset unified byte order conversion function is called to perform byte position substitution on the memory byte representation to obtain a converted byte stream that conforms to the target byte order; and the converted byte stream is written into the register mapping area according to the number of registers occupied. When performing downlink decoding, the byte stream to be decoded is read from the register mapping area, and the unified byte order conversion function is called again to perform the byte position substitution on the byte stream to restore the byte stream to a native type variable of host byte order; The unified byte order conversion function performs a deterministic byte position permutation for each byte order identifier, and the output is the same as the input after the permutation is performed twice consecutively on the same input, so that the uplink encoding and downlink decoding share the conversion function and structurally ensure the round-trip consistency of encoding and decoding.

2. The method according to claim 1, characterized in that, The format of the descriptor string is: {data type identifier}_{byte order identifier}, where the data type identifier and the byte order identifier are separated by an underscore; The parsing of the descriptor string includes: The descriptor string is split using underscores as delimiters to obtain the data type identifier and the byte order identifier.

3. The method according to claim 1, characterized in that, The step of obtaining the memory byte representation of the primitive type variable involves calling a preset unified byte order conversion function to perform byte position substitution on the memory byte representation according to the byte order identifier cached in the memory object, including: When the data type identifier indicates that the data type is a floating-point type, the primitive type variable is formatted into a string with a specified precision according to the specified precision format; The string with the specified precision is parsed into a floating-point variable. According to the byte order identifier cached in the memory object, a preset unified byte order conversion function is called to perform byte position substitution on the floating-point variable.

4. The method according to claim 1, characterized in that, The preset unified byte order conversion function includes: When the byte order identifier is AB / ABCD / BADC / CDAB / BE, the byte position permutation is performed on the memory byte representation according to the inverse permutation; When the byte order identifier is BA / DCBA / LE, byte position permutation is performed on the memory byte representation according to the identity mapping.

5. The method according to claim 3, characterized in that, The step of formatting the primitive type variable into a string with a specified precision according to a specified precision format includes: For the primitive type variable whose data type is identified as float32, format it as a string with 3 decimal places; For the primitive type variable whose data type is identified as float64, format it as a string with 6 decimal places.

6. The method according to claim 1, characterized in that, Determining the required register usage based on the data type identifier includes: When the data type identifier indicates a 16-bit type, the required number of registers is determined to be 1; When the data type identifier is represented as a 32-bit type, the required number of registers is determined to be 2; When the data type identifier is represented as a 64-bit type, the required number of registers is determined to be 4.

7. The method according to claim 1, characterized in that, After writing the converted byte stream into the register mapping area, the method further includes: The converted byte stream is then converted into a hexadecimal string for storage.

8. The method according to claim 1, characterized in that, The register is a register in any of the following industrial communication protocols: Modbus protocol, BACnet protocol, OPC UA protocol, or EtherNet / IP protocol; the byte position permutation and the unified byte order conversion function are independent of the protocol type and adapt to the byte order conversion of multi-byte data in each protocol.

9. A register multi-byte order conversion and encoding device, characterized in that, The device includes: The descriptor reading module is used to read the descriptor strings of each data object from the configuration database when the gateway starts up or receives a device configuration update instruction. The descriptor strings include data type identifiers and byte order identifiers. The descriptor parsing module is used to parse the descriptor string to obtain the data type identifier and the byte order identifier of the data object; The register usage quantity determination module is used to determine the required register usage quantity according to the data type identifier, and cache the data type identifier, the byte order identifier, and the register usage quantity as parsing results in a memory object for direct reference in subsequent encoding and decoding processes; The uplink encoding module is used to, when receiving uplink data from the device for uplink encoding, parse the string value of the uplink data from the device into a primitive type variable corresponding to the data type identifier; obtain the memory byte representation of the primitive type variable; call a preset unified byte order conversion function according to the byte order identifier cached in the memory object; perform byte position substitution on the memory byte representation to obtain a converted byte stream that conforms to the target byte order; and write the converted byte stream into the register mapping area according to the number of registers occupied. The downlink decoding module is used to read the byte stream to be decoded from the register mapping area when performing downlink decoding, and call the unified byte order conversion function again to perform the byte position substitution on the byte stream so as to restore the byte stream to the host byte order native type variable; The unified byte order conversion function performs a deterministic byte position permutation for each byte order identifier, and the output is the same as the input after the permutation is performed twice consecutively on the same input, so that the uplink encoding and downlink decoding share the conversion function and structurally ensure the round-trip consistency of encoding and decoding.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method described in any one of claims 1-8.

Images