Sriov multicast data transmission system based on multicast table pre-configuration

Abstract

This invention relates to the field of SRIO multicast data transmission technology, specifically an SRIO multicast data transmission system based on pre-configured multicast tables. The system includes: during the power-on initialization phase of the SRIO switching chip, a configuration parsing module parses a pre-set metallurgical process flow configuration file to obtain process segment definitions and corresponding actuator lists divided by process steps; a multicast binding module retrieves the physical port numbers of the actuators, generates multicast group identifiers, and establishes binding relationships; and a routing table configuration module writes these relationships into a pre-configured multicast routing table. When metallurgical production enters a specific process segment, the SRIO switching chip, based on the pre-configured routing table, performs hardware-level copying and parallel forwarding of data frames carrying the corresponding multicast group identifiers, ensuring that process data synchronously reaches all actuators in the corresponding process segment. This system improves the real-time performance and synchronization of data transmission, reduces transmission latency, ensures coordinated operation of all actuators, and accurately adapts to metallurgical production needs.

Description

Technical Field

[0001] This invention relates to the field of SRIO multicast data transmission technology, and in particular to an SRIO multicast data transmission system based on multicast table pre-configuration. Background Technology

[0002] In metallurgical production, an SRIO multicast data transmission system is needed to synchronize process data between the process control server and the actuators in each process segment, ensuring coordinated operation of all actuators. In existing technologies, the multicast configuration of SRIO switching chips often uses generic settings. During initialization, only basic hardware self-tests and general parameter configurations are completed, without specific adaptation for metallurgical processes. The establishment of multicast groups and port binding must be manually performed during production based on real-time requirements or dynamically configured using a generic protocol.

[0003] In existing technical solutions, multicast routing tables are mostly dynamically generated, lacking pre-configuration designs for process segments divided according to metallurgical operations. Data forwarding largely relies on software-level processing, requiring multiple layers of protocol parsing and forwarding judgment. Under this approach, when switching process segments in metallurgical production, multicast group binding relationships need to be re-established and routing tables updated, leading to data transmission delays. This prevents the synchronous distribution of process data to all actuators within the same process segment, and the software-level forwarding efficiency is low, making it difficult to meet the real-time and synchronous requirements of process data transmission in metallurgical production.

[0004] The actuators in each process segment of metallurgical production need to receive process data synchronously. The list of actuators for different process segments is different. Conventional SRIO multicast configuration cannot be adapted to this process characteristic in advance, resulting in poor data distribution targeting and problems such as asynchronous actuator actions and process deviations. It is necessary to solve the problems of insufficient adaptability of SRIO multicast configuration to metallurgical process flow and low data synchronization and forwarding efficiency. Summary of the Invention

[0005] The purpose of this invention is to overcome the shortcomings of the existing technology and propose an SRIO multicast data transmission system based on multicast table pre-configuration.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: an SRIO multicast data transmission system based on multicast table pre-configuration, comprising: The configuration parsing module parses the pre-set metallurgical process flow configuration file during the power-on initialization phase of the SRIO switching chip to obtain the process segment definition divided by process and the list of actuators that need to receive process data synchronously within each process segment. The multicast binding module retrieves the physical port number corresponding to each actuator from the address mapping table of the SRIO switching chip according to the actuator list, generates a multicast group identifier based on the physical port number, and establishes a binding relationship between the multicast group identifier and the physical port number of the actuator. The routing table configuration module writes the established binding relationship into the pre-configured multicast routing table of the SRIO switching chip. The pre-configured multicast routing table is used to define multicast forwarding rules from a specific source port to multiple destination ports. When the metallurgical production process enters a specific process segment, the data distribution module sends a data frame carrying the multicast group identifier to the SRIO switching chip via the process control server. The data frame contains process data that needs to be synchronously distributed. The SRIO switching chip performs hardware-level copying of the received data frame according to the multicast forwarding rules in the pre-configured multicast routing table, and forwards the multiple copies of the data frame in parallel through the physical ports of each bound actuator, so that the process data reaches all actuators in the process segment simultaneously.

[0007] As a further aspect of the present invention, the parsing of the preset metallurgical process flow configuration file includes: Read the header of the metallurgical process flow configuration file to obtain the version number and total number of process segments of the metallurgical process flow configuration file; Traverse the main content of the metallurgical process flow configuration file and extract the process segment number, process segment name and process data message format corresponding to each process segment; For each process segment, its associated list of actuators is further analyzed. The list of actuators includes the device ID, device type, and logical address of the actuator in the SRIO network. The parsed process segment number, process data message format, and actuator list are associated and stored to form a process segment-data-equipment mapping table for subsequent multicast group configuration.

[0008] As a further aspect of the present invention, based on the list of actuators, the physical port number corresponding to each actuator is retrieved from the address mapping table of the SRIO switching chip, including: Send a read request to the SRIO switching chip to obtain the address mapping table maintained internally by the SRIO switching chip. The address mapping table records the mapping relationship between logical addresses and physical port numbers. Iterate through each actuator in the list of actuators, convert its device ID into the corresponding logical address, and look up the physical port number corresponding to the logical address in the address mapping table; For the physical port number that is found, check whether its status bit is available. If it is not available, mark the actuator as pending and skip the subsequent binding operation. The list of valid ports is composed of the available actuators and their corresponding physical port numbers. This list is used for the subsequent generation of multicast group identifiers.

[0009] As a further aspect of the present invention, generating a multicast group identifier based on the physical port number and establishing a binding relationship between the multicast group identifier and the physical port number of the execution mechanism includes: Each process segment is assigned a unique process segment index number, which is selected sequentially from a predefined range of values. The process segment index number is combined with a preset multicast identifier prefix to generate the multicast group identifier corresponding to the process segment. The multicast group identifier is globally unique in the SRIO network. Traverse the list of valid ports and associate the generated multicast group identifier with the physical port number of all actuators in the list of valid ports to form a many-to-many binding relationship table; Conflict detection is performed on the binding relationship table. If there are duplicate multicast group identifiers, the corresponding process segment index number is incremented to correct them until all multicast group identifiers remain unique in the system.

