Modbus protocol and broadband industrial bus AUTBUS-PA protocol conversion gateway implementation method and system

Abstract

The invention discloses a modbus protocol and broadband industrial bus AUTBUS-PA protocol conversion gateway implementation method and system, and relates to the technical field of industrial communication, and the method comprises the steps: loading an AUTBUS-PA equipment description XML file in gateway equipment; analyzing an AUTBUS-PA equipment description XML file, and extracting a field identifier, a semantic tag and a data direction attribute of each real-time data field; respectively mapping the field identifier and the semantic tag to a Modbus register address and a register type, and generating a point table mapping relation; constructing a gateway configuration file, and generating an equipment description XML (Extensible Markup Language) file for AUTBUS-PA network configuration; the gateway configuration file is loaded to a Modbus master station protocol stack, and the gateway configuration file is registered to an AUTBUS-PA-S protocol stack; and receiving downlink real-time data issued by the AUTBUS-PA master station through the AUTBUS-PA-S protocol stack and writing the downlink real-time data into the register of the Modbus slave station according to the point table mapping relationship, and periodically reading the data of the register of the Modbus slave station through the protocol stack of the Modbus master station and uploading the data to the AUTBUS-PA master station according to the point table mapping relationship. According to the invention, the deployment efficiency, the communication certainty and the system compatibility are improved.

Description

Technical Field

[0001] This application relates to the field of industrial communication technology, and in particular to a method and system for implementing a Modbus protocol and a broadband industrial bus AUTBUS-PA protocol conversion gateway. Background Technology

[0002] The AUTBUS-PA broadband industrial bus protocol is a high-bandwidth, real-time industrial communication technology independently developed in my country for process automation. It is suitable for time-sensitive and highly reliable industrial control scenarios. By defining a network architecture of master station (M device), agent (P device), and slave station (S device), this technology constructs a complete industrial field communication system, providing a new generation of infrastructure support for industrial digitalization and intelligent upgrading.

[0003] However, many existing industrial sites still widely deploy existing equipment based on the Modbus protocol (including RTU and TCP). While the protocol structure is simple and highly compatible, it suffers from low bandwidth, poor real-time performance, and insufficient communication efficiency due to its underlying serial or Ethernet mechanisms, making it difficult to meet future high-dynamic control demands. Current technologies lack a conversion gateway capable of automatically aligning and enabling bidirectional transparent communication between AUTBUS-PA and Modbus protocols at the data model level, resulting in the two networks remaining isolated. Traditional protocol conversion schemes typically rely on manual configuration of point tables and static mapping registers, which are not only complex and error-prone to deployment but also unable to adapt to changes in device models, and struggle to guarantee deterministic and real-time communication. Therefore, there is an urgent need for a gateway implementation method that can automatically generate Modbus mapping relationships based on AUTBUS-PA device templates, collaboratively construct dual-protocol configurations, and achieve low-latency bidirectional data synchronization. This would break down the interoperability barriers between old and new industrial protocols, fully leveraging the synergistic value of AUTBUS-PA's high bandwidth and real-time advantages and Modbus's broad compatibility. Summary of the Invention

[0004] In view of the aforementioned problems, this application is hereby filed.

[0005] Therefore, this application provides a method and system for implementing a gateway to convert between Modbus protocol and broadband industrial bus AUTBUS-PA protocol, which can solve the problems mentioned in the background art.

[0006] To solve the above-mentioned technical problems, this application provides the following technical solution: In a first aspect, this application provides a method for implementing a gateway to convert between Modbus protocol and broadband industrial bus AUTBUS-PA protocol, including: loading an AUTBUS-PA device description XML file in the gateway device, wherein the AUTBUS-PA device description XML file contains a U16 type real-time data field, a field identifier of the real-time data field, and a semantic tag; Parse the AUTBUS-PA device description XML file and extract the field identifiers, semantic tags, and data direction attributes of each real-time data field; According to the preset mapping rules, the field identifiers and semantic tags are mapped to Modbus register addresses and register types respectively, generating a point table mapping relationship; Based on the point table mapping relationship, a gateway configuration file is constructed, and a device description XML file for AUTBUS-PA network configuration is generated; The gateway configuration file is loaded into the Modbus master protocol stack, and the device description XML file is registered into the AUTBUS-PA-S protocol stack. The system receives downlink real-time data from the AUTBUS-PA master station via the AUTBUS-PA-S protocol stack and writes it into the Modbus slave register according to the point table mapping relationship. At the same time, the system periodically reads data from the Modbus slave register via the Modbus master station protocol stack and uploads it to the AUTBUS-PA master station according to the point table mapping relationship to complete bidirectional data communication.

[0007] Preferably, the loading of the AUTBUS-PA device description XML file includes: After the gateway device starts up, it reads the locally stored AUTBUS-PA device description XML file, which is used to define the data model of the gateway as a slave device in the AUTBUS-PA network. Identify all U16 type real-time data fields from the AUTBUS-PA device description XML file. The U16 type real-time data field is a standard unsigned 16-bit integer data unit supported by the AUTBUS-PA protocol. Obtain the field identifier and semantic tag corresponding to each U16 type real-time data field. The field identifier is used to uniquely identify the real-time data field, and the semantic tag is used to characterize the physical meaning or functional purpose of the real-time data field.

[0008] Preferably, parsing the AUTBUS-PA device description XML file includes: The XML parsing module is invoked to perform structured parsing on the AUTBUS-PA device description XML file, locating the node region containing the real-time data field definition; Traverse each real-time data field node in the node region and read the field identifier, semantic label, and data direction attribute declared in that node; The read field identifiers, semantic tags, and data direction attributes are stored in a real-time data field list in memory in the form of structured records.

