Multi-protocol cooperative communication architecture of a robot joint module

Abstract

This invention discloses a multi-protocol collaborative communication architecture for a robot joint module. The invention relates to the field of collaborative communication architecture technology and includes: a protocol adaptation layer, a data conversion layer, a scheduling and control layer, and a security encapsulation layer. The protocol adaptation layer comprises a protocol frame identification unit (PRI) and a data parsing unit (PDU) for receiving heterogeneous data frames input from an external communication bus. By constructing a multi-protocol collaborative communication architecture with a protocol adaptation layer, data conversion layer, scheduling and control layer, and security encapsulation layer in the robot joint module, this invention achieves the identification, parsing, and unified encapsulation of heterogeneous communication protocol data. This enables efficient transmission of joint control commands and status data within the same communication framework. Through protocol frame identification and field normalization mapping mechanisms, the invention reduces the data parsing complexity in multi-protocol scenarios, improves the communication compatibility and system integration efficiency of the robot joint module in a multi-bus environment, and enhances the stability of the entire system.

Description

Technical Field

[0001] This invention relates to the field of collaborative communication architecture technology, specifically a multi-protocol collaborative communication architecture for robot joint modules. Background Technology

[0002] With the rapid development of industrial robots, intelligent manufacturing, and high-end equipment systems, the joint module, as the core execution unit of the robot, has a decisive impact on the overall performance of the machine due to its control accuracy and response efficiency. In order to achieve high-performance collaborative control, different manufacturers and system integrators have introduced a variety of communication protocols into robot joint modules, such as EtherCAT, CANopen, Modbus, and VDA5050, to meet the needs of real-time data interaction and functional integration between different devices. Current multi-protocol communication systems face adaptation complexities due to protocol heterogeneity, requiring the development of independent communication parsing logic for each protocol, which increases development costs; scheduling control lacks bandwidth awareness and task priority mechanisms, making it difficult to guarantee the priority transmission of data for real-time tasks under complex loads. To address the aforementioned technical shortcomings, a solution is proposed. Summary of the Invention

[0003] To address the shortcomings of existing technologies, this invention provides a multi-protocol collaborative communication architecture for robot joint modules. This architecture supports multiple industrial communication protocols while enabling standardized data format conversion, intelligent bandwidth scheduling, and secure encrypted transmission, thereby improving the system's communication compatibility, real-time performance, and reliability.

[0004] To achieve the above objectives, the present invention provides the following technical solution: a multi-protocol cooperative communication architecture for a robot joint module, comprising: Protocol adaptation layer, data conversion layer, scheduling control layer, and security encapsulation layer; The protocol adaptation layer includes a protocol frame identification unit (PRI) and a data parsing unit (PDU), which are used to receive heterogeneous data frames input from an external communication bus and output them to the data conversion layer. The data conversion layer converts the heterogeneous data frames into a unified data format according to the corresponding rules of the Protocol Mapping Table (PMT), and outputs the unified data frame UDF to the scheduling control layer. The scheduling control layer includes a priority judgment unit (PJU) and a resource allocation unit (RDA). It performs priority judgment based on the task type field of the unified data frame UDF and dynamically allocates communication resources in combination with the bandwidth occupancy status. The security encapsulation layer is used to perform 128-bit key encryption on the unified data frame UDF, and to perform access token verification and device identity and permission confirmation.

[0005] In the protocol adaptation layer, the Protocol Frame Identification Unit (PRI) and the Data Parsing Unit (PDU) work together: The protocol frame identification unit PRI performs a frame header parsing operation on the input data frame, extracts the protocol identifier field PID from the preset frame header offset position, and matches the protocol identifier field PID with the local protocol feature table to determine the protocol type corresponding to the current data frame. The protocol identifier field PID is a protocol code with a length of 2 bytes. The data parsing unit (PDU) decomposes the original data frame according to the matched protocol specifications, based on the field start address and field length parameters. It extracts the joint torque command parameter (tor), the joint angle parameter (ang), and the status byte parameter (sta), and maps them to a unified intermediate representation parameter set. The torque (tor) is obtained using the following normalization formula: tor=(Raw_tor−Off) / Sca Wherein, Raw_tor is the torque count value read from the original protocol frame, Off is the zero-bias calibration amount corresponding to the protocol, and Sca is the torque dimension scaling factor; after the angle ang and the state sta are converted into parameters according to the same mapping rule, they form an intermediate representation parameter set with the torque tor and are output to the data conversion layer.