[0010] As a further aspect of the present invention, the step of writing the established binding relationship into the pre-configured multicast routing table of the SRIO switching chip includes: Construct a multicast routing table entry that conforms to the SRIO protocol specification. The multicast routing table entry includes a multicast group identifier field, an ingress port number field, and an egress port bitmap field. Fill the multicast group identifier in each of the binding relationships into the multicast group identifier field, and fill the connection port number of the process control server into the ingress port number field; Based on the physical port number of each actuator in the binding relationship, set the corresponding bit in the output port bitmap field to the valid state, and keep the bit corresponding to the unbound physical port number in the invalid state; By initiating a write operation to the register space of the SRIO switching chip through the SRIO configuration transaction, the constructed multicast routing table entries are sequentially written to the specified register addresses, thus completing the solidification of the pre-configured multicast routing table.

[0011] As a further aspect of the present invention, the step of sending a data frame carrying the multicast group identifier from the process control server to the SRIO switching chip includes: Based on the currently operating metallurgical process segment, retrieve the corresponding process data message format from the process segment-data-equipment mapping table; According to the retrieved process data message format, the current process data is encapsulated, and the corresponding multicast group identifier is inserted into the header of the data frame. A cyclic redundancy check code is entered into the verification field of the data frame. The cyclic redundancy check code is calculated based on the content of the encapsulated data frame. The encapsulated data frame is sent to the SRIO switching chip via the SRIO link, triggering the SRIO switching chip to start the multicast forwarding process.

[0012] As a further aspect of the present invention, the SRIO switching chip performs hardware-level copying of the received data frames according to the multicast forwarding rules in the pre-configured multicast routing table, including: After receiving the data frame, the SRIO switching chip extracts the multicast group identifier contained in the data frame header; Retrieve an entry in the pre-configured multicast routing table that matches the multicast group identifier, and read the outgoing port bitmap recorded in the entry; The output port bitmap is parsed to identify all valid physical port numbers, and these physical port numbers are used as the destination ports for multicast replication. The switching matrix inside the SRIO switching chip is activated, using the ingress port number as the data source and the parsed destination ports as the data output. The input data frame is copied to multiple output channels through a crossbar switch, realizing hardware-level copying from single frame to multiple frames.

[0013] As a further aspect of the present invention, the method also includes a multicast table dynamic maintenance step during metallurgical production process switching: When it is detected that the metallurgical production process is switching from the current process segment to the next process segment, the transmission of process data packets to the SRIO switching chip is suspended. Remove the multicast group identifier and all its binding relationships corresponding to the current process segment from the pre-configured multicast routing table, and release the hardware resources occupied by the multicast group; According to the definition of the next process segment, a new list of actuators is obtained from the process segment-data-device mapping table, and the generation, binding and routing table writing operations of the multicast group identifier are repeated to complete the configuration of the new multicast group; Once the new multicast group is configured, process data packets carrying the new multicast group identifier are resumed to the SRIO switching chip, allowing data synchronization to continue within the new process segment.

[0014] As a further aspect of the present invention, the method further includes a consistency verification step for the pre-configured multicast routing table: After the multicast routing table configuration is completed during the power-on initialization phase of the SRIO switching chip, a multicast table query request is sent to the SRIO switching chip to obtain a copy of the currently effective multicast routing table. The obtained copy of the multicast routing table is compared with the locally built pre-configured multicast routing table entry by entry to check whether the multicast group identifier, ingress port number and egress port bitmap are completely consistent. If inconsistent entries are found, the differences in the entries are recorded, and the routing table write operation corresponding to the entries is re-executed for error correction. After all entries match, a confirmation signal indicating successful multicast routing table configuration is returned to the process control server, allowing normal data transmission to begin.

[0015] As a further aspect of the present invention, the step of filling the verification field of the data frame with a cyclic redundancy check code, wherein the cyclic redundancy check code is calculated based on the content of the encapsulated data frame, includes: Obtain the process data message format corresponding to the current process segment from the process segment-data-equipment mapping table, and determine the range of cyclic redundancy check calculation based on the process data message format. The range includes all payload data after the data frame header and before the check field. A polynomial division operation is performed using a preset generator polynomial as the divisor and the binary bit sequence of the payload data as the dividend. Record the remainder obtained from the polynomial division operation, and use the remainder as the cyclic redundancy check code; The packaged process data is written into the payload area of ​​the data frame. The cyclic redundancy check code is written into the check field of the data frame according to a preset bit order; Based on the complete data frame content after writing the process data and cyclic redundancy check code, its length is recalculated, and the calculated frame length value is filled into the predefined frame length field in the data frame header.

[0016] Compared with the prior art, the advantages and positive effects of the present invention are as follows: During the power-on initialization phase of the SRIO switch chip, the pre-configured metallurgical process flow configuration file is parsed to obtain the process segment definitions divided by process steps and the list of actuators that need to synchronously receive process data within each process segment. This approach advances the parsing of the metallurgical process flow configuration to the chip initialization phase, eliminating the need to temporarily parse configuration information and adjust the actuator list during production. This avoids interference with data transmission caused by configuration operations during production, ensuring that the SRIO switch chip's configuration aligns with the process characteristics of metallurgical production from the initial stage. This reduces configuration redundancy and invalid operations, allowing the switch chip to quickly enter a working state adapted to metallurgical production, achieving precise matching between multicast configuration and metallurgical processes.

[0017] The binding relationship between multicast group identifiers and actuator physical port numbers is written into the pre-configured multicast routing table of the SRIO switching chip. When metallurgical production enters a specific process segment, the SRIO switching chip performs hardware-level replication on the received data frames carrying the corresponding multicast group identifiers based on this pre-configured multicast routing table, and forwards them in parallel through the bound physical ports of each actuator. Hardware-level replication eliminates the need for complex software protocol parsing and forwarding judgment, shortening data processing time. Parallel forwarding allows process data to be transmitted simultaneously to all actuators within the same process segment, eliminating data reception time differences and achieving synchronous distribution of process data. This meets the requirements for coordinated operation of actuators in various process segments of metallurgical production, reduces data transmission latency, and improves the stability and efficiency of data distribution. Attached Figure Description

