Communication method, system and device for secure real-time bus, and storage medium

Abstract

The invention discloses a communication method, system and device for a secure real-time bus and a storage medium, the method is applied to a communication system adopting the secure real-time bus SRB for communication, the communication system comprises a server and a terminal device, and the server comprises a sending end and a receiving end; the communication method comprises the following steps: a sending end obtains target data and encapsulates the target data into a user datagram protocol UDP message; the sending end sends a UDP message to the receiving end through a plurality of sending threads; the receiving end receives the UDP message through a plurality of receiving threads; and the receiving end processes the UDP message to obtain a service processing result, and sends the service processing result to the terminal equipment. Therefore, the equipment resource utilization rate of the communication system can be improved, and the operation efficiency of the system is improved.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a communication method, system, device and storage medium for a secure real-time bus. Background Technology

[0002] In fields such as the Industrial Internet of Things (IIoT), autonomous driving, and smart manufacturing, the communication architecture between devices is one of the foundations for achieving intelligent control. Currently, data transmission between servers and terminal devices can be achieved using protocols such as Transmission Control Protocol (TCP) or User Datagram Protocol (UDP).

[0003] Taking the UDP-based communication architecture as an example, this architecture currently generally uses a single-threaded model to achieve communication. However, devices have entered the multi-core era, so they cannot fully utilize multi-core processor resources, resulting in low resource utilization and obvious performance bottlenecks. Summary of the Invention

[0004] This application provides a communication method, system, device, and storage medium for a secure real-time bus to improve the utilization rate of device resources in the communication system and thereby enhance the system's operating performance.

[0005] In a first aspect, embodiments of this application provide a communication method for a Security Real-time Bus (SRB), applied to a communication system that uses a SRB for communication. The communication system includes a server and terminal devices, the server including a transmitter and a receiver. The communication method includes:

[0006] The sending end acquires the target data and encapsulates the target data into a User Datagram Protocol (UDP) message.

[0007] The sending end sends the UDP packet to the receiving end through multiple sending threads;

[0008] The receiving end receives the UDP packets through multiple receiving threads;

[0009] The receiving end processes the UDP packet to obtain the service processing result, and then sends the service processing result to the terminal device.

[0010] Optionally, the communication system further includes a sending thread pool and a receiving thread pool, wherein the sending thread pool includes multiple sending threads and the receiving thread pool includes multiple receiving threads;

[0011] The number of sending ends is multiple, and each of the multiple sending ends is bound to at least one of the multiple sending threads, and each sending end is bound to a different sending thread;

[0012] The number of receiving ends is multiple, and each of the multiple receiving ends is bound to at least one of the multiple receiving threads, and each receiving end is bound to a different receiving thread.

[0013] Optionally, before the receiving end processes the UDP packet to obtain the service processing result, the method further includes:

[0014] The receiving end sends a heartbeat request message to the terminal device based on the first heartbeat interval;

[0015] In response to the heartbeat request message, the terminal device sends a heartbeat response message to the receiving end;

[0016] The receiving end adjusts the first heartbeat interval based on the heartbeat request message and the heartbeat response message to obtain a second heartbeat interval. The second heartbeat interval is used by the receiving end to send a new heartbeat request message to the terminal device based on the second heartbeat interval.

[0017] Optionally, the receiving end adjusts the first heartbeat interval based on the heartbeat request message and the heartbeat response message to obtain a second heartbeat interval, including:

[0018] The receiving end determines the response time standard deviation based on the heartbeat request message and the heartbeat response message. The response time standard deviation is used to indicate the difference between the timestamp of the receiving end sending the heartbeat request message and the timestamp of receiving the heartbeat response message.

[0019] The receiving end adjusts the first heartbeat interval based on the response time standard deviation to obtain the second heartbeat interval.

[0020] Optionally, the receiving end adjusts the first heartbeat interval based on the response time standard deviation to obtain a second heartbeat interval, including:

[0021] If the standard deviation of the response time is greater than or equal to a preset difference, the receiving end increases the first heartbeat interval to obtain the second heartbeat interval;

[0022] If the standard deviation of the response time is less than a preset difference, the receiving end reduces the first heartbeat interval to obtain the second heartbeat interval.

[0023] Optionally, the sending end acquires the target data, including:

[0024] The sending end encrypts the original data based on the AES-256 algorithm to obtain the target data;

[0025] The receiving end processes the UDP packet to obtain the service processing result, including:

[0026] The receiving end decrypts the UDP packet based on the AES-256 algorithm to obtain decrypted data;

[0027] The receiving end processes the decrypted data to obtain the business processing result.

[0028] Optionally, after the sending end encrypts the original data based on the AES-256 algorithm to obtain the target data, the method further includes:

[0029] The sending end processes the target data based on the Hash Message Authentication Code (HMAC) algorithm to obtain the first HMAC;

[0030] The sending end sends the first HMAC to the receiving end;

[0031] The receiving end processes the decrypted data to obtain the service processing result, including:

[0032] The receiving end verifies the decrypted data using the HMAC algorithm to obtain a verification result. The verification includes processing the decrypted data based on the HMAC algorithm to generate a second HMAC.

[0033] If the verification result indicates that the second HMAC and the first HMAC are consistent, the receiving end processes the decrypted data to obtain the service processing result.

[0034] Secondly, embodiments of this application provide a communication system for a secure real-time bus, including: a server and a terminal device, wherein the server includes a transmitting end and a receiving end, and the communication system uses SRB for communication;

[0035] The sending end is used to acquire target data and encapsulate the target data into a User Datagram Protocol (UDP) packet; and to send the UDP packet to the receiving end through multiple sending threads.

[0036] The receiving end is configured to receive the UDP packets through multiple receiving threads; and the receiving end processes the UDP packets to obtain a service processing result, and sends the service processing result to the terminal device.

[0037] Thirdly, embodiments of this application provide an electronic device, the device including: a processor, a memory, and a system bus;

[0038] The processor and the memory are connected via the system bus;

[0039] The memory is used to store a program, the program including instructions that, when executed by the processor, cause the processor to perform any of the implementation steps performed by the server or any of the implementation steps performed by the terminal device in the communication method for the secure real-time bus described above.

[0040] Fourthly, embodiments of this application provide a computer-readable storage medium storing instructions that, when executed on an electronic device, cause the electronic device to perform any of the implementation steps of the communication method for a secure real-time bus described above.

[0041] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0042] In this embodiment, the communication system using SRB includes a server and a terminal device, wherein the server includes a sender and a receiver. Accordingly, the communication method includes: the sender encapsulating the acquired target data into a UDP packet and sending the UDP packet to the receiver through multiple sending threads. Then, the receiver receives the UDP packet through multiple receiving threads, processes the UDP packet to obtain a service processing result, and finally sends the service processing result to the terminal device. It is evident that through multi-threaded parallel processing technology, the sender can send UDP packets in parallel through multiple sending threads, and the receiver can also receive UDP packets through multiple receiving threads. This fully utilizes the computing resources of multi-core processors, helping to improve the resource utilization of devices in the communication system, thereby improving the overall operating efficiency of the system. Furthermore, by encapsulating the target data into a UDP packet, the connectionless nature of UDP can be utilized, meaning the sender can send the UDP packet to the receiver without establishing a connection and without considering whether the receiver is ready to receive the UDP packet, thus improving the transmission efficiency of the target data. Furthermore, this communication system, which utilizes SRB for communication, can more precisely control the resources corresponding to each thread, significantly improving the overall system's operating efficiency and stability. Attached Figure Description

[0043] Figure 1 A flowchart illustrating a communication method for a secure real-time bus provided in an embodiment of this application;

[0044] Figure 2 A schematic diagram of a communication system for a secure real-time bus provided in an embodiment of this application;

[0045] Figure 3 This is a schematic diagram of the structure of a communication system for a secure real-time bus, provided as an embodiment of this application. Detailed Implementation

[0046] As mentioned earlier, in fields such as industrial IoT, autonomous driving, and smart manufacturing, the communication architecture between devices typically uses TCP or UDP to achieve data transmission. However, as devices enter the multi-core era, the UDP communication architecture based on a single thread can no longer meet the requirements for fast communication between devices, resulting in low device resource utilization and significant performance bottlenecks.

[0047] Specifically, modern servers and terminal devices typically employ multi-core processing architectures to enhance parallel communication capabilities. However, current single-threaded UDP communication architectures operate on a single CPU, while other CPUs may be idle. This results in underutilization of multi-core resources, leading to low overall resource utilization and consequently impacting the throughput and response speed of the communication system.