[0009] Preferably, the generation of the point table mapping relationship includes: Based on the content of the semantic tag, a preset semantic-register type mapping table is queried to determine the data operation semantics corresponding to each real-time data field. The data operation semantics include "readable and writable" or "read-only". Based on the data operation semantics, each real-time data field is mapped to a Modbus register type, where "readable and writable" semantics are mapped to a holding register and "read-only" semantics are mapped to an input register; if the semantic label contains the keywords "status", "switch", or "enable", the Modbus register type is corrected to a coil. A unique hash value is generated based on the character sequence of the field identifier, and a Modbus register address is allocated in a preset address pool based on the unique hash value. The preset address pool is divided into a holding register area, an input register area, and a coil area according to the register type. The addresses in each area are continuous and do not overlap. The field identifier, Modbus register type, and Modbus register address of each real-time data field are combined into a structured mapping record. All mapping records are sorted by field identifier and stored to form a point-to-point mapping relationship.

[0010] Preferably, generating the device description XML file for AUTBUS-PA network configuration includes: Based on the point table mapping relationship, extract the Modbus register address, register type and corresponding field identifier from each mapping record, and construct the access parameter table required for the Modbus master station to run. The access parameter table and Modbus communication parameters are encapsulated into structured data to generate a gateway configuration file. The Modbus communication parameters include slave ID, communication interface type, access period, and physical layer configuration information. Based on the field identifiers, semantic tags, and Modbus register types of each real-time data field in the point table mapping relationship, a device description XML file containing the definition of U16 type real-time data fields is generated according to the AUTBUS-PA row scale board format. The order of the real-time data fields in the device description XML file is consistent with the mapping relationship of the point table.

[0011] Preferably, registering the device description XML file to the AUTBUS-PA-S protocol stack includes: During the gateway device initialization phase, the gateway configuration file is read, the Modbus communication parameters and access parameter table are parsed, and the parsing result is passed to the configuration interface of the Modbus master protocol stack. The Modbus master protocol stack initializes the physical layer and link layer based on the Modbus communication parameters, and constructs an internal register mapping cache based on the access parameter table. The device description XML file is loaded into the AUTBUS-PA-S protocol stack, and the AUTBUS-PA-S protocol stack parses the device description XML file to determine the device capability set and the definition of the U16 type real-time data field. Based on the parsing results, the AUTBUS-PA-S protocol stack declares itself to the AUTBUS-PA master station as an S device that conforms to the AUTBUS-PA industry rules, and is ready to receive downlink real-time data and upload uplink real-time data.

[0012] Preferably, the completion of bidirectional data communication includes: The AUTBUS-PA-S protocol stack receives downlink real-time data frames sent by the AUTBUS-PA master station, parses out the values ​​of each U16 type real-time data field, and determines the Modbus register address and register type corresponding to each value according to the point table mapping relationship. The value of the downlink real-time data field is written to the corresponding address in the register mapping cache inside the Modbus master station protocol stack, and the Modbus master station protocol stack is triggered to perform a write operation, writing the cached data to the Modbus slave station register through the corresponding function code. The Modbus master station protocol stack reads data from the Modbus slave station registers sequentially according to a preset access cycle, and updates the corresponding address in the register mapping cache with the reading results. The AUTBUS-PA-S protocol stack extracts the values ​​corresponding to each U16 type real-time data field from the register mapping cache, encapsulates them into uplink real-time data frames, and uploads them to the AUTBUS-PA master station to complete bidirectional data communication.

[0013] Secondly, this application also provides a Modbus protocol and Broadband Industrial Bus AUTBUS-PA protocol conversion gateway implementation system, including: a loading module, used to load an AUTBUS-PA device description XML file in the gateway device, wherein the AUTBUS-PA device description XML file contains a U16 type real-time data field, a field identifier of the real-time data field, and a semantic tag; The parsing module is used to parse the AUTBUS-PA device description XML file and extract the field identifiers, semantic tags and data direction attributes of each real-time data field; The mapping module is used to map the field identifiers and semantic tags to Modbus register addresses and register types respectively according to preset mapping rules, and generate a point table mapping relationship; The configuration module is used to construct a gateway configuration file based on the point table mapping relationship and generate a device description XML file for AUTBUS-PA network configuration; The registration module is used to load the gateway configuration file into the Modbus master protocol stack and register the device description XML file into the AUTBUS-PA-S protocol stack. The communication module is used to receive downlink real-time data sent by the AUTBUS-PA master station through the AUTBUS-PA-S protocol stack and write it into the Modbus slave station register according to the point table mapping relationship. At the same time, it periodically reads the Modbus slave station register data through the Modbus master station protocol stack and uploads it to the AUTBUS-PA master station according to the point table mapping relationship to complete bidirectional data communication.

[0014] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps: The gateway device loads an AUTBUS-PA device description XML file, which contains a U16 type real-time data field, a field identifier for the real-time data field, and a semantic tag. Parse the AUTBUS-PA device description XML file and extract the field identifiers, semantic tags, and data direction attributes of each real-time data field; According to the preset mapping rules, the field identifiers and semantic tags are mapped to Modbus register addresses and register types respectively, generating a point table mapping relationship; Based on the point table mapping relationship, a gateway configuration file is constructed, and a device description XML file for AUTBUS-PA network configuration is generated; The gateway configuration file is loaded into the Modbus master protocol stack, and the device description XML file is registered into the AUTBUS-PA-S protocol stack. The system receives downlink real-time data from the AUTBUS-PA master station via the AUTBUS-PA-S protocol stack and writes it into the Modbus slave register according to the point table mapping relationship. At the same time, the system periodically reads data from the Modbus slave register via the Modbus master station protocol stack and uploads it to the AUTBUS-PA master station according to the point table mapping relationship to complete bidirectional data communication.