[0006] The data conversion layer encapsulates a unified data frame UDF, and adopts the following structure and process: The system receives an intermediate representation parameter set from the data parsing unit (PDU) of the protocol adaptation layer, including torque (tor), angle (ang), and speed (vel). Based on a preset field mapping structure, it performs a format conversion and encapsulates the above parameters into a JSON format data body. The UDF data frame structure consists of three parts: a frame header field (HDR), formatted as follows: protocol identifier (PID), timestamp (TS), and device address.

[0007] After generating a unified data frame UDF, the data conversion layer performs cyclic redundancy check (CRC) processing on the frame header field and the data body field. The CRC check employs a 16-bit CRC parameter and includes: The frame header field and the data body field are concatenated in byte order to form a data stream to be verified. Then, XOR and shift operations are performed byte by byte on the data stream to be verified using a preset initial verification value. The verification operation is based on generator polynomial iterative calculation to obtain a 16-bit verification field. The verification field is appended to the end of the unified data frame UDF; the same verification operation is performed on the unified data frame UDF, and the calculation result is compared with the verification field for consistency. If the comparison result is inconsistent, the data frame is determined to be transmitted incorrectly and a retransmission is triggered.

[0008] The resource allocation unit RDA in the scheduling control layer includes a task load monitoring module LMT and a bandwidth allocation calculation module BDC. The task load monitoring module LMT is used to statistically analyze the cumulative data packet sizes B1, B2, and B3 of the three types of communication tasks in real time during each scheduling cycle. Combined with the current system communication cycle Tcur and the maximum link bandwidth Bmax, it calculates the instantaneous bandwidth occupancy rate Rload. Wherein, B1 represents the cumulative number of effective data packet bytes occupied by the priority 1 emergency control instruction task in the current scheduling period, B2 represents the cumulative number of effective data packet bytes occupied by the priority 2 periodic status data task in the current scheduling period, and B3 represents the cumulative number of effective data packet bytes occupied by the priority 3 non-real-time log task in the current scheduling period. B1, B2, and B3 are all obtained by the task load monitoring module LMT by counting the bytes of the data frames that have been sent. Bmax represents the maximum available bandwidth value allowed at the protocol layer for the current communication link.

[0009] The bandwidth allocation calculation module BDC determines the current load level based on the instantaneous bandwidth occupancy rate Rload. When Rload ≥ 0.8, it triggers a bandwidth reallocation strategy: freezes the scheduling of priority 3 tasks, limits the bandwidth of priority 2 tasks to 20%, and allocates all remaining bandwidth resources to priority 1 tasks. The bandwidth allocation calculation module (BDC) adopts a time-slice-based round-robin scheduling mechanism, which allocates scheduling time windows to tasks of different priorities proportionally under normal bandwidth conditions.

[0010] In the secure encapsulation layer, the unified data frame UDF is encrypted: Extract the frame header information from the unified data frame UDF and generate the corresponding initialization vector IV. The IV is 16 bytes long and is calculated using the following rules: Among them, the protocol identifier IDproto, timestamp TS and device address ADDR are all derived from the UDF frame header field, and the first 16 bytes are extracted after MD5 digest as the encryption vector; Encryption uses AES-CBC mode and is based on a 128-bit symmetric key. After encryption, the ciphertext frame and the corresponding IV field are encapsulated together into an encrypted data packet EDP.

[0011] The secure encapsulation layer processing flow includes: Perform CRC16 verification on the header and body fields of the Unified Data Frame (UDF) to generate an integrity verification result (CLR). When the verification result meets the preset consistency conditions, trigger the encryption process. The initialization vector generation subunit performs concatenation calculations based on the protocol identifier ID, timestamp TS, and device address ADR in the frame header to generate an initialization vector IV with a length of 16 bytes, and writes the initialization vector IV into the encryption context; The 128-bit session key is invoked, and the data body field of the UDF is encrypted block by block using AES-CBC encryption mode, which divides the data body field of the UDF into 128-bit blocks to generate the corresponding encrypted data block sequence. The encrypted data block sequence, initialization vector IV, and check field are re-encapsulated to form an encrypted data frame EDF; Based on the device's unique identifier (UID) and access token (Tok), a validity check is performed. If the authentication result is successful, the encrypted data frame (EDF) is allowed to enter the communication sending queue; otherwise, the data is discarded.