[0048] Alternatively, when the server and terminal devices communicate using the TCP protocol, a three-way handshake is required to establish a connection and verify that both parties have the ability to send and receive data. However, during the three-way handshake, data packets can be transmitted back and forth between the server and terminal devices, and each transmission requires a certain amount of time, the length of which depends on network latency. Therefore, the higher the network latency, the greater the delay in establishing a communication connection between the server and terminal devices. Furthermore, if data packets are lost due to network latency during the three-way handshake, the TCP retransmission mechanism will be triggered. In this case, the lost data packets need to be retransmitted. In network environments with high packet loss rates, the TCP retransmission mechanism will increase the transmission time of data packets, further exacerbating the communication latency between the server and terminal devices.

[0049] To address the aforementioned issues, this application provides a communication method for a Secure Real-Time Bus (SRB), applicable to a communication system using SRB. The communication system includes a server and terminal devices, wherein the server comprises a sender and a receiver. Accordingly, the communication method includes: the sender encapsulating acquired target data into a UDP packet and sending the UDP packet to the receiver through multiple sending threads. Then, the receiver receives the UDP packet through multiple receiving threads, processes the UDP packet to obtain a service processing result, and finally sends the service processing result to the terminal device.

[0050] SRB, or Industrial Data Bus, is an industrial data fieldbus built on high-performance semiconductor device technology. It features stable, secure, and real-time data transmission, making it adaptable to harsh industrial environments. Therefore, SRB is a core infrastructure for efficient communication between devices in fields such as the Industrial Internet of Things (IIoT), autonomous driving, and smart manufacturing.

[0051] As can be seen, by employing multi-threaded parallel processing technology, the sending end can send UDP packets in parallel using multiple sending threads, and the receiving end can receive UDP packets using multiple receiving threads. This fully utilizes the computing resources of multi-core processors, helping to improve the resource utilization of devices in the communication system and thus enhancing the overall system performance. Furthermore, by encapsulating the target data into UDP packets, the connectionless nature of UDP can be leveraged—the sending end can send UDP packets to the receiving end without establishing a connection or considering whether the receiving end is ready to receive them—thus improving the transmission efficiency of the target data. Moreover, this communication system, utilizing SRB for communication, allows for more precise control of the resources corresponding to each thread, significantly improving the overall system's operational efficiency and stability.

[0052] It should be noted that the embodiments of this application are not limited to the executing entity of the communication method for the secure real-time bus. For example, the server in the communication method for the secure real-time bus in the embodiments of this application can be a standalone server, a cluster server, or a cloud server, and the terminal device can be an electronic device such as a smartphone, computer, personal digital assistant (PDA), or tablet computer.

[0053] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0054] Figure 1 This is a flowchart illustrating a communication method for a secure real-time bus provided in this embodiment. (In conjunction with...) Figure 1 As shown in the embodiments of this application, the communication method for a secure real-time bus is described with a corresponding communication system as the execution subject. The communication system uses an SRB for communication and may specifically include a server and terminal devices. The server includes a sender and a receiver. Accordingly, the communication method may include the following steps S101-S104.

[0055] S101: The sending end obtains the target data and encapsulates the target data into a UDP packet.

[0056] In this embodiment of the application, considering that traditional bus transmission usually uses plaintext for data exchange, which is susceptible to security risks such as eavesdropping or data tampering during data transmission, the sending end can encrypt the data before sending it to improve the security of the data during transmission.

[0057] Specifically, target data refers to the data that the communication system intends to transmit. Regarding the acquisition of target data, in practice, the sending end can encrypt the original data using the AES-256 algorithm (an advanced encryption standard using a 256-bit key length) to obtain the target data.

[0058] For example, in the encryption process, ciphertext (i.e., target data) = AES-256(kencrypt, plaintext||Nonce), where kencrypt represents a 256-bit encryption key, plaintext represents the original data to be encrypted, Nonce is a randomly generated number, and || represents concatenating the plaintext and Nonce. In this embodiment, the target data is obtained by encrypting the original data using the AES-256 algorithm, thus improving the confidentiality and security of the original data.

[0059] After obtaining the target data, the sending end can process the target data using the HMAC algorithm to generate the first HMAC. For example, the first HMAC = SHA256(ksign, ciphertext||sequence number), where SHA256 represents the HMAC algorithm implemented using a hash function, ksign represents the key for calculating the HMAC, ciphertext refers to the encrypted data, and || represents concatenating the ciphertext and the sequence number, where the sequence number is a randomly generated number.