[0018] Figure 1 This is a timing diagram of the SRIO multicast data transmission system based on multicast table pre-configuration as described in this invention; Figure 2 A flowchart for parsing metallurgical process flow configuration files; Figure 3 A flowchart illustrating the process of generating multicast group identifiers and binding relationships; Figure 4 Performance analysis diagram for output port bitmap parsing; Figure 5 This is a graph showing the performance analysis of SRIO multicast data transmission. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0020] In the description of this invention, it should be understood that the terms "length," "width," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships, are based on the orientation or positional relationships shown in the accompanying drawings and are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, in the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0021] See Figure 1 A pre-configured SRIO multicast data transmission system based on multicast tables is described. During the power-on initialization phase of the SRIO switching chip, the configuration parsing module reads and parses a pre-configured metallurgical process flow configuration file. This file defines the various process segments divided according to metallurgical processes, and a list of actuators within each process segment that need to synchronously receive process data. The multicast binding module, based on the parsed list of actuators, retrieves the physical port number corresponding to each actuator from the address mapping table of the SRIO switching chip. Based on these physical port numbers, a globally unique multicast group identifier is generated for each process segment, and a binding relationship is established between this multicast group identifier and the physical port numbers of all actuators within the process segment. The routing table configuration module converts the established binding relationships into multicast routing table entries conforming to the SRIO protocol specification and writes these entries into the pre-configured multicast routing table of the SRIO switching chip. This table defines hardware multicast forwarding rules from a specific source port to multiple destination ports. In actual metallurgical production, when the process enters a specific technological segment, the process control server encapsulates the current process data according to the data format defined for that segment, fills in the corresponding multicast group identifier in the data frame header, and then sends the data frame to the SRIO switching chip. Upon receiving the data frame, the SRIO switching chip extracts the multicast group identifier, queries the pre-configured multicast routing table, and, based on the outgoing port bitmap information in the matching entry, performs hardware-level copying of the data frame through its internal switching matrix. The copied data frames are then forwarded in parallel through the bound physical ports, thereby achieving synchronous and concurrent delivery of process data to all actuators within the same technological segment.

[0022] In one embodiment of the present invention, when parsing a pre-set metallurgical process flow configuration file, the file header information of the configuration file is read to obtain the file version number and the total number of process segments defined in the file. The main content of the configuration file is traversed, and the process segment number, process segment name, and corresponding process data message format of each process segment are extracted one by one. For each parsed process segment, its associated actuator list is further parsed. This list contains the device ID, device type, and logical address assigned to each actuator in the SRIO network. The parsed process segment number, process data message format, and corresponding actuator list are associated and stored to form a process segment-data-device mapping table. When retrieving the physical port number according to the actuator list, a read request is sent to the SRIO switching chip to obtain the address mapping table maintained internally by the chip. This table records the mapping relationship between logical addresses and physical port numbers in the network. Each actuator in the actuator list is traversed, its device ID is converted into a corresponding logical address, and this logical address is used to look up its corresponding physical port number in the address mapping table. For an actuator whose physical port number is successfully located, check if the port's status bit in the address mapping table is available. If the port status is unavailable, mark the actuator as pending and skip subsequent binding operations. Summarize all available actuators and their corresponding physical port numbers to form a list of valid ports.

[0023] In practical implementation, when parsing the pre-set metallurgical process flow configuration file, refer to... Figure 2The process reads the header information of the metallurgical process flow configuration file to obtain the version number and the total number of process segments defined in the configuration file. For example, in a sample scenario, the header of the metallurgical process flow configuration file contains a version number field and a total number of process segments field. The version number field stores the value "1.2", and the total number of process segments field stores the value "5", indicating that there are five process segments divided by process. The process then iterates through the main content of the metallurgical process flow configuration file, extracting the process segment number, process segment name, and corresponding process data message format for each process segment. In practice, the main content is organized in structured text. For the process segment number "SEG_202", the extracted process segment name is "Rolling Segment", and the process data message format is defined as a fixed-length structure containing temperature, pressure, and speed fields. For each parsed process segment, the process segment is further parsed... The auxiliary actuator list contains the device ID, device type, and logical address of each actuator in the SRIO network. In the data comparison of the example scenario, for process segment number "SEG_202", the actuator list lists three actuators with device IDs "ACTUATOR_ALPHA", "ACTUATOR_BETA", and "ACTUATOR_GAMMA" and corresponding logical addresses "0x00A0", "0x00A1", and "0x00A2" respectively. The parsed process segment number, process data message format, and corresponding actuator list are associated and stored to form a process segment-data-device mapping table. The process segment-data-device mapping table is organized in memory in key-value pair form, where the process segment number is used as the key and the associated process data message format and actuator list are used as values.

[0024] In some embodiments, a depth-first parsing algorithm is used to traverse the main content of the metallurgical process flow configuration file to ensure that the nested structure is correctly expanded. In a specific implementation, when retrieving the physical port number according to the actuator list, a read request is sent to the SRIO switch chip to obtain the address mapping table maintained internally by the SRIO switch chip. The address mapping table records the mapping relationship between logical addresses and physical port numbers in the network. For example, the address mapping table contains multiple entries, each consisting of a logical address field, a physical port number field, and a status bit field. Each actuator in the actuator list is traversed, and the actuator's device ID is converted into the corresponding logical address. The logical address is then used to look up the physical port number corresponding to the logical address in the address mapping table. In the example scenario, for the device ID "ACTUATOR_ALPHA", the physical port number is converted into the physical port number corresponding to the logical address. The obtained logical address "0x00A0" is matched with an entry in the address mapping table. This entry shows a physical port number of "4" and a status bit of "1", indicating that the port is available. For actuators whose physical port numbers are successfully found, the status bit of the physical port number in the address mapping table is checked to see if it is available. If the physical port number is unavailable, the actuator is marked as pending and subsequent binding operations are skipped. For example, if the status bit corresponding to the logical address "0x00A2" in the address mapping table is "0", then the device ID "ACTUATOR_GAMMA" is marked as pending and not included in the list of valid ports. All actuators with available status and their corresponding physical port numbers are summarized to form a list of valid ports. The list of valid ports is stored in an array structure, and each element contains a pair of actuator device IDs and physical port numbers. Optionally, when parsing the metallurgical process flow configuration file, a cyclic redundancy check is performed on the file integrity. The check formula is:

[0025] in: Indicates the verification result. This represents the data in the i-th byte of the configuration file. Represents a pre-defined polynomial constant. This indicates the total number of bytes in the configuration file. This represents an XOR operation. It can be understood that the parsing process of the metallurgical process flow configuration file transforms the text configuration into structured data, providing input for multicast group binding. In some embodiments, the address mapping table is obtained by sending an SRIO type 9 read transaction with a response to the maintenance port of the SRIO switch chip. In specific implementations, the conversion from device ID to logical address is based on a preset conversion mapping table, which is stored independently of the metallurgical process flow configuration file. Optionally, for physical port numbers that are unavailable, the system generates an event log and notifies the upper-layer monitoring interface. It can be understood that the list of valid ports filters out abnormal ports, ensuring the reliability of subsequent bindings.