[0012] This invention provides a multi-protocol cooperative communication architecture for robot joint modules. Compared with existing technologies, it has the following advantages: This invention constructs a multi-protocol collaborative communication architecture in the robot joint module, which includes a protocol adaptation layer, a data conversion layer, a scheduling and control layer, and a security encapsulation layer. This architecture enables the identification, parsing, and unified encapsulation of heterogeneous communication protocol data, allowing joint control commands and status data to be transmitted efficiently within the same communication framework. Through protocol frame identification and field normalization mapping mechanisms, the complexity of data parsing in multi-protocol scenarios is reduced, improving the communication compatibility and system integration efficiency of the robot joint module in a multi-bus environment, and enhancing the stability of the entire system. This invention introduces a dynamic bandwidth allocation mechanism based on task priority and a secure encapsulation process. It performs differentiated resource scheduling for different types of communication tasks based on monitoring communication load, and prioritizes the transmission reliability of emergency control commands under high load conditions. Combined with CRC check, AES encryption and identity authentication mechanisms, it achieves multiple guarantees for data integrity, confidentiality and access legitimacy. It can effectively avoid the risks of communication congestion, data tampering and unauthorized access, and improve the operational safety and real-time control reliability of robot joint modules in complex industrial application scenarios. Attached Figure Description

[0013] Figure 1 This is a schematic diagram of the principle framework of the present invention. Detailed Implementation

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

[0015] Please see Figure 1 This application provides a multi-protocol cooperative communication architecture for a robot joint module, including: Protocol adaptation layer, data conversion layer, scheduling control layer, and security encapsulation layer; The protocol adaptation layer includes a protocol frame identification unit (PRI) and a data parsing unit (PDU), which are used to receive heterogeneous data frames input from an external communication bus and output them to the data conversion layer. The data conversion layer converts the heterogeneous data frames into a unified data format according to the corresponding rules of the Protocol Mapping Table (PMT), and outputs the unified data frame UDF to the scheduling control layer. The scheduling control layer includes a priority judgment unit (PJU) and a resource allocation unit (RDA). It performs priority judgment based on the task type field of the unified data frame UDF and dynamically allocates communication resources in combination with the bandwidth occupancy status. The security encapsulation layer is used to perform 128-bit key encryption on the unified data frame UDF, and to perform access token verification and device identity and permission confirmation.

[0016] In the protocol adaptation layer, the Protocol Frame Identification Unit (PRI) and the Data Parsing Unit (PDU) work together: The protocol frame identification unit PRI performs a frame header parsing operation on the input data frame, extracts the protocol identifier field PID from the preset frame header offset position, and matches the protocol identifier field PID with the local protocol feature table to determine the protocol type corresponding to the current data frame. The protocol identifier field PID is a protocol code with a length of 2 bytes. The data parsing unit (PDU) decomposes the original data frame according to the matched protocol specifications, based on the field start address and field length parameters. It extracts the joint torque command parameter (tor), the joint angle parameter (ang), and the status byte parameter (sta), and maps them to a unified intermediate representation parameter set. The torque (tor) is obtained using the following normalization formula: tor=(Raw_tor−Off) / Sca Wherein, Raw_tor is the torque count value read from the original protocol frame, Off is the zero-bias calibration amount corresponding to the protocol, and Sca is the torque dimension scaling factor; after the angle ang and the state sta are converted into parameters according to the same mapping rule, they form an intermediate representation parameter set with the torque tor and are output to the data conversion layer.

[0017] In the specific implementation process, the Protocol Frame Identification Unit (PRI) first receives the raw data frame from the communication bus and scans the preamble header field of the data frame byte by byte. At a preset offset position (e.g., from the 2nd to the 3rd byte), it reads the Protocol Identifier (PID) field (protocol code PID, 2 bytes in length). This field is used to distinguish the communication protocol type to which the data frame belongs (e.g., EtherCAT, CANopen, VDA5050, etc.). The read protocol code PID is compared with a locally stored protocol feature matching table. The matching rules include byte values, check bits, frame structure features, etc. If a match is successful, the protocol type of the data frame can be determined, and the protocol identification result is output to the Data Parsing Unit (PDU).

