A DP and PA bus protocol conversion method and related device

Abstract

This invention provides a DP to PA bus protocol conversion method and related apparatus, comprising the following steps: lexical parsing of the received raw message to obtain a token sequence; syntactic analysis of the token sequence to construct an abstract syntax tree; post-order traversal of the abstract syntax tree to extract protocol data units and obtain an intermediate representation; binding the DP bus data objects or function block parameters in the obtained intermediate representation with PA bus function block parameters or data based on dynamic mapping rules; and coordinating the data transmission rate between the DP bus and PA bus using timing compensation and flow control mechanisms to achieve protocol conversion between the DP bus and PA bus. This invention solves the technical problems of poor version compatibility, fixed mapping relationships, and difficulty in timing synchronization of existing protocol converters, achieving high-performance protocol conversion with a conversion delay of less than 1ms and a data transmission accuracy of 99.99%.

Description

Technical Field

[0001] This invention belongs to the field of industrial communication network technology, specifically relating to a DP and PA bus protocol conversion method and related apparatus. Background Technology

[0002] Industrial fieldbus technology, as the underlying communication infrastructure for factory automation and process automation, plays a crucial role in modern manufacturing. PROFIBUS, a key fieldbus protocol defined in the International Electrotechnical Commission (IEC) standard 61158, is mainly divided into two types based on its application: PROFIBUS-DP and PROFIBUS-PA. PROFIBUS-DP is primarily used in factory automation, employing the RS-485 physical layer and supporting communication rates up to 12 Mbps, suitable for high-speed data transmission and real-time control. PROFIBUS-PA, on the other hand, is mainly used in process automation, employing the IEC 61158-2 physical layer, with a communication rate of 31.25 kbps, intrinsically safe characteristics, and suitable for field instrument communication in hazardous environments such as petrochemical plants.

[0003] In practical industrial applications, to achieve seamless data transmission from field instruments to the control system, PROFIBUS-PA field devices typically need to be connected to the PROFIBUS-DP backbone network via couplers or connectors. However, existing DP / PA protocol conversion technologies have the following technical drawbacks: First, existing protocol converters typically use fixed hardware logic or hard-coded methods to implement protocol parsing, which can only support specific versions of DP or PA protocols and cannot be compatible with different protocol versions such as DP v1, DP v2, PA v1, and PA v2. This results in the need to replace hardware when upgrading the system or replacing the equipment, and the adaptability is poor. Second, the existing technology adopts a static and fixed data mapping method. The correspondence between the I / O data of the DP network and the functional block parameters of the PA device is fixed at the factory. Users cannot flexibly configure it according to the actual engineering needs, which leads to complex parameter adjustments when connecting PA devices from different manufacturers, and cannot achieve true "plug and play". Third, due to the huge difference in communication speed between PROFIBUS-DP and PROFIBUS-PA (up to 384 times the speed difference), the existing technology lacks an effective timing coordination mechanism, which causes data on the high-speed DP bus side to accumulate or be lost on the low-speed PA bus side, making it difficult to guarantee data consistency and potentially causing misjudgment by the control system in severe cases. Summary of the Invention

[0004] The purpose of this invention is to provide a method and related apparatus for converting DP and PA bus protocols, which solves the technical problems of poor version compatibility, fixed mapping relationship and difficulty in timing synchronization of existing protocol converters, and realizes efficient and compatible conversion and flexible configuration of multiple versions of DP / PA protocols.

[0005] To achieve the above objectives, the technical solution adopted by the present invention is as follows: In a first aspect, the present invention provides a DP to PA bus protocol conversion method, which performs lexical parsing on the received original message to obtain a token sequence; The token sequence is parsed to construct an abstract syntax tree; The abstract syntax tree is traversed in post-order traversal to extract protocol data units and obtain intermediate representations; Based on the dynamic mapping rules, the data objects or function block parameters of the DP bus in the obtained intermediate representation are bound to the function block parameters or data of the PA bus; A timing compensation method and a flow control mechanism are used to coordinate the data transmission rate between the DP bus and the PA bus, thereby achieving protocol conversion between the DP bus and the PA bus.

[0006] Preferably, the received original message is lexically parsed based on a finite state automaton to obtain a token sequence, wherein the token sequence includes a token type field, a token value field, a position offset field, and a verification status field.

[0007] Preferably, a recursive descent parser is used to perform syntactic analysis on the token sequence to construct an abstract syntax tree. Each node of the abstract syntax tree contains a protocol type identifier, a data length field, a data pointer, and an array of pointers pointing to lower-level child nodes.

[0008] Preferably, the intermediate representation includes a source address field, a destination address field, a service type field, a data length field, and a data payload field.

[0009] Preferably, the preset dynamic mapping rule table includes a device identifier segment, a data object segment, and a mapping relationship segment. The device identifier segment includes the DP slave identifier and the PA device identifier; the data object segment includes the DP input data length, the DP output data length, the PA function block input parameter list, and the PA function block output parameter list; the mapping relationship segment includes the correspondence between the DP input offset and the PA input parameter index, and the correspondence between the DP output offset and the PA output parameter index.

[0010] Preferably, based on dynamic mapping rules, the data objects or function block parameters of the DP bus in the obtained intermediate representation are bound to the function block parameters or data of the PA bus. Specifically, the method is as follows: The preset dynamic mapping rule table is parsed to generate a runtime hash table; Calculate the hash key value for each byte in the intermediate representation; The obtained hash key value is compared with the runtime hash table to obtain the corresponding DP mapping information or PA mapping information; Based on the obtained mapping information, obtain a 16-bit unsigned integer primitive value; Convert a 16-bit unsigned integer primitive value to a floating-point value; Convert floating-point values ​​to the IEEE 754 standard 32-bit floating-point format; Assemble 32-bit floating-point format into DP or PA message data units to complete the binding between DP bus data objects or function block parameters and PA bus function block parameters or data in the intermediate representation.

[0011] Preferably, the lock-free switching mechanism based on atomic flags dynamically configures the preset dynamic mapping rules.