[0026] In one embodiment of the present invention, when generating a multicast group identifier based on a physical port number, see [reference needed]. Figure 3 Each process segment in the system is assigned a unique process segment index number, selected sequentially from a predefined range. The assigned process segment index number is combined with a system-predefined multicast identifier prefix to generate a multicast group identifier corresponding to that process segment. This identifier must remain globally unique across the entire SRIO network. The list of valid ports generated for the current process segment is traversed, and the generated multicast group identifier is associated with the physical port numbers of all actuators in the list, forming a many-to-many binding table between multicast group identifiers and multiple physical port numbers. Conflict detection is performed on this binding table. If duplicate multicast group identifiers are found in the system, the conflicting process segment index number is incremented to correct the conflict, and its multicast group identifier is regenerated and detected until all multicast group identifiers in the system remain unique. When the established binding relationships are written into the pre-configured multicast routing table of the SRIO switching chip, multicast routing table entries conforming to the SRIO protocol specification are constructed. The table entry structure includes a multicast group identifier field, an ingress port number field, and an egress port bitmap field. In the table entries, the multicast group identifier from the binding relationship is filled into the multicast group identifier field, and the physical port number used by the process control server to connect to the SRIO switch chip is filled into the ingress port number field. Based on the physical port numbers of each actuator included in the binding relationship, the corresponding bits in the egress port bitmap field are set to valid, while the bits corresponding to unbound physical port numbers remain invalid. A write operation is initiated to the register space of the SRIO switch chip through the SRIO configuration transaction, sequentially writing the constructed multicast routing table entries to the register addresses specified by the chip, thereby completing the permanent storage of the pre-configured multicast routing table.

[0027] In practical implementation, when generating multicast group identifiers based on physical port numbers, a unique process segment index number is assigned to each process segment in the system. The process segment index number is selected sequentially from a predefined numerical range. In the example scenario, the predefined numerical range is decimal 1 to 255. For process segment number "SEG_202", its assigned process segment index number is "2". The assigned process segment index number is combined with a pre-defined multicast identifier prefix to generate the multicast group identifier corresponding to the process segment. In data comparison, the pre-defined multicast identifier prefix is ​​the hexadecimal number "0x0100". Combined with the process segment index number "2", the generated multicast group identifier is "0x0102". The system iterates through the list of valid ports generated for the current process segment and compares the generated multicast group identifier with all actuators in the list of valid ports. The system associates the multicast group identifier with the physical port numbers to form a many-to-many binding table. In the example scenario, the valid port list contains physical port numbers "4, 5, 7", and the binding table records that "0x0102" is mapped to ports "4", "5", and "7". Conflict detection is performed on this binding table. If a duplicate multicast group identifier is found in the system, the process segment index number causing the conflict is incremented, and the multicast group identifier is regenerated and detected. In one example of conflict detection, if the identifier "0x0102" generated by the new process segment is duplicated with an existing identifier, the system increments the process segment index number of the new process segment from "2" to "3", thereby generating a new multicast group identifier "0x0103" and performing another detection, until all multicast group identifiers in the system remain unique. In some embodiments, the calculation of the multicast group identifier follows the formula:

[0028] in: This represents the generated multicast group identifier. This represents a system-preset multicast identifier prefix constant. This indicates the process segment index number assigned to the process segment.

[0029] In practical implementation, when writing the established binding relationship into the pre-configured multicast routing table of the SRIO switching chip, a multicast routing table entry conforming to the SRIO protocol specification is constructed. The multicast routing table entry structure includes a multicast group identifier field, an ingress port number field, and an egress port bitmap field. In the example scenario, a multicast routing table entry occupies 32 bits of register space, where the high 16 bits are the multicast group identifier field, the middle 8 bits are the ingress port number field, and the low 8 bits are the egress port bitmap field. In the multicast routing table entry, the multicast group identifier from the binding relationship is filled into the multicast group identifier field, and the physical port number used by the process control server to connect to the SRIO switching chip is filled into the ingress port number field. For example, if the process control server is connected to physical port "0", the ingress port number field is filled with "0". The physical port numbers of each actuator included in the system are set to valid bits in the output port bitmap field. In the example scenario, the binding relationship includes physical port numbers "4, 5, 7", and bits 4, 5, and 7 of the output port bitmap field are set to "1", while the bits corresponding to the unbound physical port numbers "0, 1, 2, 3, 6" remain invalid at "0". A write operation is initiated to the register space of the SRIO switching chip through the SRIO configuration transaction, sequentially writing the constructed multicast routing table entries to the chip's specified register addresses, thereby completing the solidification of the pre-configured multicast routing table. The SRIO configuration transaction is a type 8 maintenance write transaction, and the destination address is the base address of the SRIO switching chip's multicast routing table register plus the offset of the entry index. Optionally, a conflict detection algorithm traverses the entire binding relationship table, comparing whether the value of each multicast group identifier already exists in a global set of used identifiers.

[0030] It is understood that the incremental correction operation is performed cyclically until an unused process segment index number is assigned to the process segment and a unique multicast group identifier is generated. In some embodiments, the bit settings in the output port bitmap field follow the formula:

[0031] in: This indicates the final bitmap value to be written to the port bitmap field. This represents a bitmap cumulative value that is initially set to 0. This represents the value of each physical port number in the binding relationship. It iterates through all bound physical port numbers k, performing a bitwise OR operation to accumulate the values. In practice, the initiation of SRIO configuration transactions needs to follow the correct timing, inserting necessary delay periods between two write operations. Optionally, after writing the multicast routing table entry, a readback operation is immediately initiated to verify the correctness of the written data, but this readback verification step is independent of the consistency check step. It can be understood that by maintaining the write transaction configuration routing table, the standard maintenance functions of the SRIO protocol are utilized, without the need for customized hardware operations.