[0018] After receiving the protocol identification result, the data parsing unit (PDU) automatically loads the corresponding protocol's field decomposition rule table, including parameters such as the starting address (Addr_start) and field length (Len) for each field. Based on these parsing rules, key control fields in the original data frame are decoded and extracted. Specific field processing is as follows: Torque field: The raw count value Raw_tor read from the raw frame and processed using a uniform normalization formula.

[0019] The angle field (ang) and the status field (sta) are read according to their respective offset positions and lengths in the frame structure, and the original count values ​​are converted into standard angle values ​​and binary status bytes through linear normalization using the same mapping mechanism as tor.

[0020] The three parameters tor, ang, and sta mentioned above together form a unified intermediate representation parameter set MID_param, which is used as an encapsulation of structured data objects.

[0021] The data conversion layer encapsulates a unified data frame UDF, and adopts the following structure and process: The system receives an intermediate representation parameter set from the data parsing unit (PDU) of the protocol adaptation layer, including torque (tor), angle (ang), and speed (vel). Based on a preset field mapping structure, it performs a format conversion and encapsulates the above parameters into a JSON format data body. The UDF data frame structure consists of three parts: a frame header field (HDR), formatted as follows: protocol identifier (PID), timestamp (TS), and device address.

[0022] After generating a unified data frame UDF, the data conversion layer performs cyclic redundancy check (CRC) processing on the frame header field and the data body field. The CRC check employs a 16-bit CRC parameter and includes: The frame header field and the data body field are concatenated in byte order to form a data stream to be verified. Then, XOR and shift operations are performed byte by byte on the data stream to be verified using a preset initial verification value. The verification operation is based on generator polynomial iterative calculation to obtain a 16-bit verification field. The verification field is appended to the end of the unified data frame UDF; the same verification operation is performed on the unified data frame UDF, and the calculation result is compared with the verification field for consistency. If the comparison result is inconsistent, the data frame is determined to be transmitted incorrectly and a retransmission is triggered.

[0023] In this embodiment, the CRC16 verification process is executed by the data conversion layer in an integrated manner after the unified data frame UDF is generated. The overall process is as follows: First, the frame header field HDR and the data body field DAT in the unified data frame UDF are concatenated according to a predetermined byte order to form the data stream to be verified, Str(Stream). Then, the data stream Str is checked byte by byte using a preset initial check value Ini(Initial, 0xFFFF). During the verification process, each byte is XORed with the current check register, and the data stream is checked bit by bit based on the preset generator polynomial Pol(Polynomial, 0x1021). The shift and conditional XOR iterative calculation is performed until all bytes are traversed, thus obtaining the 16-bit Cyclic Redundancy Check (CRC) result in Chinese check value (Crc). This CRC value is then appended as a check field to the end of the Unified Data Frame (UDF) to form a complete transmission frame. At the data receiving end, the received UDF is re-executed with the same initial value Ini and polynomial Pol. The calculated check result is compared with the CRC value appended to the end of the frame. If they do not match, a transmission error is determined in the current data frame, triggering retransmission or discarding. This integrated CRC16 check process effectively ensures the integrity and reliability of data frames during multi-protocol collaborative communication.

[0024] The resource allocation unit RDA in the scheduling control layer includes a task load monitoring module LMT and a bandwidth allocation calculation module BDC. The task load monitoring module LMT is used to statistically analyze the cumulative data packet sizes B1, B2, and B3 of the three types of communication tasks in real time during each scheduling cycle. Combined with the current system communication cycle Tcur and the maximum link bandwidth Bmax, it calculates the instantaneous bandwidth occupancy rate Rload. Wherein, B1 represents the cumulative number of effective data packet bytes occupied by the priority 1 emergency control instruction task in the current scheduling period, B2 represents the cumulative number of effective data packet bytes occupied by the priority 2 periodic status data task in the current scheduling period, and B3 represents the cumulative number of effective data packet bytes occupied by the priority 3 non-real-time log task in the current scheduling period. B1, B2, and B3 are all obtained by the task load monitoring module LMT by counting the bytes of the data frames that have been sent. Bmax represents the maximum available bandwidth value allowed at the protocol layer for the current communication link.