[0015] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps: The gateway device loads an AUTBUS-PA device description XML file, which contains a U16 type real-time data field, a field identifier for the real-time data field, and a semantic tag. Parse the AUTBUS-PA device description XML file and extract the field identifiers, semantic tags, and data direction attributes of each real-time data field; According to the preset mapping rules, the field identifiers and semantic tags are mapped to Modbus register addresses and register types respectively, generating a point table mapping relationship; Based on the point table mapping relationship, a gateway configuration file is constructed, and a device description XML file for AUTBUS-PA network configuration is generated; The gateway configuration file is loaded into the Modbus master protocol stack, and the device description XML file is registered into the AUTBUS-PA-S protocol stack. The system receives downlink real-time data from the AUTBUS-PA master station via the AUTBUS-PA-S protocol stack and writes it into the Modbus slave register according to the point table mapping relationship. At the same time, the system periodically reads data from the Modbus slave register via the Modbus master station protocol stack and uploads it to the AUTBUS-PA master station according to the point table mapping relationship to complete bidirectional data communication.

[0016] Implementing this application will have the following beneficial effects: This application provides a method and system for implementing a gateway that converts between Modbus protocol and broadband industrial bus AUTBUS-PA protocol. The gateway acts as a slave device (S device) in the AUTBUS-PA network and a master device in the Modbus network. It integrates an AUTBUS-PA-S protocol stack and a Modbus master protocol stack, which operate independently but achieve collaboration by sharing real-time data. A configuration tool is used to establish a one-to-one mapping relationship between the U16 type real-time data field in the AUTBUS-PA device template and the Modbus register, generating a gateway configuration file and a device description XML file conforming to AUTBUS PA standards. After the device starts up, the AUTBUS-PA-S protocol stack receives downlink real-time data sent by the master station and synchronizes it to the Modbus master protocol stack, which then writes it into the Modbus slave register. At the same time, the Modbus master protocol stack periodically reads the slave register data and sends it back to the AUTBUS-PA-S protocol stack, ultimately realizing bidirectional transparent data communication between the AUTBUS-PA master station and the Modbus slave station. This fully leverages the technical advantages of AUTBUS PA's high bandwidth, strong real-time performance, and deterministic communication while maintaining Modbus device compatibility. Attached Figure Description

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

[0018] Figure 1 This is an overall flowchart of a method for implementing a Modbus protocol and broadband industrial bus AUTBUS-PA protocol conversion gateway involved in this application; Figure 2 This is a computer device diagram illustrating a method for implementing a Modbus protocol and a broadband industrial bus AUTBUS-PA protocol conversion gateway, which is the subject of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0020] In one exemplary embodiment, such as Figure 1 As shown, a method for implementing a gateway to convert between Modbus protocol and broadband industrial bus AUTBUS-PA protocol is provided, wherein: S100: Load the AUTBUS-PA device description XML file in the gateway device. The AUTBUS-PA device description XML file contains U16 type real-time data fields, field identifiers of the real-time data fields, and semantic tags. S110: After the gateway device starts up, it reads the AUTBUS-PA device description XML file stored locally. The AUTBUS-PA device description XML file is used to define the data model of the gateway as a slave device in the AUTBUS-PA network. In an optional embodiment, the AUTBUS-PA device description XML file is pre-installed in the device's non-volatile memory before the gateway leaves the factory, and is automatically loaded into memory by the operating system during the device power-on initialization phase.

[0021] In an optional embodiment, the AUTBUS-PA device description XML file is generated by a host configuration tool during the engineering deployment phase and written to a specified storage path on the gateway device via USB, Ethernet, or serial port. The gateway reads the file from this path when it starts up.

[0022] In an optional embodiment, the gateway device first checks whether a valid AUTBUS-PA device description XML file exists during startup; if not, it enters a configuration waiting mode until it receives an externally sent XML file, completes loading, and continues the initialization process.

[0023] S120: Identify all U16 type real-time data fields from the AUTBUS-PA device description XML file. The U16 type real-time data field is a standard unsigned 16-bit integer data unit supported by the AUTBUS-PA protocol. In an optional embodiment, the gateway traverses the "RealtimeData" node of the AUTBUS-PA device description XML file using an XML parser, filters out all field nodes with the data type attribute "U16", and adds them to the real-time data field list.

[0024] In an optional embodiment, U16 type real-time data fields are declared in an XML file using a fixed tag format, such as <field type="U16" id="T101" / > The parsing module identifies the system based on the "type" attribute value being equal to "U16".

[0025] In an optional embodiment, if the AUTBUS-PA device description XML file contains non-U16 type fields (such as U32, BOOL), the gateway ignores these fields during the identification phase and only processes the U16 type real-time data fields to ensure alignment with the 16 bits of the Modbus register.

[0026] S130: Obtain the field identifier and semantic tag corresponding to each U16 type real-time data field. The field identifier is used to uniquely identify the real-time data field, and the semantic tag is used to characterize the physical meaning or functional purpose of the real-time data field. In an optional embodiment, the field identifier is the "id" attribute value in the XML node, and the semantic label is the "label" attribute value in the same node, for example... <field type="U16" id="P205" label="压力值" / > .

[0027] In an optional embodiment, the semantic tag is automatically filled by the configuration tool based on the annotation information in the Modbus point table when generating the XML file. For example, if Modbus register 40001 corresponds to "motor temperature", then the generated semantic tag is "motor temperature".

[0028] In an optional embodiment, if the XML node does not explicitly contain a semantic tag, the gateway uses the field identifier itself as the default semantic tag to ensure that the subsequent mapping rule engine can process all U16 type real-time data fields.

[0029] S200: Parse the AUTBUS-PA device description XML file and extract the field identifiers, semantic tags, and data direction attributes of each real-time data field; S210: Call the XML parsing module to perform structured parsing of the AUTBUS-PA device description XML file and locate the node area containing the real-time data field definition; In an optional embodiment, the XML parsing module is a lightweight DOM parser that loads the entire AUTBUS-PA device description XML file into memory during the gateway startup phase and locates the node area defined by the real-time data field according to the preset XPath path / DeviceModel / RealtimeData / Field.

[0030] In an optional embodiment, the AUTBUS-PA device description XML file follows the AUTBUS-PA row-scale board structure, where real-time data fields are uniformly defined in... <realtimedata>Within the tag, the XML parsing module determines the node region boundary by identifying the tag's start and end positions.