[0032] In one embodiment of the present invention, when the process control server sends a data frame carrying a multicast group identifier to the SRIO switching chip, the process data message format corresponding to the current process segment in the metallurgical production process is retrieved from the process segment-data-device mapping table. The real-time process data to be sent is encapsulated strictly according to the retrieved process data message format, and the multicast group identifier corresponding to the process segment is inserted into the header of the assembled data frame. A cyclic redundancy check (CRC) code is filled into the check field of the data frame; this check code is calculated based on the encapsulated data frame content. The encapsulated and checked complete data frame is sent to the SRIO switching chip via the SRIO physical link. When calculating the CRC code, the process data message format corresponding to the current process segment is obtained from the process segment-data-device mapping table. Based on this format, the data range covered by the CRC calculation is determined, which includes all payload data after the data frame header and before the check field. A polynomial division operation is performed using a system-preset generator polynomial as the divisor and the binary bit sequence of the payload data as the dividend. Record the remainder obtained after polynomial division and use this remainder as the cyclic redundancy check (CRC) code. Write the process data to be sent into the payload area of ​​the data frame. Write the calculated CRC code into the check field of the data frame according to a preset bit order. Based on the complete data frame content containing the written process data and CRC code, recalculate its total length and fill the predefined frame length field in the data frame header with the calculated frame length value.

[0033] In practical implementation, when the process control server sends a data frame carrying a multicast group identifier to the SRIO switching chip, it retrieves the corresponding process data message format from the process segment-data-equipment mapping table based on the current process segment in the metallurgical production process. For example, for process segment number "SEG_202", its process data message format is defined as a fixed 16-byte structure, including a 2-byte frame header, a 4-byte temperature value, a 4-byte pressure value, a 4-byte speed value, a 1-byte multicast group identifier, and a 1-byte cyclic redundancy check code. The real-time process data to be sent is strictly encapsulated according to the retrieved process data message format, and the multicast group identifier corresponding to the process segment is inserted into the header of the assembled data frame. In the example scenario, the group identifier in the encapsulated data frame is set to "0x000003E8" (corresponding to 1000 degrees), "0x00002710" (corresponding to 10000 kPa), and "0x00000064" (corresponding to 100 mm / s). The predefined multicast group identifier field in the data frame header is set to "0x02". The checksum field of the data frame is set to Cyclic Redundancy Check (CRC) code, which is calculated based on the content of the encapsulated data frame. The encapsulated and checked complete data frame is sent to the SRIO switching chip via the SRIO physical link, which has a transmission rate of 5 gigabits per second. When calculating the Cyclic Redundancy Check (CRC) code, the process data message format corresponding to the current process segment is obtained from the process segment-data-equipment mapping table. Based on the process data message format, the data range covered by the CRC calculation is determined. The data range includes all payload data after the data frame header and before the check field. In the example scenario comparison, for the "SEG_202" process segment, the payload data includes temperature, pressure, and speed fields, totaling 12 bytes. A polynomial division operation is performed using a system-preset generator polynomial as the divisor and the binary bit sequence of the payload data as the dividend. In some embodiments, the generator polynomial adopts the CRC-8 standard polynomial. The corresponding binary sequence of the divisor is "100000111". The remainder obtained after polynomial division is recorded and used as the cyclic redundancy check code. For example, the 8-bit remainder obtained after calculating 12 bytes of payload data is "0x1C", and the cyclic redundancy check code is "0x1C".

[0034] In specific implementation, the process data to be sent is written into the payload area of ​​the data frame, and the starting offset address of the payload area in the data frame is fixed. The calculated cyclic redundancy check (CRC) code is written into the check field of the data frame according to a preset bit order. Optionally, byte order conversion needs to be performed when writing the CRC code into the check field to match the byte order of the SRIO link transmission. Based on the complete data frame content with the written process data and CRC code, the total length of the complete data frame content is recalculated, and the calculated frame length value is filled into the predefined frame length field in the data frame header. The frame length field occupies 2 bytes. It can be understood that the calculation of the CRC code covers the core process data except for the frame header and its own check field, providing the basis for data integrity verification. In some embodiments, the polynomial division operation is performed in the dedicated hardware coprocessor of the process control server, and the operation follows the formula:

[0035] in: This represents the remainder of the calculated cyclic redundancy check code. Integer values ​​representing payload data, This indicates the bit width of the cyclic redundancy check code (8 bits in this case). This represents the integer value corresponding to the generator polynomial. This indicates a modulo operation. In practical implementations, in addition to the multicast group identifier field and frame length field, the data frame header also includes a control field to identify the frame type and priority. Optionally, before sending a data frame via the SRIO link, it is temporarily stored in a first-in-first-out transmission queue, and then retrieved and sent in sequence by the SRIO link controller. It can be understood that the padding of the frame length field ensures that the SRIO switching chip can correctly parse the boundaries of the data frame.

[0036] In one embodiment of the present invention, when the SRIO switching chip performs hardware-level copying of received data frames according to the multicast forwarding rules in the pre-configured multicast routing table, after receiving a data frame from the process control server, the chip first extracts the multicast group identifier carried in the header of the data frame. The chip uses the extracted multicast group identifier as a query key to search its pre-configured multicast routing table for a matching multicast routing table entry and reads the outgoing port bitmap information recorded in that entry. The chip parses the read outgoing port bitmap, identifying all bits set to a valid state. Each valid bit corresponds to a physical port number that needs to forward data; these port numbers constitute the destination port set for this multicast copying. The switching matrix inside the SRIO switching chip is activated, using the ingress port number of the received data frame as the data source and all parsed destination port numbers as the data output. The input data stream is copied to multiple output channels via a crossbar switch, realizing the hardware-level copying of a single input data frame into multiple output data frames.