[0060] In this embodiment of the application, the encrypted target data is processed using the HMAC algorithm to generate a first HMAC. Since the HMAC algorithm is an encryption algorithm used for data integrity verification and message authentication, the sending end can send the first HMAC to the receiving end when sending the target data, and use the HMAC algorithm and the first HMAC to verify the integrity and consistency of the target data.

[0061] Furthermore, regarding the process of encapsulating target data into UDP packets, in specific implementations, the sending end can convert the acquired target data into UDP format and store it in the packet queue corresponding to the UDP packet. Here, the implementation method for converting target data into UDP format in this application embodiment is not limited, and any existing or future method for encapsulating UDP packets can be used.

[0062] S102: The sending end sends UDP packets to the receiving end through multiple sending threads.

[0063] In this embodiment, the communication system may further include a sending thread pool, which may include multiple sending threads. In this way, when there are multiple sending ends, each sending end can be bound to at least one of the multiple sending threads, and each sending end is bound to a different sending thread. Thus, each sending end can be bound to at least one independent sending thread, allowing multiple sending ends to send UDP packets in parallel using multiple sending threads, thereby improving data transmission efficiency.

[0064] For example, if the sending end needs to send multiple sets of data, multiple sending threads can be associated with these sets of data one-to-one, meaning each sending thread can send a corresponding set of data. Similarly, if the sending end needs to send a large amount of data at once, it can first divide the data into multiple sub-data segments, and multiple sending threads can be associated with these sub-data segments one-to-one, meaning each sending thread can send a corresponding sub-data segment to the receiving end.

[0065] In this way, the sending thread pool can reasonably distribute the target data to be sent to multiple sending threads for parallel processing, thereby improving the efficiency of data transmission at the sending end.

[0066] Furthermore, in practical applications, the communication system may also include a network layer, which is implemented by routers and / or switches. Accordingly, when the sending end sends a UDP packet to the receiving end, it can first send the UDP packet to the network layer through multiple sending threads, and then forward it through routers and / or switches in the network layer to the receiving end.

[0067] In addition, as mentioned earlier, the sender can generate the first HMAC to verify the integrity and consistency of the target data. Therefore, when the sender sends UDP packets to the receiver through multiple sending threads working in parallel, it can also send the first HMAC to the receiver.

[0068] S103: The receiving end receives UDP packets through multiple receiving threads.

[0069] In this embodiment, the communication system may further include a receiving thread pool, which may include multiple receiving threads. In this way, when there are multiple receivers, each receiver can be bound to at least one of the multiple receiving threads, and each receiver can be bound to a different receiving thread. Thus, each receiver can be bound to at least one independent sending thread, allowing multiple receivers to receive UDP packets in parallel using multiple receiving threads, thereby improving data reception efficiency.

[0070] For example, if the receiving end needs to receive multiple sets of data, multiple receiving threads can be associated with multiple sets of data one by one, that is, each receiving thread can receive the corresponding set of data.

[0071] In practical applications, multiple receiving threads can also perform preemptive scheduling for UDP packets. That is, when there are multiple idle receiving threads, the receiving thread with the highest transmission efficiency among the multiple idle receiving threads can directly receive the UDP packet, thereby preempting the scheduling of the UDP packet and improving the efficiency and responsiveness of the communication system.

[0072] S104: The receiving end processes the UDP packet, obtains the service processing result, and sends the service processing result to the terminal device.

[0073] After multiple threads on the receiving end receive UDP packets, the receiving end performs business processing on the received UDP packets, obtains the business processing results, and feeds back the business processing results to the terminal device, thereby completing the business process between the server and the terminal device.

[0074] In this embodiment of the application, since the target data is encrypted using the AES-256 algorithm, and the sending end directly encapsulates the target data as UDP data, the receiving end can decrypt the received UDP packet after receiving it.

[0075] Specifically, after receiving a UDP packet containing the target data, the receiving end can decrypt the UDP packet using the AES-256 algorithm to obtain the decrypted data. Then, the receiving end uses the HMAC algorithm to verify the integrity and consistency of the decrypted data.

[0076] The receiving end can first generate a second HMAC using the HMAC algorithm, and then compare the generated second HMAC with the received first HMAC. If the second HMAC matches the first HMAC, it means the decrypted data verification is successful, and the receiving end can continue to process the decrypted data to obtain the processing result. If the second HMAC does not match the first HMAC, it means the decrypted data verification is unsuccessful, and the receiving end will report the verification result to the terminal device.