[0031] In an optional embodiment, if the AUTBUS-PA device description XML file does not exist... <realtimedata>If the node is empty, the XML parsing module returns an empty node area, and subsequent steps skip the data extraction process. The gateway enters an unmapped operation mode, maintaining only the basic communication functions of the protocol stack.

[0032] S220: Traverse each real-time data field node in the node region and read the field identifier, semantic label and data direction attribute declared in the node; In an optional embodiment, for each real-time data field node, the XML parsing module sequentially reads its id attribute as a field identifier, label attribute as a semantic label, and direction attribute as a data direction attribute, where the value of direction is either "input" or "output".

[0033] In an optional embodiment, if a real-time data field node is missing the label attribute, the semantic label is set to an empty string; if the direction attribute is missing, the default data direction attribute is "input", indicating that the field is used to receive data sent by the AUTBUS-PA master station.

[0034] In an optional embodiment, the gateway verifies the uniqueness of a field identifier when reading it. If a duplicate field identifier is found, an error log is recorded and the field is skipped to ensure the one-to-one correspondence of subsequent mapping relationships.

[0035] S230: Store the read field identifiers, semantic tags, and data direction attributes in a structured record format into a real-time data field list in memory. The real-time data field list is used for subsequent mapping processing. In an optional embodiment, the structured record is a C language structure containing three member variables: field_id (string type), semantic_label (string type), and data_direction (enumeration type). Each time a field is parsed, a structure instance is created and added to the linked list.

[0036] In an optional embodiment, the real-time data field list is sorted in memory lexicographically by field identifier so that the subsequent mapping rule engine can quickly locate the target field through binary search.

[0037] In an optional embodiment, the list of real-time data fields is constructed before the Modbus master station protocol stack is initialized, and is used as a global data structure for direct access by the mapping rule module in step S300, avoiding repeated parsing of XML files.

[0038] S300: According to the preset mapping rules, the field identifier and semantic label are mapped to the Modbus register address and register type respectively, generating a point table mapping relationship; S310: Based on the content of the semantic tag, query the preset semantic-register type mapping table to determine the data operation semantics corresponding to each real-time data field. The data operation semantics include "readable and writable" or "read-only". In an optional embodiment, a preset semantic-register type mapping table is stored in the gateway firmware in the form of key-value pairs, where the key is a semantic keyword (such as "set value" or "target temperature") and the value is "readable and writable"; the key is "measured value" or "feedback status" and the value is "read-only".

[0039] In an optional embodiment, if the semantic tag is "motor speed setting", then the keyword "setting" is matched and mapped to "readable and writable"; if it is "pipeline pressure measurement", then "measurement" is matched and mapped to "read-only".

[0040] In an optional embodiment, when a semantic tag does not contain any preset keywords, the system defaults its data operation semantics to "read-only" to ensure that the Modbus side will not perform write operations on unknown semantic fields, thereby improving system security.

[0041] S320: Based on data operation semantics, each real-time data field is mapped to a Modbus register type, where "read-write" semantics are mapped to a holding register, and "read-only" semantics are mapped to an input register; if the semantic label contains the keywords "status", "switch", or "enable", the Modbus register type is further modified to a coil. In an optional embodiment, for fields with a data operation semantic of "readable and writable", the initial mapping is a holding register (function code 03 / 06); if its semantic label also contains the word "enable" (such as "pump enable"), it is overridden as a coil type (function code 05).

[0042] In an optional embodiment, the system performs word segmentation on the semantic tags. If the segmentation result contains "switch" or "state" and the data operation semantic is "read-only", it is mapped to the coil type and marked as a read-only coil. The Modbus master station only uses function code 01 to read it.

[0043] In an optional embodiment, register type correction takes precedence over initial mapping: that is, regardless of the data operation semantics, as long as the semantic label contains any of the keywords "switch", "enable", or "start / stop", the final register type is forced to be coil.

[0044] S330: Generates a unique hash value based on the character sequence of the field identifier, and allocates a Modbus register address in the preset address pool according to the hash value. The address pool is divided into holding register area, input register area and coil area according to register type. The addresses in each area are continuous and do not overlap. In an optional embodiment, the BKDRHash algorithm is used to hash the field identifier (such as "T101") to obtain a 32-bit integer value, and then the modulo 1000 of the value is used to map it to the offset position of the corresponding register type address pool.

[0045] In an optional embodiment, the register area address range is maintained at 40001–49999, the input register area at 30001–39999, and the coil area at 00001–09999; the hash value is moduloed and then added to the starting address of each area to generate the final Modbus register address.

[0046] In an optional embodiment, if the hash mapping results in an address collision (i.e., two fields map to the same address), a linear probing method is used to sequentially search for the next free address in the address pool, and a collision log is recorded for debugging purposes.

[0047] S340: Combine the field identifier, Modbus register type and Modbus register address of each real-time data field into a structured mapping record, and store all mapping records in order of field identifier to form a point table mapping relationship; In an optional embodiment, each structured mapping record contains three fields: field_id (string), reg_type (enumeration value), and reg_addr (16-bit unsigned integer), stored in a dynamic array in memory.

[0048] In an optional embodiment, the mapping records are arranged in ascending order of the ASCII lexicographical order of the field identifiers, which facilitates the Modbus master protocol stack to quickly locate the register information corresponding to the target field through binary search.

[0049] In an optional embodiment, the point table mapping relationship is serialized into JSON format after generation and written to non-volatile memory as part of the gateway configuration file, so that it can be directly loaded and used after the device restarts, avoiding repeated parsing and mapping.

[0050] S400: Based on the point table mapping relationship, construct the gateway configuration file and generate a device description XML file for AUTBUS-PA network configuration; S410: Based on the point table mapping relationship, extract the Modbus register address, register type and corresponding field identifier from each mapping record, and construct the access parameter table required for the Modbus master station to run; In an optional embodiment, the access parameter table is organized as an array, with each element containing three items: Modbus register address (e.g., 40001), register type (e.g., "holding register"), and corresponding field identifier (e.g., "T101"), which are used by the Modbus master protocol stack to directly index during polling.