[0025] In this embodiment, the Task Load Monitoring (LMT) module is deployed within the scheduling control layer to perform real-time statistics on the load of communication tasks within each scheduling cycle. This module identifies the task type and counts the bytes of all completed data frames in the system. Based on the task type field in the data frame, it classifies the communication tasks in the current cycle into three categories: Priority 1 emergency control command tasks, Priority 2 periodic status feedback tasks, and Priority 3 non-real-time log recording tasks. It then calculates the cumulative data packet size for each category, obtaining the corresponding byte amounts B1, B2, and B3. These statistics are performed by traversing each frame of data frames in the communication buffer that are in the "completed transmission" state, extracting fields, and accumulating bytes, ensuring the real-time nature and accuracy of the statistical data. Subsequently, the LMT calculates the instantaneous bandwidth occupancy rate Rload for the current cycle by combining the current scheduling cycle duration Tcur and the maximum available bandwidth Bmax of the link.

[0026] The bandwidth allocation calculation module BDC determines the current load level based on the instantaneous bandwidth occupancy rate Rload. When Rload ≥ 0.8, it triggers a bandwidth reallocation strategy: freezes the scheduling of priority 3 tasks, limits the bandwidth of priority 2 tasks to 20%, and allocates all remaining bandwidth resources to priority 1 tasks. The bandwidth allocation calculation module (BDC) adopts a time-slice-based round-robin scheduling mechanism, which allocates scheduling time windows to tasks of different priorities proportionally under normal bandwidth conditions.

[0027] In the secure encapsulation layer, the unified data frame UDF is encrypted: Extract the frame header information from the unified data frame UDF and generate the corresponding initialization vector IV. The IV is 16 bytes long and is calculated using the following rules: Among them, the protocol identifier IDproto, timestamp TS and device address ADDR are all derived from the UDF frame header field, and the first 16 bytes are extracted after MD5 digest as the encryption vector; Encryption uses AES-CBC mode and is based on a 128-bit symmetric key. After encryption, the ciphertext frame and the corresponding IV field are encapsulated together into an encrypted data packet EDP.

[0028] This invention introduces a dynamic bandwidth allocation mechanism based on task priority and a secure encapsulation process. It performs differentiated resource scheduling for different types of communication tasks based on monitoring communication load, and prioritizes the transmission reliability of emergency control commands under high load conditions. Combined with CRC check, AES encryption and identity authentication mechanisms, it achieves multiple guarantees for data integrity, confidentiality and access legitimacy. It can effectively avoid the risks of communication congestion, data tampering and unauthorized access, and improve the operational safety and real-time control reliability of robot joint modules in complex industrial application scenarios.

[0029] The secure encapsulation layer processing flow includes: Perform CRC16 verification on the header and body fields of the Unified Data Frame (UDF) to generate an integrity verification result (CLR). When the verification result meets the preset consistency conditions, trigger the encryption process. The initialization vector generation subunit performs concatenation calculations based on the protocol identifier ID, timestamp TS, and device address ADR in the frame header to generate an initialization vector IV with a length of 16 bytes, and writes the initialization vector IV into the encryption context; The 128-bit session key is invoked, and the data body field of the UDF is encrypted block by block using AES-CBC encryption mode, which divides the data body field of the UDF into 128-bit blocks to generate the corresponding encrypted data block sequence. The encrypted data block sequence, initialization vector IV, and check field are re-encapsulated to form an encrypted data frame EDF; Based on the device's unique identifier (UID) and access token (Tok), a validity check is performed. If the authentication result is successful, the encrypted data frame (EDF) is allowed to enter the communication sending queue; otherwise, the data is discarded.

[0030] In this embodiment, the integrity and security assurance process of the unified data frame (UDF) by the secure encapsulation layer includes the following steps: First, the verification processing unit performs CRC16 integrity verification on the frame header field and data body field in the UDF. This process concatenates the two fields in byte order to form a data stream to be verified, and combines it with a preset CRC initial value and a generator polynomial, performing cyclic redundancy check through XOR and shift operations to generate a 16-bit verification result CLR. When the CLR matches the verification field attached to the end of the UDF, it is determined that the data frame has not been corrupted during transmission, thereby triggering the subsequent encryption process.

[0031] The initialization vector generation subunit extracts the protocol identifier (ID), timestamp (TS), and device address (ADR) fields from the frame header, concatenates them into a string in a set order, and passes it into the MD5 digest function to generate a 128-bit digest value. The first 16 bytes are extracted from the digest to form the initialization vector (IV), which is then written into the AES encryption context for initial state configuration.