[0012] Preferably, a timing compensation method and a flow control mechanism are used to coordinate the data transmission rate between the DP bus and the PA bus, thereby achieving protocol conversion between the DP bus and the PA bus. Specifically, the method is as follows: When a data frame sent by the master station is received on the DP bus side, a first timestamp is recorded; when a corresponding PA bus response frame is received, a second timestamp is recorded. The second timestamp is recorded by the PA-side coprocessor and written to the shared memory area when the transmission is completed. The difference between the first timestamp and the second timestamp is calculated to obtain the clock offset; Calculate the compensation value based on the obtained clock offset; Configure the write buffer and read buffer to store the data to be converted; By using a sliding window and adjusting the rate at which the data to be converted switches from the write buffer to the read buffer using a compensation value, protocol conversion between the DP bus and the PA bus can be achieved.

[0013] Secondly, the present invention provides a DP to PA bus protocol conversion system, comprising: The lexical analysis unit is used to perform lexical analysis on the received raw message to obtain a token sequence; The syntax parsing unit is used to perform syntax analysis on the token sequence and construct an abstract syntax tree; The intermediate representation is obtained by using a post-order traversal of the abstract syntax tree to extract protocol data units. The data binding unit is used to bind the data objects or function block parameters of the DP bus in the obtained intermediate representation to the function block parameters or data of the PA bus based on dynamic mapping rules. The protocol conversion unit is used to coordinate the data transmission rate between the DP bus and the PA bus using timing compensation and flow control mechanisms, and to realize protocol conversion between the DP bus and the PA bus.

[0014] Thirdly, the present invention provides an electronic device including a processor and a memory, wherein the memory stores computer instructions, and when the computer instructions are executed by the processor, the electronic device performs the method described thereon.

[0015] Compared with the prior art, the beneficial effects of the present invention are: This invention provides a DP to PA bus protocol conversion method that solves three core problems in existing technologies: poor protocol version compatibility, fixed mapping relationships, and difficulties in timing synchronization. Specifically, this method first utilizes lexical analysis and syntax analysis to construct an abstract syntax tree, achieving unified parsing of multiple versions of the DP v1 / v2 and PA v1 / v2 protocols. This breaks through the limitation of traditional solutions that can only handle a single protocol version, significantly improving device compatibility and adaptability. Second, by introducing dynamic mapping rules to replace static hard-coded binding, the correspondence between DP bus I / O data objects and PA bus function block parameters can be flexibly configured according to actual engineering needs, supporting plug-and-play functionality for devices from different manufacturers, greatly enhancing system deployment flexibility and engineering efficiency. Finally, by combining timing compensation and flow control mechanisms, it effectively coordinates the speed difference of up to 384 times between the high-speed DP bus and the low-speed PA bus, avoiding data accumulation or loss, and ensuring the real-time performance and consistency of data transmission between heterogeneous buses. Thus, this method achieves high performance indicators such as conversion latency of less than 1ms and data transmission accuracy of 99.99%, providing a highly compatible, flexible, and reliable protocol conversion solution for the industrial automation field.

[0016] Furthermore, by defining the specific structure of the dynamic mapping rule table, the device identifier segment, data object segment, and mapping relationship segment are organized in a standardized and configurable manner. This provides a clear and easily manageable rule carrier for data mapping between the DP and PA buses, enabling users to flexibly preset corresponding relationships for different slave devices, different data lengths, and different parameter indices. This achieves explicit definition and centralized management of mapping relationships, fundamentally breaking away from the limitations of traditional solutions where mapping relationships are fixed in code or hardware, and significantly improving the engineering adaptability and maintainability of the protocol converter.

[0017] Furthermore, based on dynamic mapping, the complete data binding process is further defined from rule table parsing to runtime hash table generation, hash key value calculation, and data type conversion (such as 16-bit integer to IEEE 754 floating-point format). The hash table enables fast matching of mapping information with O(1) time complexity. Combined with standardized numerical conversion and message assembly steps, it ensures high efficiency, high accuracy, and format consistency of data conversion between heterogeneous buses. This provides a specific and feasible technical path to meet the performance indicators of conversion latency of less than 1ms and data transmission accuracy of 99.99%.

[0018] Furthermore, by recording the first and second timestamps on the DP and PA sides respectively and calculating the clock offset, and dynamically adjusting the data transmission rate using a sliding window mechanism of the write buffer and read buffer, the timing mismatch and data accumulation problems caused by the huge difference in communication rates between the DP high-speed bus and the PA low-speed bus are precisely solved. This ensures the real-time performance and integrity of the data during the bidirectional conversion process, and provides key timing coordination guarantees for the stable and reliable operation of the entire protocol conversion method under complex industrial conditions. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of the overall architecture of the DP / PA bus protocol conversion method according to an embodiment of the present invention. The diagram shows a three-layer structure of protocol parsing layer, data mapping layer and timing control layer, as well as the positional relationship of DP physical layer interface, PA physical layer interface, configuration interface and diagnostic interface. Figure 2 This is a schematic diagram of the protocol parsing process based on an abstract syntax tree according to an embodiment of the present invention. The diagram shows in detail the complete process of the original message data stream being processed by lexical analysis to generate a token sequence, then by syntax analysis to construct an abstract syntax tree, and finally generating an intermediate representation, as well as the data structure diagram of each stage. Figure 3 This is a schematic diagram illustrating the working principle of the dynamic data mapping mechanism in an embodiment of the present invention. The diagram shows the structure of the mapping rule table, the generation process of the data mapping dictionary, and the dynamic binding relationship between DP network I / O data objects and PA network function block parameters. Figure 4 This is a timing diagram of the timing compensation and flow control mechanism in an embodiment of the present invention. The diagram shows the calculation process of the DP bus clock, PA bus clock, timestamp recording point, timing compensation value, and the adjustment curve of the sliding window size as the buffer occupancy rate changes. Figure 5This is a typical application topology diagram of the thermal automation system of a thermal power plant according to an embodiment of the present invention. The diagram shows the network topology structure in which the DCS control station is connected to the protocol converter of the present invention through the DP backbone network, and then connected to various field instruments (temperature transmitters, pressure transmitters, actuators, etc.) through the PA bus. Detailed Implementation