[0077] In practical applications, the connection between the server and terminal devices may become unstable due to network fluctuations, equipment failures, or other factors. Due to the lack of a real-time monitoring mechanism, the server cannot promptly obtain the real-time status of the terminal devices and may continue to send data to disconnected devices, leading to data loss or task failure. Furthermore, the lack of terminal device disconnection detection means the server may take a considerable amount of time to detect a disconnection, and re-establishing the connection after the terminal device reconnects may also take a long time, increasing communication latency between devices.

[0078] Based on the above problems, in this embodiment of the application, the receiving end can dynamically adjust the heartbeat interval through a heartbeat management mechanism before processing UDP packets, so as to flexibly detect the online and connection status of the terminal device. For ease of understanding, the implementation process is described below with reference to a possible implementation method.

[0079] As one possible implementation method, the above-mentioned heartbeat management mechanism can be implemented through the following steps 1-3.

[0080] Step 1: The receiving end sends a heartbeat request message to the terminal device based on the first heartbeat interval.

[0081] In this embodiment, the receiving end can send heartbeat request messages to the terminal device according to the time period corresponding to the first heartbeat interval to detect the online and connection status of the terminal device. The heartbeat request message includes a heartbeat request timestamp, a server identifier, and a sequence number. The heartbeat request timestamp records the time when the receiving end sends the heartbeat request message. The server identifier identifies the server making the current heartbeat request. The sequence number identifies the currently sent heartbeat request message.

[0082] Step 2: The terminal device responds to the heartbeat request message by sending a heartbeat response message to the receiving end.

[0083] Accordingly, after receiving a heartbeat request message from the receiving end, the terminal device sends a heartbeat response message to the receiving end. The heartbeat response message includes a heartbeat response timestamp, a terminal device identifier, and a terminal device status code. The heartbeat response timestamp records the time the terminal device sent the heartbeat response message. The terminal device identifier identifies the terminal device currently responding to the heartbeat, such as the terminal device's ID and / or physical address. The terminal device status code indicates the terminal device's current operating status, such as normal, standby, fault, or reconnection. This response message indicates that the terminal device is online and the connection is normal; the receiving end can confirm the terminal device's online and connection status through the received heartbeat response message.

[0084] It should be noted that the format of the above heartbeat response message can be represented as: | 1-byte type | 4-byte heartbeat response timestamp | 2-byte terminal device ID | 4-byte sequence number | 16-byte terminal device physical address | where the type indicates that the message is a heartbeat message, and the terminal device ID, sequence number and physical address can be found in the above description.

[0085] In addition, the format of the heartbeat request message is similar to that of the heartbeat response message, except that the heartbeat response timestamp is replaced with the heartbeat request timestamp, and the terminal device ID and physical address are replaced with the receiving end ID and physical address. This will not be explained in detail here.

[0086] Step 3: The receiving end adjusts the first heartbeat interval based on the heartbeat request message and the heartbeat response message to obtain the second heartbeat interval. The second heartbeat interval is used by the receiving end to send a new heartbeat request message to the terminal device based on the second heartbeat interval.

[0087] The receiving end determines the response time standard deviation based on heartbeat request messages and heartbeat response messages. Specifically, the receiving end can determine the response time for each heartbeat cycle by sending a heartbeat request message and receiving a heartbeat response message, and then calculate the standard deviation of that response time. The response time standard deviation indicates the difference between the timestamp of the receiving end sending the heartbeat request message and the timestamp of receiving the heartbeat response message. The response time standard deviation reflects the latency fluctuation of the terminal device in responding to heartbeat requests, and helps to assess the connection stability between the terminal device and the receiving end.

[0088] The receiver can dynamically adjust the heartbeat interval based on the standard deviation of the response time. Specifically, if the standard deviation of the response time is greater than or equal to a preset difference, the receiver will increase the first heartbeat interval, thereby reducing the frequency of heartbeat requests. If the standard deviation of the response time is less than the preset difference, the receiver can decrease the first heartbeat interval, thereby increasing the frequency of heartbeat requests. By dynamically adjusting the heartbeat interval, the receiver can optimize the frequency of heartbeat requests based on real-time network conditions, improve communication efficiency, and avoid wasting device resources caused by frequent heartbeat requests.