[0032] The pre-set 128-bit session key is invoked, and the data body fields in the UDF are encrypted using AES-CBC symmetric encryption mode. This encryption process is performed block-by-block encryption in 128-bit (16-byte) units to ensure the randomness and replay resistance of the ciphertext. After encryption, the generated encrypted data block sequence, the aforementioned initialization vector IV, and the integrity check field CLR are encapsulated together into an encrypted data frame EDF.

[0033] The device authentication process is performed based on the device's unique identifier (UID) and access token (Tok). This authentication process calls the OAuth2.0 protocol stack module to verify the binding relationship between the UID and Tok, validate the token's validity, and match permissions. If the authentication result is valid, the encrypted data frame (EDF) is written to the communication sending queue; if the verification fails, the data frame discarding mechanism is triggered.

[0034] Beneficial effects: This invention constructs a multi-protocol collaborative communication architecture in the robot joint module, which includes a protocol adaptation layer, a data conversion layer, a scheduling and control layer, and a security encapsulation layer. This enables the identification, parsing, and unified encapsulation of heterogeneous communication protocol data, allowing joint control commands and status data to be transmitted efficiently within the same communication framework. Through protocol frame identification and field normalization mapping mechanisms, the complexity of data parsing in multi-protocol scenarios is reduced, improving the communication compatibility and system integration efficiency of the robot joint module in a multi-bus environment, and enhancing the stability of the entire system.

[0035] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired or wireless network. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0036] Some of the data in the above formulas are numerical calculations with dimensions removed, and the contents not described in detail in this specification are all prior art known to those skilled in the art.

[0037] The above embodiments are only used to illustrate the technical methods of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical methods of the present invention without departing from the spirit and scope of the technical methods of the present invention.

Claims

1. A multi-protocol cooperative communication architecture for a robot joint module, characterized in that, include: Protocol adaptation layer, data conversion layer, scheduling control layer, and security encapsulation layer; The protocol adaptation layer includes a protocol frame identification unit (PRI) and a data parsing unit (PDU), which are used to receive heterogeneous data frames input from an external communication bus and output them to the data conversion layer. The data conversion layer converts the heterogeneous data frames into a unified data format according to the corresponding rules of the Protocol Mapping Table (PMT), and outputs the unified data frame UDF to the scheduling control layer. The scheduling control layer includes a priority judgment unit (PJU) and a resource allocation unit (RDA). It performs priority judgment based on the task type field of the unified data frame UDF and dynamically allocates communication resources in combination with the bandwidth occupancy status. The security encapsulation layer is used to perform 128-bit key encryption on the unified data frame UDF, and to perform access token verification and device identity and permission confirmation.

2. The multi-protocol cooperative communication architecture for a robot joint module according to claim 1, characterized in that, In the protocol adaptation layer, the Protocol Frame Identification Unit (PRI) and the Data Parsing Unit (PDU) work together: The protocol frame identification unit PRI performs a frame header parsing operation on the input data frame, extracts the protocol identifier field PID from the preset frame header offset position, and matches the protocol identifier field PID with the local protocol feature table to determine the protocol type corresponding to the current data frame. The protocol identifier field PID is a protocol code with a length of 2 bytes. The data parsing unit (PDU) decomposes the original data frame according to the matched protocol specifications, based on the field start address and field length parameters. It extracts the joint torque command parameter (tor), the joint angle parameter (ang), and the status byte parameter (sta), and maps them to a unified intermediate representation parameter set. The torque (tor) is obtained using the following normalization formula: tor=(Raw_tor−Off) / Sca Where Raw_tor is the torque count value read from the original protocol frame, Off is the zero-bias calibration amount corresponding to the protocol, and Sca is the torque dimension scaling factor; After the angle ang and the state sta are converted into parameters according to the same mapping rule, they are combined with the torque tor to form an intermediate representation parameter set and output to the data conversion layer.

3. The multi-protocol cooperative communication architecture for a robot joint module according to claim 1, characterized in that, The data conversion layer encapsulates a unified data frame UDF, and adopts the following structure and process: Receive the intermediate representation parameter set output from the data parsing unit PDU of the protocol adaptation layer, including torque tor, angle ang and speed vel, perform format conversion based on the preset field mapping structure, and encapsulate the above parameters into a JSON format data body; The UDF data frame structure consists of three parts: the frame header field HDR, the format of which is: protocol identifier PID, timestamp TS, and device address.