[0051] In an optional embodiment, the access parameter table is grouped by register type, first arranging all coils, then the input registers, and finally the holding registers. Within each group, the registers are arranged in ascending order of their addresses to reduce the number of Modbus function code switching and improve communication efficiency.

[0052] In an optional embodiment, if the register type of a certain mapping record is a coil, the access parameter table marks its access mode as "Write single coil (function code 05)" or "Read coil status (function code 01)", depending on the data direction attribute; the holding register is marked as "Read holding register (function code 03)" or "Write single register (function code 06)".

[0053] S420: Encapsulates the access parameter table and Modbus communication parameters into structured data to generate a gateway configuration file. The Modbus communication parameters include slave ID, communication interface type, access cycle, and physical layer configuration information. In an optional embodiment, the gateway configuration file is in JSON format. The top layer contains fields such as "modbus_slave_id", "interface_type" (with the value "RTU" or "TCP"), "polling_interval_ms", and "serial_baudrate", while the lower layer contains the "access_table" field to store the access parameter table.

[0054] In an optional embodiment, when the Modbus communication interface type is TCP, the gateway configuration file additionally includes the "slave_ip" and "slave_port" fields; when it is RTU, it includes serial port parameters such as "parity", "data_bits" and "stop_bits".

[0055] In an optional embodiment, the access period is set by the user in the configuration tool. If not set, it defaults to 500 milliseconds and is written to the "polling_interval_ms" field of the gateway configuration file for the Modbus master protocol stack to read and use after startup.

[0056] S430: Based on the field identifiers, semantic tags, and Modbus register types of each real-time data field in the point table mapping relationship, generate a device description XML file containing the definition of U16 type real-time data fields in the AUTBUS-PA row scale board format. In an optional embodiment, the root node of the device description XML file is <devicemodel>, which includes <deviceinfo>and <realtimedata>Nodes; each real-time data field in <realtimedata>It is declared in the form of <Fieldtype="U16" id="T101" label="Temperature value" / >, where type is fixed as "U16", id comes from the field identifier, and label comes from the semantic tag.

[0057] In an optional embodiment, if a certain field in the mapping relationship corresponds to the Modbus coil type, it is still declared as the U16 type in XML, but its original register type is marked through the extended attribute modbus_type="coil" for the AUTBUS-PA-S protocol stack to identify during data conversion.

[0058] In an optional embodiment, the device description XML file strictly follows the format requirements of the AUTBUS-PA profile for the S device template in GB / T 42019-2022 to ensure that it can be directly imported by the AUTBUS-PA configuration tool and the network topology construction can be completed.

[0059] S440: Keep the order of the real-time data fields in the device description XML file consistent with the point table mapping relationship to ensure that no additional index conversion is required when the AUTBUS-PA-S protocol stack and the Modbus master protocol stack exchange data; In an optional embodiment, the point table mapping relationship is stored as an ordered list in memory, and the <realtimedata>The order of fields within a node is exactly the same as the order of the list, ensuring that the i-th XML field is aligned in memory with the i-th Modbus register.

[0060] In an optional embodiment, the gateway allocates a contiguous memory buffer for real-time data fields at runtime. The i-th U16 unit of the buffer serves as both the upload data source for the AUTBUS-PA-S protocol stack and the register cache for the Modbus master protocol stack. This sequential consistency avoids the overhead of field lookups or hash mappings.

[0061] In an optional embodiment, if subsequent updates to the point table result in the addition or deletion of fields, the gateway shall force the original field order to remain unchanged when regenerating the device description XML file, and append the newly added fields to the end to maintain the stability of the runtime memory layout.

[0062] S500: Loads the gateway configuration file into the Modbus master protocol stack and registers the device description XML file into the AUTBUS-PA-S protocol stack; S510: Obtain all logical UKey instances from the subset of available logical UKey instances, and verify that the current state of each logical UKey instance is still idle; In an optional embodiment, the UKey sharing scheduling module traverses each logical UKey instance in the subset of available logical UKey instances, reads its runtime status field, and if the value of the status field is equal to the preset idle status constant, it is determined that the current status of the logical UKey instance is still idle.

[0063] In an optional embodiment, the state of each logical UKey instance is uniformly maintained by a distributed state service. The UKey sharing scheduling module queries the latest state of each instance in the subset of available logical UKey instances in batches through the state service client, and filters out the list of instances with a state value of "idle".

[0064] In an optional embodiment, the verification process includes timestamp verification: if the status update timestamp of a logical UKey instance is earlier than the current system time minus a preset status expiration window (e.g., 500 milliseconds), it is considered untrustworthy and excluded from the valid candidates even if its status field is "idle", in order to avoid resource conflicts caused by status synchronization delay.

[0065] S520: Based on a preset instance selection strategy, determine the target logical UKey instance from logical UKey instances whose verified status is idle; In an optional embodiment, the preset instance selection strategy is a polling strategy. The UKey sharing scheduling module maintains a polling pointer. Each time, it selects the next instance as the target logical UKey instance from the list of logical UKey instances that have been verified to be idle, according to the pointer position, and updates the polling pointer.

[0066] In an optional embodiment, the preset instance selection strategy is a performance-first strategy. The UKey sharing scheduling module sorts the verified idle instances in ascending order according to the historical average response latency of each logical UKey instance, and selects the instance ranked first as the target logical UKey instance.

[0067] In an optional embodiment, the preset instance selection strategy supports dynamic switching, and the strategy type is issued by the scheduling configuration center; if the strategy type is "nearby scheduling", the UKey shared scheduling module combines the IP address of the current bidding task initiator with the network topology distance of the physical node where each logical UKey instance is located, and selects the idle instance with the lowest network latency as the target logical UKey instance.

[0068] S530: Update the state of the target logical UKey instance to occupied, and establish a binding relationship between the target logical UKey instance and the session identifier of the current bidding task; In an optional embodiment, the UKey sharing scheduling module calls the interface of the status management module to update the status field of the target logical UKey instance to "occupied" and inserts a record in the binding relationship table, which contains the identifier of the target logical UKey instance and the session identifier of the current bidding task.