[0089] Based on the above steps S101-S104, it is clear that in this embodiment, the communication system uses SRB for communication, including a server and a terminal device. The server includes a sender and a receiver. The communication method includes: the sender encapsulating the acquired target data into a UDP packet and sending the UDP packet to the receiver through multiple sending threads. Then, the receiver receives the UDP packet through multiple receiving threads, processes the UDP packet to obtain the service processing result, and finally sends the service processing result to the terminal device. It is evident that through multi-threaded parallel processing technology, the sender can send UDP packets in parallel through multiple sending threads, and the receiver can also receive UDP packets through multiple receiving threads. This fully utilizes the computing resources of multi-core processors, helping to improve the resource utilization of devices in the communication system and thus improving the overall operating efficiency of the system. Furthermore, by encapsulating the target data into a UDP packet, the connectionless nature of UDP can be utilized, meaning the sender can send the UDP packet to the receiver without establishing a connection and without considering whether the receiver is ready to receive the UDP packet, thus improving the transmission efficiency of the target data. Furthermore, this communication system, which utilizes SRB for communication, can more precisely control the resources corresponding to each thread, significantly improving the overall system's operating efficiency and stability.

[0090] Furthermore, based on the communication method for the secure real-time bus mentioned in the above embodiments, this embodiment can also introduce the corresponding communication system in conjunction with the embodiments and accompanying drawings.

[0091] Figure 2 This is a schematic diagram of a communication system for a secure real-time bus, provided as an embodiment of this application. (In conjunction with...) Figure 2 As shown, the communication system includes a sender, a network layer, a receiver, and terminal devices. After the sender obtains the raw data from the data source, it can fragment the data using multiple sending threads to facilitate parallel data transmission. Subsequently, the sender encrypts the data using an encryption engine, such as AES-256 or HMAC algorithms, generating UDP packets and storing them in a UDP packet queue. These UDP packets are then sent to the network layer in parallel by multiple sending threads.

[0092] Accordingly, UDP packets are forwarded via routers or switches to the receiving end. The receiving end receives these UDP packets through multiple receiving threads. Subsequently, based on the algorithm used by the sending end's encryption engine, the received UDP packets are decrypted and verified, and a heartbeat management mechanism is used to confirm the connection status between the receiving end and the terminal device. This heartbeat management mechanism can dynamically adjust the heartbeat interval to flexibly detect the online and connection status of the terminal device. After decryption, the receiving end can process the decrypted data, obtain the processing result, and report the result back to the terminal device. Finally, the terminal device's actuator performs corresponding operations based on the processing result and reports the execution status, thereby realizing data transmission between the server and the terminal device.

[0093] Furthermore, in order to make the technical solution of this application clearer and easier to understand, the communication method for a secure real-time bus provided by the embodiments of this application can be introduced below from the perspective of application scenarios, in conjunction with a variety of possible implementation methods.

[0094] As one possible implementation, in collaborative control scenarios of industrial robots, the latency of commands for synchronous execution of actions by multiple robots generally needs to be controlled within 5 milliseconds. Therefore, multiple robots can be bound to independent threads to achieve parallel transmission of control commands, thereby reducing command latency. By combining a heartbeat management mechanism, AES-256 encryption algorithm, and HMAC algorithm, the security of synchronized robot actions can be improved.

[0095] As another possible implementation, in real-time monitoring scenarios of smart grids, the throughput for collecting status data from thousands of electricity meters typically exceeds 100,000 packets per second. Therefore, the electricity meters can be divided into regions, and each region can be bound to an independent transmission thread. This allows for parallel data transmission through multiple threads, improving data throughput. This approach enables parallel collection and transmission of status data from electricity meters within each region. Furthermore, a heartbeat management mechanism can be incorporated to reduce network latency during data transmission, further enhancing the efficiency of real-time grid monitoring.

[0096] As one possible implementation, in the communication scenarios of autonomous driving fleets, the packet loss rate is generally less than 0.1% to meet the need for real-time sharing of vehicle location information. Therefore, the sending end can repeatedly send the same vehicle location information to the receiving end at certain time intervals to ensure that the receiving end can still receive the vehicle location information in a timely manner even in the event of network fluctuations or data packet loss. Furthermore, the ACE-256 algorithm and the HMAC algorithm can be combined to improve the integrity and security of data transmission.

[0097] As one possible implementation, in drone formation performance scenarios, the disconnection recovery time generally needs to be less than 100 milliseconds to meet the requirement of synchronized actions by multiple drones. Therefore, a heartbeat management mechanism can be used to monitor the online status of drones in real time and trigger disconnection reconnection in real time, reducing disconnection recovery time. Simultaneously, the number of sending and receiving threads can be adjusted according to the size of the drone formation, thereby improving the coordination and efficiency of drone formation performances.