[0037] In practical implementation, when the SRIO switching chip performs hardware-level copying of received data frames according to the multicast forwarding rules in the pre-configured multicast routing table, after receiving a data frame from the process control server, the SRIO switching chip first extracts the multicast group identifier carried in the header of the data frame. In an example scenario, a 1-byte multicast group identifier field is stored at a specific offset byte position in the header of the data frame. The receiving logic of the SRIO switching chip parses this field to obtain the value "0x02". The SRIO switching chip uses the extracted multicast group identifier as a query key to search in its pre-configured multicast routing table, looking for a multicast routing table entry that completely matches the multicast group identifier, and reads the outgoing port bitmap information recorded in the multicast routing table entry. The pre-configured multicast routing table is stored in the content-addressable memory inside the SRIO switching chip, supporting fast lookup based on the multicast group identifier. The read outgoing port bitmap is analyzed to identify all bits set to valid status. Each valid bit corresponds to a physical port number that needs to forward data. These physical port numbers constitute the destination port set for this multicast replication. In a data comparison scenario, the retrieved outgoing port bits... Figure 2The binary sequence "10011000" indicates that the bits corresponding to physical port numbers 3, 4, and 7 are 1 (valid state). Therefore, the destination port set includes physical ports 3, 4, and 7. The switching matrix inside the SRIO switching chip is activated, using the ingress port number of the received data frame as the data source and all parsed destination port numbers as the data output. A crossbar switch copies the input data stream to multiple output channels, achieving hardware-level duplication of a single input data frame into multiple output data frames. The duplication operation of the switching matrix is ​​completed within one clock cycle. The input data frame enters the input buffer of the switching matrix from the ingress port number. Subsequently, according to the output port bitmap, the control logic of the switching matrix simultaneously activates the output links pointing to all ports in the destination port set and copies the data in the input buffer to the corresponding transmit buffer of each activated output link. Refer to Table 1, which shows the contents of a multicast routing table entry matching the example.

[0038] Table 1: Multicast Routing Table ; In some embodiments, the parsing process of the output port bitmap involves a bit scan operation to quickly locate all bits set to 1, and its index calculation can be described as follows:

[0039] in: This represents the j-th valid physical port number identified. The index starts from 0. This represents the integer value read from the output port bitmap, function Indicates the value from the bitmap The operation extracts the index of the j-th set bit. In a specific implementation, the crossbar switch of the switching matrix is ​​composed of a multiplexer array, and its connection status is configured in real time by the output port bitmap. When the output port bitmap value is "0x98" (binary 10011000), the physical path connecting the input buffer to output port 3, output port 4, and output port 7 in the crossbar switch array is connected. It can be understood that each bit that is 1 in the output port bitmap directly controls the enable signal of a corresponding output link in the switching matrix. Optionally, after the SRIO switching chip copies the data frame to the transmit buffer of multiple output ports, it will independently add the link layer control information of the destination port to each copied data frame. In some embodiments, the hardware-level copying delay is deterministic and does not increase linearly with the increase of the number of destination ports because the broadcast capability of the switching matrix allows data to be written to multiple ports in parallel. In a specific implementation, if the parsed output port bitmap is all 0, it means that there is no valid destination port, and the SRIO switching chip will discard the received data frame and may generate an error event. It is understandable that by querying the pre-configured multicast routing table and parsing the port bitmap, the SRIO switching chip can determine all target paths for data distribution without software intervention. Optionally, while replicating data frames, the switching matrix maintains the original priority markers of the data frames to ensure that the scheduling order of each replicated frame on the output port is consistent with that of the input frames.

[0040] See Figure 4 This is a performance analysis chart for output port bitmap parsing, showing the impact of output port bitmap length on parsing performance during the routing table retrieval phase of the SRIO chip. As the bitmap length increases from 8 bits to 128 bits, the parsing time increases significantly from 12 nanoseconds to 75 nanoseconds, exhibiting an almost linear growth trend. This indicates that the complexity of the bit scan operation is positively correlated with the bitmap length; longer bitmaps require more clock cycles to locate all set bits. The parsing error rate slowly increases from 0.01% to 0.10%, remaining at an extremely low level overall, but also reflecting a slight increase in the probability of misjudgments in the hardware parsing logic as bitmap complexity increases. When the bitmap length exceeds 64 bits, the growth slope of the parsing time becomes significantly steeper, which may become a performance bottleneck for SRIO chips in high-density port scenarios.

[0041] In one embodiment of the present invention, a multicast table dynamic maintenance step is performed during metallurgical production process switching. When the system detects that the metallurgical production process is about to switch from the current process segment to the next process segment, the transmission of process data packets belonging to the current process segment to the SRIO switching chip is paused. The routing table entry consisting of the multicast group identifier corresponding to the current process segment and all its port binding relationships is deleted from the pre-configured multicast routing table of the SRIO switching chip, releasing the hardware routing resources occupied by the multicast group. According to the definition of the next process segment to be entered, the new list of actuators corresponding to the process segment is obtained from the process segment-data-device mapping table, and the generation of the multicast group identifier, the establishment of binding relationships, and the writing of routing table entries are re-executed, thereby completing the multicast group configuration suitable for the new process segment. After the new multicast group is configured in the SRIO switching chip, the transmission of process data packets to the SRIO switching chip resumes. At this time, the packets carry the multicast group identifier corresponding to the new process segment, allowing the data synchronization process to continue within the new process segment. After the multicast routing table configuration is completed during the power-on initialization phase of the SRIO switching chip, a consistency verification step is performed on the pre-configured multicast routing table. A multicast table query request is sent to the SRIO switching chip to obtain a copy of the multicast routing table that is currently effective within the chip. The obtained copy of the multicast routing table within the chip is compared item by item with the pre-configured multicast routing table that is built locally by the system and expected to be written. The contents of the multicast group identifier, ingress port number, and egress port bitmap fields in each entry are checked to ensure they are completely consistent. If any inconsistent entries are found during the comparison, the detailed differences between these entries are recorded, and the routing table write operation for the inconsistent entries is re-executed to correct the configuration within the chip. After all multicast routing table entries are consistent, a confirmation signal of successful multicast routing table configuration is returned to the process control server, after which the system allows normal metallurgical process data transmission to begin.

[0042] In practical implementation, a dynamic maintenance step for the multicast table is performed during metallurgical production process switching. When the system detects that the metallurgical production process is about to switch from the current process segment to the next process segment, it suspends the transmission of process data packets belonging to the current process segment to the SRIO switching chip. The system triggers the process switching event by monitoring the host computer's production instructions or sensor status changes. For example, in the example scenario of switching from the "rolling segment" to the "annealing segment," the process control server immediately stops sending data frames carrying the multicast group identifier "0x0102" after receiving the switching instruction. From the pre-configured multicast routing table of the SRIO switching chip, the routing table entry consisting of the multicast group identifier corresponding to the current process segment and all its port binding relationships is deleted, releasing the hardware routing resources occupied by the multicast group. The deletion operation is completed by sending a maintenance write transaction to the SRIO switching chip for the specific multicast group identifier register address. The written data is all zeros to clear the table entry. In the example, the deletion target is the routing table entry corresponding to the multicast group identifier "0x0102".