[0020] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0021] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0022] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0023] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0024] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0025] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0026] Example 1 This embodiment provides a method for converting DP and PA bus protocols, including the following steps: The received raw message is lexically parsed to obtain a token sequence; The token sequence is parsed to construct an abstract syntax tree; The abstract syntax tree is traversed in post-order traversal to extract protocol data units and obtain intermediate representations; Based on the dynamic mapping rules, the data objects or function block parameters of the DP bus in the obtained intermediate representation are bound to the function block parameters or data of the PA bus; A timing compensation method and a flow control mechanism are used to coordinate the data transmission rate between the DP bus and the PA bus, thereby achieving protocol conversion between the DP bus and the PA bus.

[0027] Example 2 This embodiment provides a DP to PA bus protocol conversion system. This method, through the coordinated operation of the protocol parsing layer, data mapping layer, and timing control layer, achieves efficient and reliable data exchange between the PROFIBUS-DP backbone network and PROFIBUS-PA field devices. Specifically: The protocol parsing layer is responsible for receiving raw messages from the DP bus or PA bus and converting different versions of protocol messages into intermediate representations that are independent of the protocol version through a parsing method based on abstract syntax trees. The data mapping layer is responsible for flexibly binding I / O data objects of the DP bus to function block parameters of the PA bus according to dynamically configured mapping rules. The timing control layer is responsible for monitoring the clock offset between the two buses and coordinating the data transmission rhythm between the high-speed DP bus and the low-speed PA bus through timing compensation and flow control mechanisms.

[0028] In this embodiment, the protocol parsing layer includes a message receiving module, a lexical analysis module, a syntax analysis module, and an intermediate representation generation module, wherein: The message receiving module is used to receive raw message data streams from the DP bus and PA bus through the DP physical layer interface and PA physical layer interface, respectively.

[0029] The lexical analysis module is used to scan the original message data stream using a finite state automaton. Based on the lexical rules of the DP v1, DP v2, PA v1 or PA v2 protocol, it decomposes the byte stream into a sequence of tokens with independent semantics. The tokens include start delimiter tokens, length tokens, function code tokens, data tokens and check tokens.

[0030] The syntax analysis module is used to analyze the token sequence using a recursive descent parser or an LR parser, and to construct an abstract syntax tree according to the syntax rules of each protocol version. The root node of the abstract syntax tree represents the complete message, and the lower-level nodes include a header node representing the message header, a data unit node representing the valid data, and a check node representing the frame check sequence. Each node contains a protocol type identifier, a data length, a data pointer, and an array of child node pointers.

[0031] The intermediate representation generation module is used to extract protocol data units by traversing the abstract syntax tree and convert them into a unified intermediate representation format that is independent of the protocol version. The intermediate representation includes a source address field, a destination address field, a service type field, a data length field, and a data payload field.

[0032] The data mapping layer includes a mapping rule management module, a mapping dictionary generation module, and a dynamic binding module, wherein: The mapping rule management module is responsible for reading and managing the mapping rule table. The mapping rule table is stored in XML or JSON format and includes a device identifier segment, a data object segment, and a mapping relationship segment. The device identifier segment stores the DP slave identifier and the PA device identifier. The data object segment defines the DP input data length, DP output data length, PA function block input parameter list, and PA function block output parameter list. The mapping relationship segment specifies the correspondence between the DP input offset and the PA input parameter index, as well as the correspondence between the DP output offset and the PA output parameter index.

[0033] The mapping dictionary generation module is used to parse the mapping rule table and generate a data mapping dictionary for runtime. The data mapping dictionary adopts a hash table structure, with key values ​​including DP slave address and DP input / output offset, and values ​​including corresponding PA device address, PA function block index and PA parameter index.

[0034] The dynamic binding module is used to dynamically bind I / O data objects from the DP bus to the corresponding PA bus function block parameters, or vice versa, according to the data mapping dictionary, to achieve bidirectional data conversion.

[0035] The mapping rule management module supports receiving dynamic reconfiguration instructions from the configuration interface during system operation, updating the data mapping dictionary according to the instructions, and applying the updated mapping relationship to the subsequent data conversion process without interrupting bus communication, thereby realizing flexible adjustment of the mapping relationship.

[0036] In the timing control layer, this invention employs timing compensation and flow control techniques. The timing control layer includes a clock monitoring module, a timing compensation module, and a flow control module, wherein: The clock monitoring module is used to monitor the offset between the DP bus clock and the PA bus clock by using a timestamp comparison method. Specifically, it records a first timestamp when a DP bus data frame is received, records a second timestamp when a corresponding PA bus response frame or data frame is received, and calculates the difference between the two to obtain the clock offset.

[0037] The timing compensation module calculates a timing compensation value based on the clock offset. The timing compensation value is used to adjust the residence time of data in the buffer to ensure the time consistency of data on both sides.

[0038] The flow control module controls the data flow between the DP bus and the PA bus based on a sliding window mechanism. The window size of the sliding window is initialized to the theoretical rate ratio of the DP bus to the PA bus (384:1) and dynamically adjusted according to the buffer occupancy rate: when the occupancy rate exceeds 70%, the window size is reduced, and when it is below 30%, the window size is increased. Specifically, the window size is set to the theoretical rate ratio of the DP bus to the PA bus during initialization. During operation, the buffer occupancy rate is monitored. When the buffer occupancy rate exceeds a preset high watermark threshold, the window size is reduced to decrease the data injection rate. When the buffer occupancy rate is below a preset low watermark threshold, the window size is increased to improve transmission efficiency.

[0039] Example 3 Building upon Example 2, this example provides a DP to PA bus protocol conversion system that also includes an error detection and recovery mechanism. During the construction of the abstract syntax tree, the syntactic validity of the token sequence is verified. When a syntax error is detected, an error handling process is triggered, including discarding the current message, recording an error log, and sending diagnostic information to the master station. During data mapping, data length consistency and address validity are verified. When the timing compensation value exceeds a preset threshold, a clock synchronization anomaly alarm is triggered, and a fault-tolerant transmission mode is activated to ensure reliable system operation.