[0098] Furthermore, based on the communication method for a secure real-time bus provided in the above embodiments, this application embodiment can also provide a communication system for a secure real-time bus. The communication system will now be described in conjunction with the embodiments and accompanying drawings.

[0099] Figure 3 This is a schematic diagram of a communication system for a secure real-time bus, provided as an embodiment of this application. (In conjunction with...) Figure 3 As shown in the embodiment of this application, a communication system for a secure real-time bus includes: a server and a terminal device. The server includes a transmitter and a receiver. The communication system uses SRB for communication.

[0100] The sending end is used to acquire target data and encapsulate the target data into a User Datagram Protocol (UDP) message; and to send the UDP message to the receiving end through multiple sending threads.

[0101] The receiving end is configured to receive the UDP packets through multiple receiving threads; and the receiving end processes the UDP packets to obtain a service processing result, and sends the service processing result to the terminal device.

[0102] Optionally, the receiving end is further configured to:

[0103] A heartbeat request message is sent to the terminal device based on the first heartbeat interval;

[0104] The terminal device is specifically used for:

[0105] In response to the heartbeat request message, a heartbeat response message is sent to the receiving end;

[0106] The receiving end is also used for:

[0107] Based on the heartbeat request message and the heartbeat response message, the first heartbeat interval is adjusted to obtain a second heartbeat interval. The second heartbeat interval is used by the receiving end to send a new heartbeat request message to the terminal device based on the second heartbeat interval.

[0108] Optionally, the receiving end is specifically used for:

[0109] Based on the heartbeat request message and the heartbeat response message, a response time standard deviation is determined. The response time standard deviation is used to indicate the difference between the timestamp of the receiving end sending the heartbeat request message and the timestamp of receiving the heartbeat response message.

[0110] Based on the standard deviation of the response time, the first heartbeat interval is adjusted to obtain the second heartbeat interval.

[0111] Optionally, the receiving end is specifically used for:

[0112] If the standard deviation of the response time is greater than or equal to a preset difference, the first heartbeat interval is increased to obtain the second heartbeat interval;

[0113] If the standard deviation of the response time is less than a preset difference, the first heartbeat interval is reduced to obtain the second heartbeat interval.

[0114] Optionally, the sending end is specifically used for:

[0115] The original data is encrypted using the AES-256 algorithm to obtain the target data.

[0116] The receiving end is specifically used for:

[0117] The UDP packet is decrypted using the AES-256 algorithm to obtain decrypted data;

[0118] The decrypted data is processed to obtain the business processing result.

[0119] Optionally, the sending end is further configured to:

[0120] The target data is processed based on the Hash Message Authentication Code (HMAC) algorithm to obtain the first HMAC;

[0121] Send the first HMAC to the receiving end;

[0122] The receiving end is specifically used for:

[0123] The decrypted data is verified using the HMAC algorithm to obtain a verification result. The verification includes processing the decrypted data based on the HMAC algorithm to generate a second HMAC.

[0124] If the verification result indicates that the second HMAC and the first HMAC are consistent, the decrypted data is processed to obtain the business processing result.

[0125] Furthermore, embodiments of this application also provide an electronic device, including: a processor, a memory, and a system bus;

[0126] The processor and the memory are connected via the system bus;

[0127] The memory is used to store one or more programs, the one or more programs including instructions that, when executed by the processor, cause the processor to perform any of the implementation steps performed by the server or any of the implementation steps performed by the terminal device in the communication method for the secure real-time bus described above.

[0128] Furthermore, embodiments of this application also provide a computer-readable storage medium storing instructions that, when executed on an electronic device, cause the electronic device to perform any of the implementation steps of the communication method for a secure real-time bus described above.

[0129] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that all or part of the steps in the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network communication device such as a media gateway, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application. It should be noted that the various embodiments in this specification are described in a progressive manner, and each embodiment focuses on describing the differences from other embodiments. The same or similar parts between the various embodiments can be referred to mutually.

[0130] The system disclosed in the embodiments is described in a relatively simple manner because it corresponds to the method disclosed in the embodiments. For relevant details, please refer to the method section.

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

[0132] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A communication method for a secure real-time bus, characterized in that, A communication system employing a Secure Real-Time Bus (SRB) for communication, the communication system comprising a server and terminal devices, the server comprising a transmitter and a receiver, the communication method comprising: The sending end acquires the target data and encapsulates the target data into a User Datagram Protocol (UDP) message. The sending end sends the UDP packet to the receiving end through multiple sending threads; The receiving end receives the UDP packets through multiple receiving threads; The receiving end processes the UDP packet to obtain the service processing result, and sends the service processing result to the terminal device.