[0043] Based on the definition of the next process segment to be entered, the system retrieves the new actuator list corresponding to the process segment from the process segment-data-device mapping table, and re-executes the multicast group identifier generation, binding relationship establishment, and routing table entry writing operations to complete the multicast group configuration suitable for the new process segment. For the "annealing segment," its new actuator list may contain devices different from those in the "rolling segment," such as physical port numbers "2, 6, 8." The system generates a new multicast group identifier "0x0103" and establishes a binding, and writes the new routing table entry to the SRIO switching chip. After the new multicast group is configured in the SRIO switching chip, the system resumes sending process data packets to the SRIO switching chip. At this time, the packets carry the multicast group identifier corresponding to the new process segment, allowing the data synchronization process to continue within the new process segment. The process control server begins sending data frames carrying the multicast group identifier "0x0103" and encapsulating the annealing segment process data. After the multicast routing table configuration is completed during the power-on initialization phase of the SRIO switching chip, a consistency check step is performed on the pre-configured multicast routing table. A multicast table query request is sent to the SRIO switching chip to obtain a copy of the multicast routing table that is currently effective within the chip. The query request is a read transaction that iterates through all multicast group identifier register addresses. The obtained chip-internal multicast routing table copy is compared item by item with the pre-configured multicast routing table that is built locally by the system and expected to be written. The multicast group identifier, ingress port number, and egress port bitmap fields in each entry are checked to ensure they are completely consistent. The comparison process is performed byte by byte in software. If inconsistent entries are found during the comparison, the detailed difference information of the inconsistent entries is recorded, and the routing table write operation for the inconsistent entries is re-executed to correct the configuration within the chip. The detailed difference information of the inconsistent entries includes the register address, expected value, and read value. After all multicast routing table entries are consistent, a confirmation signal of successful multicast routing table configuration is returned to the process control server. After this, the system allows normal metallurgical process data transmission to begin.

[0044] In some embodiments, a difference metric is calculated during item-by-item comparison. This difference metric is used to quantify the difference in a single field as follows:

[0045] in: This represents the difference measure value of the k-th field in the table entry. This indicates the expected value of this field in the system's locally pre-configured multicast routing table. This represents the actual value of the corresponding field in the multicast routing table copy read from the SRIO switching chip. This indicates the absolute value operation, when any field... A value greater than 0 indicates inconsistency in the table entries. In practice, multicast table query requests are sent via a series of SRIO type 8 maintenance read transactions, each retrieving the content of one multicast routing table entry. This dynamic maintenance step ensures that the multicast routing configuration updates as the production process changes. Optionally, detailed information on recorded inconsistency entries is stored in non-volatile memory for subsequent system diagnostic analysis. In some embodiments, there is a defined upper limit to the total time from detecting a process switching instruction to completing the new multicast group configuration and resuming data transmission; this upper limit is determined by the fixed delay of the configuration transaction and the number of entries. In practice, the configuration success confirmation signal returned to the process control server is a rising edge pulse generated on a specific hardware pin or a specific message frame sent through the communication interface. This consistency check step is part of the initialization process, used to verify whether the hardware configuration accurately loads the software-defined routing rules. Optionally, after a consistency check fails and error correction is performed, the system re-initiates a complete multicast table query and comparison until all entries match.

[0046] See Figure 5 This is a performance analysis chart of SRIO multicast data transmission, showing the trends of three core performance indicators of the SRIO multicast data transmission system over a 60-second period. Throughput initially rises and then falls, peaking around 15-20 seconds before gradually decreasing to approximately 900 Mbps. The dramatic fluctuations in the curve indicate significant traffic jitter during data transmission, which closely matches the scenarios of process segment switching and data bursts in metallurgical production. Latency is negatively correlated with throughput; high throughput results in low latency, while decreasing throughput leads to increased latency. Latency gradually increases from approximately 500 ms initially to approximately 400 ms later, reflecting the increased queuing and processing time for data forwarding as system load changes. The packet loss rate remains at an extremely low level, close to 0%, with the curve almost touching the horizontal axis. This demonstrates that the SRIO hardware-level multicast replication mechanism is highly reliable, effectively preventing data loss even under high throughput and high latency fluctuations, meeting the stringent data integrity requirements of the metallurgical industry.

[0047] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A SRIO multicast data transmission system based on multicast table pre-configuration, characterized in that, The system includes: The configuration parsing module parses the pre-set metallurgical process flow configuration file during the power-on initialization phase of the SRIO switching chip to obtain the process segment definition divided by process and the list of actuators that need to receive process data synchronously within each process segment. The multicast binding module retrieves the physical port number corresponding to each actuator from the address mapping table of the SRIO switching chip according to the actuator list, generates a multicast group identifier based on the physical port number, and establishes a binding relationship between the multicast group identifier and the physical port number of the actuator. The routing table configuration module writes the established binding relationship into the pre-configured multicast routing table of the SRIO switching chip. The pre-configured multicast routing table is used to define multicast forwarding rules from a specific source port to multiple destination ports. When the metallurgical production process enters a specific process segment, the data distribution module sends a data frame carrying the multicast group identifier to the SRIO switching chip via the process control server. The data frame contains process data that needs to be synchronously distributed. The SRIO switching chip performs hardware-level copying of the received data frame according to the multicast forwarding rules in the pre-configured multicast routing table, and forwards the multiple copies of the data frame in parallel through the physical ports of each bound actuator, so that the process data reaches all actuators in the process segment simultaneously.

2. The SRIO multicast data transmission system based on multicast table pre-configuration according to claim 1, characterized in that, The parsed pre-set metallurgical process flow configuration file includes: Read the header of the metallurgical process flow configuration file to obtain the version number and total number of process segments of the metallurgical process flow configuration file; Traverse the main content of the metallurgical process flow configuration file and extract the process segment number, process segment name and process data message format corresponding to each process segment; For each process segment, its associated list of actuators is further analyzed. The list of actuators includes the device ID, device type, and logical address of the actuator in the SRIO network. The parsed process segment number, process data message format, and actuator list are associated and stored to form a process segment-data-equipment mapping table for subsequent multicast group configuration.