[0069] In an optional embodiment, the binding relationship is stored in an in-memory database as key-value pairs, where the key is the session identifier of the current bidding task and the value is the identifier of the target logical UKey instance; at the same time, the inverted index key is the identifier of the target logical UKey instance and the value is the session identifier, supporting bidirectional fast query.

[0070] In an optional embodiment, the state update and binding operations are executed in the same distributed transaction. If either operation fails, all changes are rolled back to ensure system state consistency. After the transaction is successfully committed, a resource binding event is generated and published to the audit message queue for subsequent monitoring and fault recovery.

[0071] S540: Based on the bidding process stage, determine the type of cryptographic operation to be performed, which is either a CA signature operation or a CA signature verification operation. In an optional embodiment, the UKey sharing scheduling module compares the stage type field value of the bidding process stage: if it is equal to "CA_SIGN", then the password operation type is determined to be a CA signature operation; if it is equal to "CA_VERIFY", then the password operation type is determined to be a CA verification operation.

[0072] In an optional embodiment, the password operation type is determined by a mapping table stored in a configuration file, with the content being {"CA_SIGN": "SIGN", "CA_VERIFY": "VERIFY"}; the UKey shared scheduling module queries the mapping table according to the bidding process stage and outputs the corresponding password operation type.

[0073] In an optional embodiment, the UKey sharing scheduling module verifies the integrity of the data to be processed while determining the type of cryptographic operation: if it is a CA signature operation, it checks whether the hash value of the data to be signed exists; if it is a CA verification operation, it verifies whether the digital signature field is not empty, and only allows the execution stage after the verification is passed.

[0074] S550: Call the password service interface of the target logical UKey instance, pass in the data to be processed and the password operation type, and perform CA signature operation or CA verification operation. In an optional embodiment, the target logical UKey instance encapsulates a cryptographic service proxy object. The UKey shared scheduling module calls its execute_crypto_operation(operation_type, input_data) method, passing in the cryptographic operation type and the data to be processed, which is then forwarded by the proxy object to the underlying physical UKey device for execution.

[0075] In an optional embodiment, the password service interface is a gRPC remote service. The UKey sharing scheduling module sends an encrypted gRPC request to the virtualized proxy node to which the target logical UKey instance belongs. The request body includes the password operation type, the data to be processed, and the session token. After verifying the token, the proxy node calls the local UKey driver to complete the operation.

[0076] In an optional embodiment, the execution process includes timeout control: the UKey shared scheduling module starts a timer, and if no operation result is received within a preset time limit (e.g., 10 seconds), the call is terminated, the target logical UKey instance is released, and the operation timeout exception is recorded; the operation result includes a signature value or a signature verification boolean result, which is returned to the bidding business engine.

[0077] S600: Receives downlink real-time data sent by the AUTBUS-PA master station through the AUTBUS-PA-S protocol stack and writes it into the Modbus slave station register according to the point table mapping relationship. At the same time, it periodically reads the Modbus slave station register data through the Modbus master station protocol stack and uploads it to the AUTBUS-PA master station according to the point table mapping relationship to complete bidirectional data communication.

[0078] S610: The AUTBUS-PA-S protocol stack receives downlink real-time data frames sent by the AUTBUS-PA master station, parses out the values ​​of each U16 type real-time data field, and determines the Modbus register address and register type corresponding to each value according to the point table mapping relationship. In an optional embodiment, the downlink real-time data frame sent by the AUTBUS-PA master station contains a sequence of U16 values ​​arranged in the order of the device description XML file. The AUTBUS-PA-S protocol stack obtains the corresponding Modbus register address and register type based on the offset position index point table mapping relationship of the field in the frame.

[0079] In an optional embodiment, if a field identifier in a downlink frame is "V205", the AUTBUS-PA-S protocol stack looks up the identifier in the dot table mapping relationship, obtains its corresponding Modbus register address as 40005, register type as holding register, and temporarily stores the value of the field in the 5th U16 unit of the internal mapping buffer.

[0080] In an optional embodiment, the AUTBUS-PA-S protocol stack checks whether the frame length is consistent with the number of real-time data fields defined in the device description XML when parsing downlink frames. If they are inconsistent, the frame is discarded and a communication error is reported to ensure the integrity of the data mapping.

[0081] S620: Writes the value of the downlink real-time data field to the corresponding address in the register mapping cache inside the Modbus master protocol stack, and triggers the Modbus master protocol stack to perform a write operation, writing the cached data to the Modbus slave register through the corresponding function code. In an optional embodiment, the Modbus master protocol stack maintains a register mapping cache aligned with the point table mapping. The AUTBUS-PA-S protocol stack writes downlink values ​​to a specified offset in this cache via shared memory and then sends a "write trigger signal" to the Modbus master protocol stack.

[0082] In an optional embodiment, after receiving the write trigger signal, the Modbus master protocol stack traverses all holding registers or coils marked as "to be written" and calls the corresponding function code (such as function code 06 to write a single register, function code 05 to write a single coil) to send the buffered data to the Modbus slave.

[0083] In an optional embodiment, if the Modbus slave returns a write operation failure response, the Modbus master protocol stack records the error log and retryes once. If it still fails, subsequent write operations on that register are frozen to prevent erroneous data from being continuously sent.

[0084] S630: The Modbus master protocol stack reads the data in the Modbus slave registers sequentially according to the preset access cycle, and updates the reading results to the corresponding address in the register mapping cache; In an optional embodiment, the Modbus master protocol stack performs a polling task every 500 milliseconds, sequentially sending function code 03 (read holding register), function code 04 (read input register), and function code 01 (read coil status) requests to the Modbus slave, and writes the returned data to the corresponding address in the register mapping cache.