[0040] In terms of hardware implementation, the method described in this invention can be executed in an embedded processor in a multi-task parallel manner, wherein the protocol parsing task runs at the highest priority, the data mapping task runs at the second highest priority, and the timing control task runs at a lower priority, ensuring the real-time performance of protocol parsing and the integrity of data processing.

[0041] Example 4 This embodiment details the complete engineering implementation of a DP to PA bus protocol conversion method in a thermal power plant's thermal automation system. Combining the three key technologies described—"protocol parsing method based on abstract syntax trees," "dynamic data mapping mechanism," and "timing compensation and flow control technology"—a comprehensive technical solution is constructed, encompassing hardware deployment, software implementation, and operation and maintenance.

[0042] In the thermal automation system of a 600MW supercritical coal-fired power plant, the distributed control system (DCS) uses the PROFIBUS-DP V1 protocol to build the backbone control network, with a communication rate configured at 1.5 Mbps and a cycle time set to 10ms. Field process layer devices include temperature transmitters, pressure transmitters, and pneumatic control valve positioners distributed in the boiler body, turbine building, and auxiliary workshops. These devices are connected via a PROFIBUS-PA bus with a communication rate of 31.25 kbps. Given the 48-fold rate difference between the DP backbone and PA field devices, as well as the diversity of protocol versions, this implementation deploys a protocol converter to achieve seamless data exchange.

[0043] The protocol converter's hardware architecture employs a dual-processor redundancy design. The main processor is an NXP i.MX RT1176 crossover microcontroller with a 1 GHz clock speed, equipped with 2 MB of on-chip SRAM and 32 MB of external SDRAM, running the FreeRTOS V10.4.6 real-time operating system. This processor connects to the PROFIBUS-DP bus via an isolated RS-485 transceiver, with a data transmission delay of less than 50 ns, meeting the aforementioned technical specification of "conversion delay less than 1 ms". The coprocessor is an STM32H743IIK6 with a 480 MHz clock speed, responsible for the PA bus Manchester encoding / decoding and physical layer signal processing, and connects to the PROFIBUS-PA bus via a dedicated PA interface chip. High-speed data exchange between the two processors is achieved through dual-port RAM, and a hardware semaphore mechanism ensures data consistency.

[0044] Based on this hardware platform, the protocol parsing layer implements the protocol parsing method based on the abstract syntax tree. When the DP bus receives the raw message data stream, the main processor's interrupt service routine first transfers the byte stream from the serial port data buffer to the protocol parsing buffer via the DMA controller. During this process, the DMA uses a circular buffer mode, with a buffer size of 2048 bytes, divided into two 1024-byte halves, to achieve parallel processing of data reception and parsing. The main processor then starts the lexical analysis module, which is implemented based on a finite state automaton (FSA). The FSA definition strictly follows the lexical rules of the DP V1, DP V2, PA V1, and PA V2 protocols.

[0045] The specific implementation of lexical analysis involves the following technical details: the finite state automaton contains eight core states: idle state (STATE_IDLE), start delimiter detection state (STATE_SD), length field parsing state (STATE_LEN), function code recognition state (STATE_FC), extended address parsing state (STATE_LE), data field receiving state (STATE_DATA), check field receiving state (STATE_FCS), and frame end state (STATE_END).

[0046] The state transition conditions are defined according to the protocol specification: when 0x68 (DP V1 long frame start delimiter) or 0x10 (DP V1 short frame start delimiter) is detected in the idle state, the finite state automaton transitions to the start delimiter detection state; if 0xDC (PA V3.x protocol start delimiter) is detected, the PA protocol parsing branch is activated. In the length field parsing state, the finite state automaton calculates the subsequent data reception length based on the DU (Data Unit) length field, expressed by the formula:

[0047]

[0048]

[0049] In the formula, The length of the data unit (in bytes) represents the payload size of the protocol data unit, taken from the definition of "protocol data unit". The length field byte value (unit: unsigned integer) represents the protocol message length indication; the transition condition of formula (1) is derived from the DP V1 / V2 protocol length encoding rules and the IEC 61158-6 standard specification on variable length encoding.

[0050] When the length field is detected to be 255 (0xFF), the finite state automaton automatically switches to the extended length parser substate and reads the next two bytes to form the length value.

[0051] In the PA protocol parsing branch, given that the PA bus uses Manchester encoding and a transmission rate of 31.25 kbps, the lexical analysis module is configured with an independent decoding finite state automaton. This finite state automaton monitors the preamble pattern 0x00...0x00 (at least 8 0x00 bytes), and then identifies the start delimiter 0xB4 (SD1) or 0xDC (SD4). According to PAV1 / V2 protocol compatibility requirements, the finite state automaton supports dynamic identification of V1 version fixed-length frames (8 bytes) and V2 version variable-length frames. The identification is based on the range of the function code field in the 4th byte: if the function code is in the range of 0x00-0x0F, it is determined to be a V1 version diagnostic frame; if it is in the range of 0x48-0x4F, it is determined to be a V2 version cyclic data frame.

[0052] The lexical analysis module outputs a structured sequence of tokens. Each token element is encapsulated in a 16-byte data structure, containing: a token type field, a token value field, a position offset field, and a verification status field. This data structure design ensures that the semantic information of the protocol elements can be quickly accessed in the subsequent syntax analysis stage.

[0053] In this embodiment, a state machine with a specific set of states and transition conditions is designed for the specific technical scenario of DP / PA multi-version protocol conversion. Specifically, conventional FSAs are usually designed for a single fixed protocol, while this application, to be compatible with four protocol versions simultaneously (DP V1 / V2 and PA V1 / V2), defines a specific set of states including eight core states such as idle state, start delimiter detection state, and length field parsing state. Protocol version identification logic is embedded in the state transition conditions (e.g., automatically branching to different parsing branches based on different start delimiters such as 0x68, 0x10, and 0xDC, and an extended length parsing sub-state for a length field of 255). In particular, this application integrates the DU length calculation formula during the state transition process. The dynamic calculation logic, which defines specific states and combines transition conditions for multiple versions of industrial fieldbus protocols, is not a simple application of conventional FSA in general text parsing, but rather solves the specific technical problem of poor version compatibility in DP / PA protocol conversion.