4. The multi-protocol cooperative communication architecture for a robot joint module according to claim 1, characterized in that, After generating a unified data frame UDF, the data conversion layer performs cyclic redundancy check (CRC) processing on the frame header field and the data body field. The CRC check employs a 16-bit CRC parameter and includes: The frame header field and the data body field are concatenated in byte order to form a data stream to be verified. Then, XOR and shift operations are performed byte by byte on the data stream to be verified using a preset initial verification value. The verification operation is based on generator polynomial iterative calculation to obtain a 16-bit verification field. The verification field is appended to the end of the unified data frame UDF; the same verification operation is performed on the unified data frame UDF, and the calculation result is compared with the verification field for consistency. If the comparison result is inconsistent, the data frame is determined to be transmitted incorrectly and a retransmission is triggered.

5. The multi-protocol cooperative communication architecture for a robot joint module according to claim 1, characterized in that, The resource allocation unit RDA in the scheduling control layer includes a task load monitoring module LMT and a bandwidth allocation calculation module BDC. The task load monitoring module LMT is used to count the cumulative data packet size B of three types of communication tasks in real time in each scheduling period 1 、B 2 With B 3 , combined with the current system communication period Tcur and the maximum link bandwidth Bmax, the instantaneous bandwidth occupancy rate Rload is calculated: Wherein, the B 1 represents the accumulated effective data packet byte amount occupied by the priority 1 emergency control instruction task in the current scheduling period, and the B 2 represents the accumulated effective data packet byte amount occupied by the priority 2 periodic state data task in the current scheduling period, and the B 3 represents the accumulated effective data packet byte amount occupied by the priority 3 non-real-time log task in the current scheduling period, wherein B 1 , B 2 , and B 3 are obtained by the task load monitoring module LMT through byte counting on the data frames that have been sent. Bmax represents the maximum available bandwidth value allowed at the protocol layer for the current communication link.

6. The multi-protocol cooperative communication architecture for a robot joint module according to claim 1, characterized in that, The bandwidth allocation calculation module BDC determines the current load level based on the instantaneous bandwidth occupancy rate Rload. When Rload ≥ 0.8, it triggers a bandwidth reallocation strategy: freezes the scheduling of priority 3 tasks, limits the bandwidth of priority 2 tasks to 20%, and allocates all remaining bandwidth resources to priority 1 tasks. The bandwidth allocation calculation module (BDC) adopts a time-slice-based round-robin scheduling mechanism, which allocates scheduling time windows to tasks of different priorities proportionally under normal bandwidth conditions.

7. The multi-protocol cooperative communication architecture for a robot joint module according to claim 1, characterized in that, In the secure encapsulation layer, the unified data frame UDF is encrypted: Extract the frame header information from the unified data frame UDF and generate the corresponding initialization vector IV. The IV is 16 bytes long and is calculated using the following rules: Among them, the protocol identifier IDproto, timestamp TS and device address ADDR are all derived from the UDF frame header field, and the first 16 bytes are extracted after MD5 digest as the encryption vector; Encryption uses AES-CBC mode and is based on a 128-bit symmetric key. After encryption, the ciphertext frame and the corresponding IV field are encapsulated together into an encrypted data packet EDP.

8. The multi-protocol cooperative communication architecture for a robot joint module according to claim 1, characterized in that, The secure encapsulation layer processing flow includes: Perform CRC16 verification on the header and body fields of the Unified Data Frame (UDF) to generate an integrity verification result (CLR). When the verification result meets the preset consistency conditions, trigger the encryption process. The initialization vector generation subunit performs concatenation calculations based on the protocol identifier ID, timestamp TS, and device address ADR in the frame header to generate an initialization vector IV with a length of 16 bytes, and writes the initialization vector IV into the encryption context; The 128-bit session key is invoked, and the data body field of the UDF is encrypted block by block using AES-CBC encryption mode, which divides the data body field of the UDF into 128-bit blocks to generate the corresponding encrypted data block sequence. The encrypted data block sequence, initialization vector IV, and check field are re-encapsulated to form an encrypted data frame EDF; Based on the device's unique identifier (UID) and access token (Tok), a validity check is performed. If the authentication result is successful, the encrypted data frame (EDF) is allowed to enter the communication sending queue; otherwise, the data is discarded.

Images