2. The communication method for a secure real-time bus according to claim 1, characterized in that, The communication system further includes a sending thread pool and a receiving thread pool, wherein the sending thread pool includes multiple sending threads and the receiving thread pool includes multiple receiving threads. The number of sending ends is multiple, and each of the multiple sending ends is bound to at least one of the multiple sending threads, and each sending end is bound to a different sending thread; The number of receiving ends is multiple, and each of the multiple receiving ends is bound to at least one of the multiple receiving threads, and each receiving end is bound to a different receiving thread.

3. The communication method for a secure real-time bus according to claim 1, characterized in that, Before the receiving end processes the UDP packet to obtain the service processing result, the method further includes: The receiving end sends a heartbeat request message to the terminal device based on the first heartbeat interval; In response to the heartbeat request message, the terminal device sends a heartbeat response message to the receiving end; The receiving end adjusts the first heartbeat interval based on the heartbeat request message and the heartbeat response message to obtain a second heartbeat interval; the second heartbeat interval is used by the receiving end to send a new heartbeat request message to the terminal device based on the second heartbeat interval.

4. The communication method for a secure real-time bus according to claim 3, characterized in that, The receiving end adjusts the first heartbeat interval based on the heartbeat request message and the heartbeat response message to obtain a second heartbeat interval, including: The receiving end determines the response time standard deviation based on the heartbeat request message and the heartbeat response message. The response time standard deviation is used to indicate the difference between the timestamp of the receiving end sending the heartbeat request message and the timestamp of receiving the heartbeat response message. The receiving end adjusts the first heartbeat interval based on the response time standard deviation to obtain the second heartbeat interval.

5. The communication method for a secure real-time bus according to claim 4, characterized in that, The receiving end adjusts the first heartbeat interval based on the response time standard deviation to obtain a second heartbeat interval, including: If the standard deviation of the response time is greater than or equal to a preset difference, the receiving end increases the first heartbeat interval to obtain the second heartbeat interval; If the standard deviation of the response time is less than a preset difference, the receiving end reduces the first heartbeat interval to obtain the second heartbeat interval.

6. The communication method for a secure real-time bus according to any one of claims 1 to 5, characterized in that, The sending end acquires the target data, including: The sending end encrypts the original data based on the AES-256 algorithm to obtain the target data; The receiving end processes the UDP packet to obtain the service processing result, including: The receiving end decrypts the UDP packet based on the AES-256 algorithm to obtain decrypted data; The receiving end processes the decrypted data to obtain the business processing result.

7. The communication method for a secure real-time bus according to claim 6, characterized in that, After the sending end encrypts the original data based on the AES-256 algorithm to obtain the target data, the method further includes: The sending end processes the target data based on the Hash Message Authentication Code (HMAC) algorithm to obtain the first HMAC; The sending end sends the first HMAC to the receiving end; The receiving end processes the decrypted data to obtain the service processing result, including: The receiving end verifies the decrypted data using the HMAC algorithm to obtain a verification result. The verification includes processing the decrypted data based on the HMAC algorithm to generate a second HMAC. If the verification result indicates that the second HMAC and the first HMAC are consistent, the receiving end processes the decrypted data to obtain the service processing result.

8. A communication system for a secure real-time bus, characterized in that, include: The server and terminal equipment, wherein the server includes a sending end and a receiving end, and the communication system uses a Secure Real-Time Bus (SRB) for communication; The sending end is used to acquire target data and encapsulate the target data into a User Datagram Protocol (UDP) message; And, the UDP packets are sent to the receiving end through multiple sending threads; The receiving end is used to receive the UDP packets through multiple receiving threads; Furthermore, the receiving end processes the UDP packet to obtain the service processing result, and sends the service processing result to the terminal device.

9. An electronic device, characterized in that, The device includes: a processor, a memory, and a system bus; The processor and the memory are connected via the system bus; The memory is used to store a program, the program including instructions that, when executed by the processor, cause the processor to perform the steps performed by the server in the communication method for a secure real-time bus according to any one of claims 1 to 7, or the steps performed by the terminal device.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program that, when executed by a terminal device, implements the steps performed by the server in the communication method for a secure real-time bus as described in any one of claims 1 to 7, or the steps performed by the terminal device.

Images