[0085] In an optional embodiment, for holding registers with consecutive addresses (such as 40001–40010), the Modbus master protocol stack merges them into a single multi-register read request to reduce communication overhead and writes the returned 10 U16 values ​​in batches to consecutive locations in the cache.

[0086] In an optional embodiment, if a read times out or verification fails, the Modbus master protocol stack retains the original value in the cache and marks the register as "communication error" for upper-layer diagnostics, thus preventing invalid data from being uploaded to the AUTBUS-PA master.

[0087] S640: The AUTBUS-PA-S protocol stack extracts the values ​​corresponding to the real-time data fields of each U16 type from the register mapping cache, encapsulates them into uplink real-time data frames, and uploads them to the AUTBUS-PA master station to complete bidirectional data communication. In an optional embodiment, after receiving an uplink data request from the AUTBUS-PA master station, the AUTBUS-PA-S protocol stack reads the U16 values ​​sequentially from the register mapping cache according to the field order in the device description XML, assembles them into a continuous byte stream, and encapsulates them into a real-time data frame conforming to AUTBUS-PA standards.

[0088] In an optional embodiment, the field order of the uplink real-time data frame is strictly consistent with that of the downlink frame, ensuring that the AUTBUS-PA master station can read each field at a fixed offset without additional parsing, thereby improving communication determinism.

[0089] In an optional embodiment, the AUTBUS-PA-S protocol stack timestamps the cached data before uploading. If a field is detected to have not been updated in the last two periods, a "data stale" flag is set in the frame header for the AUTBUS-PA master station to perform status evaluation.

[0090] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0091] Based on the same inventive concept, this application also provides a Modbus protocol and Broadband Industrial Bus AUTBUS-PA protocol conversion gateway implementation system. The solution provided by this system is similar to the implementation scheme described in the above method. Therefore, the specific limitations of one or more Modbus protocol and Broadband Industrial Bus AUTBUS-PA protocol conversion gateway implementation system embodiments provided below can be found in the limitations of the Modbus protocol and Broadband Industrial Bus AUTBUS-PA protocol conversion gateway implementation method described above, and will not be repeated here.

[0092] In one exemplary embodiment, a Modbus protocol and Broadband Industrial Bus (AUTBUS-PA) protocol conversion gateway implementation system is provided, comprising: The loading module is used to load the AUTBUS-PA device description XML file in the gateway device. The AUTBUS-PA device description XML file contains U16 type real-time data fields, field identifiers of the real-time data fields, and semantic tags. The parsing module is used to parse the AUTBUS-PA device description XML file and extract the field identifiers, semantic tags, and data direction attributes of each real-time data field; The mapping module is used to map field identifiers and semantic tags to Modbus register addresses and register types according to preset mapping rules, and generate point table mapping relationships. The configuration module is used to build gateway configuration files based on point table mapping relationships and generate device description XML files for AUTBUS-PA network configuration; The registration module is used to load the gateway configuration file into the Modbus master protocol stack and register the device description XML file into the AUTBUS-PA-S protocol stack. The communication module is used to receive downlink real-time data sent by the AUTBUS-PA master station through the AUTBUS-PA-S protocol stack and write it into the Modbus slave station register according to the point table mapping relationship. At the same time, it periodically reads the Modbus slave station register data through the Modbus master station protocol stack and uploads it to the AUTBUS-PA master station according to the point table mapping relationship to complete bidirectional data communication.

[0093] The various modules in the Modbus protocol and Broadband Industrial Bus (AUTBUS-PA) protocol conversion gateway system can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0094] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 2 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When executed by the processor, the computer program implements a Modbus protocol and a broadband industrial bus AUTBUS-PA protocol conversion gateway implementation method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0095] Those skilled in the art will understand that Figure 2 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0096] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0097] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0098] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0099] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0100] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0101] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0102] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.< / realtimedata> < / realtimedata> < / realtimedata> < / deviceinfo> < / devicemodel> < / realtimedata> < / realtimedata>

Claims

1. A method for implementing a gateway to convert between Modbus protocol and broadband industrial bus AUTBUS-PA protocol, characterized in that, include: The gateway device loads an AUTBUS-PA device description XML file, which contains a U16 type real-time data field, a field identifier for the real-time data field, and a semantic tag. Parse the AUTBUS-PA device description XML file and extract the field identifiers, semantic tags, and data direction attributes of each real-time data field; According to the preset mapping rules, the field identifiers and semantic tags are mapped to Modbus register addresses and register types respectively, generating a point table mapping relationship; Based on the point table mapping relationship, a gateway configuration file is constructed, and a device description XML file for AUTBUS-PA network configuration is generated; The gateway configuration file is loaded into the Modbus master protocol stack, and the device description XML file is registered into the AUTBUS-PA-S protocol stack. The system receives downlink real-time data from the AUTBUS-PA master station via the AUTBUS-PA-S protocol stack and writes it into the Modbus slave register according to the point table mapping relationship. At the same time, the system periodically reads data from the Modbus slave register via the Modbus master station protocol stack and uploads it to the AUTBUS-PA master station according to the point table mapping relationship to complete bidirectional data communication.

2. The method for implementing a Modbus protocol and Broadband Industrial Bus AUTBUS-PA protocol conversion gateway as described in claim 1, characterized in that: The loading of the AUTBUS-PA device description XML file includes: After the gateway device starts up, it reads the locally stored AUTBUS-PA device description XML file, which is used to define the data model of the gateway as a slave device in the AUTBUS-PA network. Identify all U16 type real-time data fields from the AUTBUS-PA device description XML file. The U16 type real-time data field is a standard unsigned 16-bit integer data unit supported by the AUTBUS-PA protocol. Obtain the field identifier and semantic tag corresponding to each U16 type real-time data field. The field identifier is used to uniquely identify the real-time data field, and the semantic tag is used to characterize the physical meaning or functional purpose of the real-time data field.