[0054] Building upon this foundation, the syntax analysis module employs a Recursive Descent Parser (RDP) to construct an Abstract Syntax Tree (AST). Based on the DP / PA protocol syntax rules, the parser defines a series of non-terminal symbol functions: parse_frame(), parse_header(), parse_data_unit(), and parse_trailer(). The parse_frame() function serves as the entry point, sequentially calling parse_header() to parse the message header (containing the destination address DA, source address SA, and function code FC), calling parse_data_unit() to parse the data unit (for DP V1 Variable bytes or PA function block parameters), and finally calling parse_trailer() to parse the Frame Check Sequence (FCS).

[0055] Each non-terminal symbol function returns a pointer to an AST node, and the node is defined using a 32-byte uniform structure: typedef struct AST_Node { uint16_t node_type; / / Node type: 0x01=Header, 0x02=Data, 0x03=FCS, etc. uint16_t protocol_ver; / / Protocol version: 0x10=DP V1, 0x20=DP V2, 0x30=PA V1, 0x40=PA V2 uint32_t data_len; / / Data length (bytes) uint8_t*data_ptr; / / Pointer to the original data or intermediate representation uint16_t child_count; / / Number of child nodes struct AST_Node **children; / / Array of child node pointers uint32_t checksum; / / Node data checksum } AST_Node; The AST construction process strictly follows the protocol hierarchy. Taking DP V1 long frames as an example, the root node type is AST_ROOT, which contains three child nodes: HEADER node (containing DA, SA, and FC child nodes), DATA_UNIT node (containing multiple DATA_SEGMENT child nodes, each corresponding to an IO data block), and TRAILER node (containing FCS child nodes).

[0056] For PA V3.x protocol frames, the AST structure adds an FB_ENTRY node to represent the function block entry. This node contains BLOCK_TYPE (function block type identifier, such as AI, AO, DI, DO), BLOCK_INDEX (function block index number, 0-15), and PARAM_LIST (parameter list node).

[0057] After the AST is constructed, the intermediate representation generation module performs tree traversal operations, adopting a post-order traversal strategy, first processing the leaf node data, and then aggregating upwards to generate the intermediate representation (IR). The IR (Intent Recognition) uses a flat structure, IR_Packet, which includes the following fields: protocol_family (protocol family identifier, enumeration type: PROTO_DP or PROTO_PA), protocol_version (protocol version number, BCD code representation, e.g., 0x10 represents V1.0), source_addr (source address, 16-bit unsigned integer, DP range 0-126, PA range 0-63), dest_addr (destination address, 16-bit unsigned integer), service_type (service type, enumeration values: SRV_READ, SRV_WRITE, SRV_ALARM, etc.), priority (priority, 3-bit unsigned integer, levels 0-7), data_length (data length, 16-bit unsigned integer, maximum 244 bytes), timestamp (timestamp, 64-bit unsigned integer, microsecond resolution, taken from the processor's high-precision timer), and payload (data payload, pointer to a byte array). This IR format is independent of protocol version, providing a unified data view for subsequent dynamic data mapping.

[0058] In this embodiment, a specific set of non-terminal symbol functions (parse_frame, parse_header, parse_data_unit, parse_trailer) and an AST node structure are defined to meet the specific requirements of DP / PA protocol conversion. This is not a simple application of conventional RDP. Specifically, the AST node structure (AST_Node) designed in this application includes a protocol_ver field to identify the protocol version (DP V1 / V2, PA V1 / V2), and defines specific node types that support multi-version protocol hierarchies (such as the FB_ENTRY node added for PA V3.x). This specific AST structure designed for the unified representation requirements of multi-version industrial protocols, and the method of generating intermediate representations (IR) independent of protocol versions using a post-order traversal strategy, solves the problem of strong coupling between protocol parsing and version in the prior art.

[0059] Given this protocol parsing architecture, compared to existing technologies (which use fixed logic in FPGAs for protocol parsing), this implementation achieves dynamic adaptation to protocol versions through software-defined AST parsing. Existing technologies use hard-coded finite state automata embedded in FPGA logic units, supporting only specific protocol versions. When the protocol version is upgraded, the hardware logic needs to be resynthesized. This implementation, however, by configuring the `protocol_ver` field in the AST node structure, can support mixed parsing of DP V1 / V2 and PA V1 / V2 on the same hardware platform, exhibiting good forward and backward compatibility. Design mitigation recommendations include: maintaining fixed field offsets in the AST node structure (the first 4 bytes are always `node_type`, and subsequent fields are aligned to 4 bytes), ensuring that future protocol version expansions do not require modification of the memory layout, only the addition of new `node_type` enumeration values.

[0060] In the data mapping layer, this implementation employs a dynamic data mapping mechanism. The core of this mechanism lies in the definition and runtime parsing of the Mapping Rule Table (MRT). The MRT is defined using the XML Schema 1.0 specification, and the file is stored on an industrial-grade SD card connected to the main processor, at the path / mapping / dp_pa_config.xml. The MRT's XML Schema definition is as follows: The mapping rule table is defined in a format conforming to the XML Schema 1.0 specification. The root element is the mapping configuration, which contains several device configuration sections. Each device configuration section contains the following attributes: dp_slave_addr (DP slave address, value range 0-126), dp_protocol_ver (DP protocol version identifier), pa_device_addr (PA device address, value range 0-63), and pa_protocol_ver (PA protocol version identifier). Each device configuration section also contains input mapping and output mapping elements, used to define specific data mapping relationships. Input mapping and output mapping elements include: dp_offset (DP data buffer byte offset), pa_block_type (PA function block type), pa_block_index (function block index number, 0-15), pa_param_index (parameter index, 0-255), data_type (data type), and an optional conversion_factor (conversion coefficient, used for linear range conversion).

[0061] The design of this XML Schema strictly follows the structural requirements of the "mapping rule table", in which the Device Profile element corresponds to the "device identifier segment", and the Input Mapping and Output Mapping elements correspond to the "data object segment" and "mapping relationship segment". The `dp_slave_addr` attribute has a value range of 0-126, corresponding to the DP slave address; the `pa_device_addr` attribute has a value range of 0-63, corresponding to the PA device address; the `dp_offset` attribute represents the byte offset (0-243) in the DP input / output data buffer; the `pa_block_type` attribute enumerates values ​​including "AI" (analog input), "AO" (analog output), "DI" (discrete input), "DO" (discrete output), "PID" (PID control block), etc., corresponding to the PA function block type; the `pa_block_index` attribute has a value range of 0-15, corresponding to the index number of the function block in the device; the `pa_param_index` attribute has a value range of 0-255, corresponding to the relative index of the parameter within the function block; the `data_type` attribute defines the data type conversion rules, including "UINT8", "INT16", "FLOAT32", "BIT", etc.; the `conversion_factor` attribute is used for linear transformation, such as converting the 4-20 mA signal of the PA device to engineering units.

[0062] When the system starts, the main processor runs the mapping dictionary generation module, parses the MRT XML file, and generates a runtime hash table (RHT). The RHT uses open addressing to handle collisions, and the hash function is designed as follows:

[0063] In the formula, The hash bucket index (unit: unsigned integer, range 0-1023) represents the storage location in the data mapping dictionary; k is the composite key value (unit: 32-bit unsigned integer), calculated as... ,in, This is the DP slave address (value range 0-126, taken from "DP slave address"). Here, is the data offset (range 0-243, taken from "DP input / output offset"), direction is the direction indicator (0=input, 1=output); A is the golden ratio constant 2654435769 (approximately). ), dimensionless.