3. The SRIO multicast data transmission system based on multicast table pre-configuration according to claim 2, characterized in that, Based on the list of actuators, the physical port number corresponding to each actuator is retrieved from the address mapping table of the SRIO switching chip, including: Send a read request to the SRIO switching chip to obtain the address mapping table maintained internally by the SRIO switching chip. The address mapping table records the mapping relationship between logical addresses and physical port numbers. Iterate through each actuator in the list of actuators, convert its device ID into the corresponding logical address, and look up the physical port number corresponding to the logical address in the address mapping table; For the physical port number that is found, check whether its status bit is available. If it is not available, mark the actuator as pending and skip the subsequent binding operation. The list of valid ports is composed of the available actuators and their corresponding physical port numbers. This list is used for the subsequent generation of multicast group identifiers.

4. The SRIO multicast data transmission system based on multicast table pre-configuration according to claim 3, characterized in that, Generate a multicast group identifier based on the physical port number, and establish a binding relationship between the multicast group identifier and the physical port number of the execution mechanism, including: Each process segment is assigned a unique process segment index number, which is selected sequentially from a predefined range of values. The process segment index number is combined with a preset multicast identifier prefix to generate the multicast group identifier corresponding to the process segment. The multicast group identifier is globally unique in the SRIO network. Traverse the list of valid ports and associate the generated multicast group identifier with the physical port number of all actuators in the list of valid ports to form a many-to-many binding relationship table; Conflict detection is performed on the binding relationship table. If there are duplicate multicast group identifiers, the corresponding process segment index number is incremented to correct them until all multicast group identifiers remain unique in the system.

5. The multicast table preconfigured based SRIO groupcast data transmission system according to claim 4, characterized in that, The step of writing the established binding relationship into the pre-configured multicast routing table of the SRIO switching chip includes: Construct a multicast routing table entry that conforms to the SRIO protocol specification. The multicast routing table entry includes a multicast group identifier field, an ingress port number field, and an egress port bitmap field. Fill the multicast group identifier in each of the binding relationships into the multicast group identifier field, and fill the connection port number of the process control server into the ingress port number field; Based on the physical port number of each actuator in the binding relationship, set the corresponding bit in the output port bitmap field to the valid state, and keep the bit corresponding to the unbound physical port number in the invalid state; By initiating a write operation to the register space of the SRIO switching chip through the SRIO configuration transaction, the constructed multicast routing table entries are sequentially written to the specified register addresses, thus completing the solidification of the pre-configured multicast routing table.

6. The multicast table preconfigured based SRIO groupcast data transmission system according to claim 5, characterized in that, The process control server sending a data frame carrying the multicast group identifier to the SRIO switching chip includes: Based on the currently operating metallurgical process segment, retrieve the corresponding process data message format from the process segment-data-equipment mapping table; According to the retrieved process data message format, the current process data is encapsulated, and the corresponding multicast group identifier is inserted into the header of the data frame. A cyclic redundancy check code is entered into the verification field of the data frame. The cyclic redundancy check code is calculated based on the content of the encapsulated data frame. The encapsulated data frame is sent to the SRIO switching chip via the SRIO link, triggering the SRIO switching chip to start the multicast forwarding process.

7. The multicast table preconfigured based SRIO groupcast data transmission system according to claim 6, characterized in that, The SRIO switching chip performs hardware-level copying of the received data frames according to the multicast forwarding rules in the pre-configured multicast routing table, including: After receiving the data frame, the SRIO switching chip extracts the multicast group identifier contained in the data frame header; Retrieve an entry in the pre-configured multicast routing table that matches the multicast group identifier, and read the outgoing port bitmap recorded in the entry; The output port bitmap is parsed to identify all valid physical port numbers, and these physical port numbers are used as the destination ports for multicast replication. The switching matrix inside the SRIO switching chip is activated, using the ingress port number as the data source and the parsed destination ports as the data output. The input data frame is copied to multiple output channels through a crossbar switch, realizing hardware-level copying from single frame to multiple frames.

8. The SRIO multicast data transmission system based on multicast table pre-configuration according to claim 7, characterized in that, The method also includes a dynamic maintenance step for multicast tables during metallurgical production process switching: When it is detected that the metallurgical production process is switching from the current process segment to the next process segment, the transmission of process data packets to the SRIO switching chip is suspended. Remove the multicast group identifier and all its binding relationships corresponding to the current process segment from the pre-configured multicast routing table, and release the hardware resources occupied by the multicast group; According to the definition of the next process segment, a new list of actuators is obtained from the process segment-data-device mapping table, and the generation, binding and routing table writing operations of the multicast group identifier are repeated to complete the configuration of the new multicast group; Once the new multicast group is configured, process data packets carrying the new multicast group identifier are resumed to the SRIO switching chip, allowing data synchronization to continue within the new process segment.

9. The SRIO multicast data transmission system based on multicast table pre-configuration according to claim 8, characterized in that, The method further includes a consistency verification step for the pre-configured multicast routing table: After the multicast routing table configuration is completed during the power-on initialization phase of the SRIO switching chip, a multicast table query request is sent to the SRIO switching chip to obtain a copy of the currently effective multicast routing table. The obtained copy of the multicast routing table is compared with the locally built pre-configured multicast routing table entry by entry to check whether the multicast group identifier, ingress port number and egress port bitmap are completely consistent. If inconsistent entries are found, the differences in the entries are recorded, and the routing table write operation corresponding to the entries is re-executed for error correction. After all entries match, a confirmation signal indicating successful multicast routing table configuration is returned to the process control server, allowing normal data transmission to begin.

10. The SRIO multicast data transmission system based on multicast table pre-configuration according to claim 9, characterized in that, The step of filling the verification field of the data frame with a cyclic redundancy check code, which is calculated based on the content of the encapsulated data frame, includes: Obtain the process data message format corresponding to the current process segment from the process segment-data-equipment mapping table, and determine the range of cyclic redundancy check calculation based on the process data message format. The range includes all payload data after the data frame header and before the check field. A polynomial division operation is performed using a preset generator polynomial as the divisor and the binary bit sequence of the payload data as the dividend. Record the remainder obtained from the polynomial division operation, and use the remainder as the cyclic redundancy check code; The packaged process data is written into the payload area of ​​the data frame. The cyclic redundancy check code is written into the check field of the data frame according to a preset bit order; Based on the complete data frame content after writing the process data and cyclic redundancy check code, its length is recalculated, and the calculated frame length value is filled into the predefined frame length field in the data frame header.

Images