3. The method for implementing a Modbus protocol and Broadband Industrial Bus AUTBUS-PA protocol conversion gateway as described in claim 2, characterized in that: The parsing of the AUTBUS-PA device description XML file includes: The XML parsing module is invoked to perform structured parsing on the AUTBUS-PA device description XML file, locating the node region containing the real-time data field definition; Traverse each real-time data field node in the node region and read the field identifier, semantic label, and data direction attribute declared in that node; The read field identifiers, semantic tags, and data direction attributes are stored in a real-time data field list in memory in the form of structured records.

4. The method for implementing a Modbus protocol and broadband industrial bus AUTBUS-PA protocol conversion gateway as described in claim 3, characterized in that: The generated point table mapping relationship includes: Based on the content of the semantic tag, a preset semantic-register type mapping table is queried to determine the data operation semantics corresponding to each real-time data field. The data operation semantics include "readable and writable" or "read-only". Based on the data operation semantics, each real-time data field is mapped to a Modbus register type, where "readable and writable" semantics are mapped to a holding register and "read-only" semantics are mapped to an input register; if the semantic label contains the keywords "status", "switch", or "enable", the Modbus register type is corrected to a coil. A unique hash value is generated based on the character sequence of the field identifier, and a Modbus register address is allocated in a preset address pool based on the unique hash value. The preset address pool is divided into a holding register area, an input register area, and a coil area according to the register type. The addresses in each area are continuous and do not overlap. The field identifier, Modbus register type, and Modbus register address of each real-time data field are combined into a structured mapping record. All mapping records are sorted by field identifier and stored to form a point-to-point mapping relationship.

5. The method for implementing a Modbus protocol and Broadband Industrial Bus AUTBUS-PA protocol conversion gateway as described in claim 4, characterized in that: The generation of the device description XML file for AUTBUS-PA network configuration includes: Based on the point table mapping relationship, extract the Modbus register address, register type and corresponding field identifier from each mapping record, and construct the access parameter table required for the Modbus master station to run. The access parameter table and Modbus communication parameters are encapsulated into structured data to generate a gateway configuration file. The Modbus communication parameters include slave ID, communication interface type, access period, and physical layer configuration information. Based on the field identifiers, semantic tags, and Modbus register types of each real-time data field in the point table mapping relationship, a device description XML file containing the definition of U16 type real-time data fields is generated according to the AUTBUS-PA row scale board format. The order of the real-time data fields in the device description XML file is consistent with the mapping relationship of the point table.

6. The method for implementing a Modbus protocol and broadband industrial bus AUTBUS-PA protocol conversion gateway as described in claim 5, characterized in that: The step of registering the device description XML file to the AUTBUS-PA-S protocol stack includes: During the gateway device initialization phase, the gateway configuration file is read, the Modbus communication parameters and access parameter table are parsed, and the parsing result is passed to the configuration interface of the Modbus master protocol stack. The Modbus master protocol stack initializes the physical layer and link layer based on the Modbus communication parameters, and constructs an internal register mapping cache based on the access parameter table. The device description XML file is loaded into the AUTBUS-PA-S protocol stack, and the AUTBUS-PA-S protocol stack parses the device description XML file to determine the device capability set and the definition of the U16 type real-time data field. Based on the parsing results, the AUTBUS-PA-S protocol stack declares itself to the AUTBUS-PA master station as an S device that conforms to the AUTBUS-PA industry rules, and is ready to receive downlink real-time data and upload uplink real-time data.

7. The method for implementing a Modbus protocol and Broadband Industrial Bus AUTBUS-PA protocol conversion gateway as described in claim 6, characterized in that: The bidirectional data communication is accomplished through the following means: The AUTBUS-PA-S protocol stack receives downlink real-time data frames sent by the AUTBUS-PA master station, parses out the values ​​of each U16 type real-time data field, and determines the Modbus register address and register type corresponding to each value according to the point table mapping relationship. The value of the downlink real-time data field is written to the corresponding address in the register mapping cache inside the Modbus master station protocol stack, and the Modbus master station protocol stack is triggered to perform a write operation, writing the cached data to the Modbus slave station register through the corresponding function code. The Modbus master station protocol stack reads data from the Modbus slave station registers sequentially according to a preset access cycle, and updates the corresponding address in the register mapping cache with the reading results. The AUTBUS-PA-S protocol stack extracts the values ​​corresponding to each U16 type real-time data field from the register mapping cache, encapsulates them into uplink real-time data frames, and uploads them to the AUTBUS-PA master station to complete bidirectional data communication.

8. A system for implementing a Modbus protocol and Broadband Industrial Bus (AUTBUS-PA) protocol conversion gateway, comprising the Modbus protocol and Broadband Industrial Bus (AUTBUS-PA) protocol conversion gateway implementation method as described in any one of claims 1 to 7, characterized in that, include: The loading module is used to load an AUTBUS-PA device description XML file into the gateway device. The AUTBUS-PA device description XML file contains a U16 type real-time data field, a field identifier for the real-time data field, and a semantic tag. The parsing module is used to parse the AUTBUS-PA device description XML file and extract the field identifiers, semantic tags and data direction attributes of each real-time data field; The mapping module is used to map the field identifiers and semantic tags to Modbus register addresses and register types respectively according to preset mapping rules, and generate a point table mapping relationship; The configuration module is used to construct a gateway configuration file based on the point table mapping relationship and generate a device description XML file for AUTBUS-PA network configuration; The registration module is used to load the gateway configuration file into the Modbus master protocol stack and register the device description XML file into the AUTBUS-PA-S protocol stack. The communication module is used to receive downlink real-time data sent by the AUTBUS-PA master station through the AUTBUS-PA-S protocol stack and write it into the Modbus slave station register according to the point table mapping relationship. At the same time, it periodically reads the Modbus slave station register data through the Modbus master station protocol stack and uploads it to the AUTBUS-PA master station according to the point table mapping relationship to complete bidirectional data communication.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the Modbus protocol and Broadband Industrial Bus AUTBUS-PA protocol conversion gateway implementation method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the Modbus protocol and Broadband Industrial Bus AUTBUS-PA protocol conversion gateway implementation method as described in any one of claims 1 to 7.

Images