[0064] Hash table entries use a 16-byte structure, containing: valid_flag (validity flag, 1 byte, 0xAA indicates valid, other values ​​indicate free or deleted), dp_addr (DP slave address, 1 byte), dp_offset (DP offset, 1 byte), direction (direction, 1 byte), pa_addr (PA device address, 1 byte), pa_block_idx (PA function block index, 1 byte), pa_param_idx (PA parameter index, 1 byte), data_type (data type encoding, 1 byte), conversion_factor (conversion factor, 4-byte floating-point), and next_idx (index of the next item in the collision chain, 2 bytes, used in open addressing).

[0065] Using this hash table, the dynamic binding module can complete the mapping query from DP data objects to PA function block parameters in O(1) time complexity.

[0066] The data conversion process of the dynamic binding module is as follows: When receiving input data from the DP bus (master to slave direction), the module traverses the DP input data buffer, calculates the hash key value k for each byte or word, and queries the RHT to obtain the corresponding PA mapping information. If the data type is FLOAT32 (corresponding to the analog input of the PA device), the module performs the following conversion operation: reads a 16-bit unsigned integer raw value from the DP buffer. Convert to floating-point value according to the conversion factor (conversion_factor). Then The data is converted to the IEEE 754 standard 32-bit floating-point format, and finally assembled into PA message data units according to the PA function block parameter structure (SP byte + data byte + status byte). During this process, the status byte sets the Quality bit (Bits 7-6) to 0b11 (indicating Good) according to the "data consistency" requirement, the Limit bit (Bits 5-4) is set according to the range check, and the Substatus bit (Bits 3-0) is set to 0x0 (normal operation).

[0067] To address the "dynamic reconfiguration" capability, this implementation implements an online reconfiguration (OR) mechanism. The OR mechanism allows the reception of new mapping rule tables or incremental update instructions during system operation via an Ethernet interface (10 / 100 Mbps, RJ45 connector, supporting Modbus TCP / IP or dedicated configuration protocols). Upon receiving a reconfiguration request, the main processor first verifies the legitimacy of the request source. Then, it allocates a new RHT structure (called the Shadow RHT) in the memory heap, parses the new XML configuration, and populates the Shadow RHT. After successful verification, the main processor performs an atomic pointer switch operation: switching the global RHT pointer from the old table to the Shadow RHT. This operation ensures atomicity by disabling interrupts. After the switch is complete, the old RHT is marked as pending release, and a low-priority garbage collection task reclaims the memory during the next system idle cycle. The latency of the entire switching process is controlled within 500 microseconds, meeting the constraint of a conversion latency of less than 1ms, and does not affect ongoing bus communication cycles.

[0068] At the timing control layer, this implementation employs timing compensation and flow control techniques to address the rate and cycle differences between the DP bus (1.5 Mbps, cycle time 10 ms) and the PA bus (31.25 kbps, typical response time 50-200 ms). The core of timing control lies in clock synchronization and compensation algorithms. Both the main processor and the coprocessor are equipped with independent hardware timers (based on the ARM Cortex-M7 SysTick timer, with the clock source being a 1 GHz processor frequency divided by 1 MHz, i.e., 1 microsecond resolution). The two processors exchange timestamp information through a specific address segment (0xFF00-0xFF0F, a total of 16 bytes) of the dual-port RAM.

[0069] The specific implementation of clock skew monitoring is as follows: when the DP bus side receives a cyclic data frame sent by the master station, the master processor records the received timestamp. (64-bit microsecond counter value). After protocol parsing and dynamic mapping, the data frame is transmitted to the coprocessor via dual-port RAM. The coprocessor converts it into a PA protocol frame and sends it to the PA bus. When the PA device returns a response frame (usually an acknowledgment frame or process data), the coprocessor records a timestamp indicating that transmission is complete. The value is then written to the shared area of ​​the dual-port RAM. The main processor reads this value at the start of the next DP cycle. Calculate clock offset :

[0070] In the formula, Clock offset (unit: microseconds) represents the clock deviation between the DP bus and the PA bus; The PA side sends a completion timestamp (in microseconds), taken from the coprocessor's timer register; The DP side receives the timestamp (in microseconds), which is retrieved from the timer register of the autonomous processor; The fixed overhead for protocol processing (unit: microseconds) is measured to be 80-120 microseconds on this hardware platform. The specific value depends on the data length and mapping complexity. This value is based on the measured statistics of protocol conversion processing latency. The PA bus physical layer transmission delay (in microseconds) is calculated as follows: ,in The length of the PA frame. This refers to the PA bus transmission rate.

[0071] Based on this offset, the timing compensation module calculates the compensation value. This value is used to adjust the residence time of data in the output buffer to ensure timing consistency between the DP and PA sides. The compensation formula is:

[0072] In the formula, The timing compensation value (unit: microseconds) represents the data processing time that needs to be delayed or advanced. The clock offset weighting coefficient (dimensionless) is 0.85. It is derived from the requirements of timing compensation for clock synchronization accuracy and the proportional coefficient selection principle of PID controller in control theory (to ensure system stability and rapid response). This is the measured clock offset (unit: microseconds). The data transmission weighting coefficient (dimensionless) has a value of 0.6 and is a statistical average based on the half-duplex characteristics of the PA bus and the response delay of typical devices (50-200 ms). The length of the data to be transmitted is taken from the currently processed data frame; This refers to the PA bus communication rate. This is the buffer occupancy compensation coefficient (dimensionless), with a value of 0.4, used to alleviate buffer overflow. This represents the number of bytes currently occupied by the buffer. This refers to the DP bus communication rate.

[0073] The flow control module uses a sliding window mechanism to control data flow from DP to PA. Given this flow control mechanism, if the PA-side device responds slowly, leading to high buffer occupancy... When the buffer occupancy rate exceeds 70% (high water level threshold), the window size W automatically decreases, reducing the rate at which data is injected from the DP side to the PA side. When the buffer occupancy rate is below 30% (low water level threshold), the window size W increases, improving throughput. This mechanism ensures that even if the PA bus experiences a brief communication interruption due to interference in the complex electromagnetic environment of a thermal power plant, the data on the DP side will not overflow due to continuous injection, thus meeting the reliability requirement of a data transmission accuracy of up to 99.99%.

[0074] In terms of error detection and recovery, this implementation constructs a multi-layered fault-tolerant system. At the protocol parsing layer, the lexical analysis module performs CRC8 checksum (for DP short frames) or CRC16 checksum (for DP long frames and PA frames) on each token, with the following checksum polynomials: If the verification fails, the syntax analysis module immediately stops building the AST for the current frame, discards the received data, and sends a diagnostic message to the master station. The diagnostic message contains the error code 0x0A and the error position counter value.

[0075] In the data mapping layer, the dynamic binding module performs address validity checks (verifying DP addresses 0-126 and PA addresses 0-63), data length consistency checks (verifying that the DP data length matches the PA function block parameter length), and range overflow checks (verifying that the converted values ​​are within the valid engineering range). Any failure in these checks triggers the mapping error handling process: an error log is recorded to the SD card (path / logs / mapping_errors.log, containing timestamps, DP address, PA address, and error type), diagnostic information is sent to the DCS master station (function code FC=0x13, diagnostic data includes error details), and valid data from the previous cycle is maintained to ensure the continuity of the control system.

[0076] In the timing control layer, when the clock offset If the preset threshold (500 microseconds, or half a DP bit time) is exceeded, the system triggers a clock synchronization failure alarm and initiates fault-tolerant transmission mode. In this mode, the protocol converter suspends new data mapping operations, enters a data hold state, continuously sends data from the previous valid cycle to the DP side, and simultaneously attempts to resynchronize the PA bus clock. If synchronization is not restored within 3 DP cycles (30 ms), the system triggers a watchdog reset and reinitializes the protocol stack.

[0077] This implementation provides specific engineering deployment specifications for thermal power plant automation systems. The protocol converter is installed inside the DCS control cabinet, with an IP54 protection rating and a grounding resistance of less than 4 ohms. The DP bus cable uses shielded twisted-pair cable (model: Siemens 6XV1830-0EH10, characteristic impedance 150 Ω, capacitance less than 60 pF / m), and is laid with a minimum distance of 300 mm from power cables to avoid electromagnetic interference. The PA bus cable uses Type A cable (IEC 61158-2 standard, cross-sectional area 1.5 mm², DC resistance 44 Ω / km, maximum transmission distance 1900 m), connected to the intrinsically safe area via a PA coupler (Siemens 6ES7157-0AC82-0XA0). The coupler's isolation voltage is 2500 V, and the short-circuit current is limited to within 31mA, meeting the safety requirements of the explosion-proof areas (Zone 1 or Zone 2) in thermal power plants.

[0078] The specific implementation in the boiler drum water level control system of a thermal power plant is as follows: the drum water level transmitter (differential pressure type, PROFIBUS-PA interface, address set to 5, function block index 0 is AI analog input block) is connected to the protocol converter via the PA bus; the DCS control system (Honeywell Experion PKS, PROFIBUS-DP interface, master station address 1) is connected to the protocol converter via the DP bus. The mapping rule table is configured as follows: DP slave address 10 corresponds to PA device address 5; DP input offset bytes 0-3 (FLOAT32 type) are mapped to PA function block index 0 and parameter index 2 (process value PV); DP output offset bytes 0-3 are mapped to PA function block index 1 (AO analog output block, used for setpoint SP); the conversion coefficient is set to 4-20 mA for a range of 0-600 mmH2O, i.e. , offset =0. When the DCS sends control commands at a 10 ms cycle, the protocol converter converts the DP data into PA frames and sends them to the level transmitter through the above-mentioned AST parsing, dynamic mapping and timing compensation mechanism. At the same time, it converts the transmitter's process value PV and uploads it to the DCS. The actual measured conversion delay is 680 microseconds, and the data transmission accuracy is 99.992% after 30 days of continuous operation.

[0079] Another implementation in the turbine speed control system is as follows: the speed control valve actuator (PROFIBUS-PA, double-acting cylinder, with valve positioner, address 12, containing AO function block index 0 and AI function block index 0 for valve position feedback) is connected to the DCS via a protocol converter. Given the extremely high real-time requirements of the speed control system (control cycle 50 ms), the protocol converter is configured in priority mode: the PA device is configured as a synchronous slave of DP V2, and the DP cycle is synchronized with the turbine speed signal (via an external synchronization pulse input). At this time, in formula (4)... The coefficient is adjusted to 1.0. The value was adjusted to 0.3 to meet stricter timing requirements. Actual testing showed that under this operating condition, the protocol converter achieved a conversion delay of less than 1 ms, and there was no data loss or timing errors during switching between different load conditions (50% to 100% of rated load).

[0080] Based on the mechanical structure and circuit logic, the above implementation achieves multi-version protocol compatibility through protocol parsing based on abstract syntax trees, flexible configuration management through dynamic data mapping mechanism, and reliable data exchange between heterogeneous buses through timing compensation and flow control technology. Thus, the technical solution described above is fully implemented and has industrial-grade implementability and reproducibility.

[0081] Example 5 This embodiment also provides a computing device. The computing device includes a bus, a processor, a memory, and a communication interface. The processor, memory, and communication interface communicate with each other via the bus. The computing device can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memory in the computing device.

[0082] A bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, a bus can include a path for transmitting information between various components of a computing device (e.g., memory, processor, communication interfaces).

[0083] The processor may include any one or more of the following: central processing unit (CPU), graphics processing unit (GPU), tensor processing unit (TPU), application specific integrated circuit (ASIC), field-programmable gate array (FPGA), microprocessor (MP), or digital signal processor (DSP).

[0084] Memory can include volatile memory, such as random access memory (RAM). Processors can also include non-volatile memory. volatile memory, such as read-only memory (ROM). ROM (memory only), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0085] The memory stores executable program code, which the processor executes to implement the functions of the aforementioned units, thereby achieving, for example, the method described in Embodiment 1. That is, the memory may store instructions for the methods and functions relating to the computing device in any of the above embodiments.

[0086] The communication interface uses transceiver modules such as, but not limited to, network interface cards and transceivers to enable communication between computing devices and other devices or communication networks.

[0087] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for converting DP and PA bus protocols, characterized in that, Includes the following steps: The received raw message is lexically parsed to obtain a token sequence; The token sequence is parsed to construct an abstract syntax tree; The abstract syntax tree is traversed in post-order traversal to extract protocol data units and obtain intermediate representations; Based on the dynamic mapping rules, the data objects or function block parameters of the DP bus in the obtained intermediate representation are bound to the function block parameters or data of the PA bus; A timing compensation method and a flow control mechanism are used to coordinate the data transmission rate between the DP bus and the PA bus, thereby achieving protocol conversion between the DP bus and the PA bus.

2. The DP to PA bus protocol conversion method according to claim 1, characterized in that, The received original message is lexically parsed using a finite state automaton to obtain a token sequence, which includes a token type field, a token value field, a position offset field, and a verification status field.

3. The DP to PA bus protocol conversion method according to claim 1, characterized in that, A recursive descent parser is used to perform syntactic analysis on the token sequence to construct an abstract syntax tree. Each node of the abstract syntax tree contains a protocol type identifier, a data length field, a data pointer, and an array of pointers pointing to the lower-level child nodes.

4. The DP to PA bus protocol conversion method according to claim 3, characterized in that, The intermediate representation includes a source address field, a destination address field, a service type field, a data length field, and a data payload field.

5. The DP to PA bus protocol conversion method according to claim 1, characterized in that, The preset dynamic mapping rule table includes a device identifier segment, a data object segment, and a mapping relationship segment. The device identifier segment includes the DP slave identifier and the PA device identifier. The data object segment includes the DP input data length, the DP output data length, the PA function block input parameter list, and the PA function block output parameter list. The mapping relationship segment includes the correspondence between the DP input offset and the PA input parameter index, as well as the correspondence between the DP output offset and the PA output parameter index.

6. The DP to PA bus protocol conversion method according to claim 1, characterized in that, Based on dynamic mapping rules, the data objects or function block parameters of the DP bus in the obtained intermediate representation are bound to the function block parameters or data of the PA bus. The specific method is as follows: The preset dynamic mapping rule table is parsed to generate a runtime hash table; Calculate the hash key value for each byte in the intermediate representation; The obtained hash key value is compared with the runtime hash table to obtain the corresponding DP mapping information or PA mapping information; Based on the obtained mapping information, obtain the original 16-bit unsigned integer value; Convert a 16-bit unsigned integer primitive value to a floating-point value; Convert floating-point values ​​to the IEEE 754 standard 32-bit floating-point format; Assemble 32-bit floating-point format into DP or PA message data units to complete the binding between DP bus data objects or function block parameters and PA bus function block parameters or data in the intermediate representation.

7. A DP to PA bus protocol conversion method according to claim 1 or 6, characterized in that, The lock-free switching mechanism based on atomic flags dynamically configures the preset dynamic mapping rules.

8. The DP to PA bus protocol conversion method according to claim 1, characterized in that, The timing compensation method and flow control mechanism are used to coordinate the data transmission rate between the DP bus and the PA bus, and to realize the protocol conversion between the DP bus and the PA bus. The specific method is as follows: When a data frame sent by the master station is received on the DP bus side, a first timestamp is recorded; when a corresponding PA bus response frame is received, a second timestamp is recorded. The second timestamp is recorded by the PA-side coprocessor and written to the shared memory area when the transmission is completed. The difference between the first timestamp and the second timestamp is calculated to obtain the clock offset; Calculate the compensation value based on the obtained clock offset; Configure the write buffer and read buffer to store the data to be converted; By using a sliding window and adjusting the rate at which the data to be converted switches from the write buffer to the read buffer using a compensation value, protocol conversion between the DP bus and the PA bus can be achieved.

9. A DP to PA bus protocol conversion system, characterized in that, include: The lexical analysis unit is used to perform lexical analysis on the received raw message to obtain a token sequence; The syntax parsing unit is used to perform syntax analysis on the token sequence and construct an abstract syntax tree; The intermediate representation is obtained by using a post-order traversal of the abstract syntax tree to extract protocol data units. The data binding unit is used to bind the data objects or function block parameters of the DP bus in the obtained intermediate representation to the function block parameters or data of the PA bus based on dynamic mapping rules. The protocol conversion unit is used to coordinate the data transmission rate between the DP bus and the PA bus using timing compensation and flow control mechanisms, and to realize protocol conversion between the DP bus and the PA bus.

10. An electronic device, characterized in that, It includes a processor and a memory, the memory storing computer instructions that, when executed by the processor, cause the electronic device to perform the method of any one of claims 1 to 8.

Images