Remote driving service system and method of a dual-service system architecture

Abstract

This invention relates to the field of remote driving technology and discloses a remote driving service system and method with a dual-service system architecture. The method includes: deploying a master server in the cloud and a backup server locally in the cabin; establishing a main data path from the vehicle to the cabin via the master server and a backup data path from the vehicle to the cabin via the backup server; transmitting video stream data and control command data to the vehicle and cabin respectively through the main and backup data paths; performing periodic heartbeat detection, latency detection, and packet loss rate detection on the main data path; and switching the markers of the video stream data and control command data received by the backup data path as valid data. This invention achieves synchronous back-switching between the vehicle and cabin based on switching timestamps. This invention requires no manual intervention, avoiding delays and errors caused by human operation, and improving the availability, continuity, and security of the remote driving service system.

Description

Technical Field

[0001] This invention relates to the field of remote driving technology, and in particular to a remote driving service system and method with a dual-service system architecture. Background Technology

[0002] Remote driving technology, as an important supplement to autonomous driving technology, plays a crucial role in scenarios such as mining transportation, port operations, and logistics distribution. Remote driving systems have extremely high requirements for service continuity and real-time performance; service interruptions can directly lead to vehicle loss of control, threatening driving safety. However, existing remote driving systems generally adopt a single cloud server deployment or a homogeneous dual-machine hot standby architecture in the cloud. Both the primary and backup servers are deployed in the same cloud network environment. When the entire cloud network link fails, the redundancy mechanism completely fails, making service takeover impossible.

[0003] Existing technologies only enable static synchronization of basic configuration parameters between primary and backup servers. They lack real-time synchronization links for core business data such as vehicle dispatch status and driver session information. This necessitates re-initializing session connections when the backup node takes over the service, causing service interruptions. Furthermore, the fault detection mechanism is not designed for remote driving scenarios, relying solely on a single heartbeat detection method, which cannot quickly detect momentary server failures or network link anomalies, resulting in high fault determination latency. Summary of the Invention

[0004] This invention provides a remote driving service system and method with a dual-service system architecture. By using a heterogeneous redundancy deployment architecture of a cloud master server and a cabin backup server, this invention eliminates the risk of single point of failure in homogeneous cloud deployment. When the cloud network link fails as a whole, the backup server can still establish a direct connection with the vehicle through the cabin local network, ensuring the effectiveness of the redundancy mechanism in extreme scenarios.

[0005] In a first aspect, the present invention provides a remote driving service method with a dual-service system architecture, the remote driving service method with a dual-service system architecture comprising: A main server is deployed in the cloud and a backup server is deployed locally in the cabin. A main data path from the vehicle to the cabin via the main server and a backup data path from the vehicle to the cabin via the backup server are established. Video stream data and control command data are transmitted in parallel to the vehicle and the cabin through the main data path and the backup data path. Periodic heartbeat detection, delay detection, and packet loss rate detection are performed on the main data path. Based on the detected number of heartbeat timeouts, average delay value, and first packet loss rate, the markings of the video stream data and control command data received by the backup data path are switched to valid data.

[0006] In conjunction with the first aspect, in a first implementation of the first aspect of the present invention, a main server is deployed in the cloud and a backup server is deployed locally in the cabin, establishing a main data path from the vehicle end to the cabin via the main server and a backup data path from the vehicle end to the cabin via the backup server, and transmitting video stream data and control command data to the vehicle end and the cabin end in parallel through the main data path and the backup data path, including: A main server for deploying and running the vehicle scheduling module and video stream forwarding module is deployed and run in the cloud, and a backup server for deploying and running the vehicle scheduling module and video stream forwarding module is deployed and run locally in the cabin, establishing an encrypted communication link between the main server and the backup server; The vehicle dispatch status, driver session information, video stream data, and network topology configuration are periodically synchronized to the backup server through the encrypted communication link. A main data path is established from the vehicle end to the cabin end via the main server, and a backup data path is established from the vehicle end to the cabin end via the backup server. Video stream data and control command data are transmitted in parallel to the vehicle end and the cabin end through the main data path and the backup data path.

[0007] In conjunction with the first aspect, in a second implementation of the first aspect of the present invention, a main data path is established from the vehicle end to the cabin end via the main server and a backup data path is established from the vehicle end to the cabin end via the backup server. Video stream data and control command data are transmitted in parallel to the vehicle end and the cabin end through the main data path and the backup data path, including: The vehicle establishes a primary data path with the main server and receives connection information from the backup server. Based on the backup server connection information, a backup data path is established between the vehicle and the backup server. The video stream data collected by the vehicle end is synchronously transmitted to the main data path and the backup data path. The control command data generated by the cabin end is synchronously transmitted to the vehicle end through the main data path and the backup data path. The video stream data and control command data transmitted by the main data path are marked as valid data.

[0008] In conjunction with the first aspect, in a third implementation of the first aspect of the present invention, periodic heartbeat detection, delay detection, and packet loss rate detection are performed on the main data path. Based on the detected number of heartbeat timeouts, average delay value, and first packet loss rate, the markings of the video stream data and control command data received by the backup data path are switched to valid data, including: Periodic heartbeat detection, delay detection, and packet loss rate detection are performed on the main data path to obtain the number of heartbeat timeouts, the average delay value, and the first packet loss rate; When the number of heartbeat timeouts exceeds a preset threshold and the average latency exceeds a preset latency threshold, or when the number of heartbeat timeouts exceeds a preset threshold and the first packet loss rate exceeds a preset packet loss rate threshold, the markings of the video stream data and control command data transmitted through the backup data path are switched to valid data.

[0009] In conjunction with the first aspect, in a fourth implementation of the first aspect of the present invention, when the number of heartbeat timeouts exceeds a preset threshold and the average latency value exceeds a preset latency threshold, or when the number of heartbeat timeouts exceeds a preset threshold and the first packet loss rate exceeds a preset packet loss rate threshold, the markers of the video stream data and control command data transmitted through the backup data path are switched to valid data, including: The flags of the video stream data and control command data transmitted through the backup data path are switched from standby data to valid data, while the flags of the data transmitted through the main data path are switched from valid data to invalid data. The vehicle receives control command data from the backup data path and extracts control commands to execute vehicle control; the cabin receives video stream data from the backup data path and extracts video frames for display.

[0010] In conjunction with the first aspect, in a fifth implementation of the first aspect of the present invention, the remote driving service method of the dual-service system architecture further includes: The backup server sends test data packets to the master server and counts the connection success rate, measures the round-trip latency and counts the second packet loss rate. The verification is successful when the connection success rate reaches a preset success rate threshold, the round-trip latency is lower than a preset latency threshold, and the second packet loss rate is lower than a preset packet loss rate threshold. The vehicle status data and session status data maintained by the backup server are compared with the historical data of the main server to identify the differences. The differences are then synchronously transmitted to the main server to update the local data. The main server sends a path switching command to the vehicle end and the cabin end, and switches the flags of the video stream data and control command data received by the main data path to valid data.

[0011] In conjunction with the first aspect, in the sixth implementation of the first aspect of the present invention, the method of sending a path switching instruction from the main server to the vehicle end and the cabin end, and switching the markers of the video stream data and control instruction data received by the main data path to valid data, includes: The master server sends a path switching instruction containing a switching timestamp to the vehicle end and the cabin end. The vehicle end and the cabin end synchronously perform data tag switching at the switching timestamp, switching the tags of the video stream data and control command data transmitted through the main data path to valid data, and switching the tags of the video stream data and control command data transmitted through the backup data path to standby data.

[0012] In conjunction with the first aspect, in the seventh implementation of the first aspect of the present invention, the vehicle end and the cabin end synchronously perform data tag switching at the switching timestamp, switching the tags of the video stream data and control command data transmitted on the main data path to valid data, and switching the tags of the video stream data and control command data transmitted on the backup data path to standby data, including: When the switching timestamp arrives, the vehicle end and the cabin end simultaneously switch the flag of the data transmitted on the main data path from invalid data to valid data, and switch the flag of the data transmitted on the backup data path from valid data to standby data; The vehicle receives control command data from the main data channel and executes vehicle control, while the cabin receives video stream data from the main data channel and displays it.

[0013] In conjunction with the first aspect, in the eighth implementation of the first aspect of the present invention, after switching the markers of the video stream data and control command data transmitted through the backup data path to standby data, the method further includes: Switch the service status of the backup server from active service status to standby status, stop processing vehicle dispatching and video stream forwarding tasks, and clear temporary session data. The backup server, after switching to standby mode, restarts the heartbeat detection mechanism and periodically sends heartbeat detection messages to the master server.

[0014] Secondly, the present invention provides a remote driving service system with a dual-service system architecture, the remote driving service system with the dual-service system architecture comprising: A module is established to deploy a main server in the cloud and a backup server locally in the cabin, establishing a main data path from the vehicle to the cabin via the main server and a backup data path from the vehicle to the cabin via the backup server, and transmitting video stream data and control command data to the vehicle and the cabin in parallel through the main data path and the backup data path; The tag switching module is used to perform periodic heartbeat detection, delay detection, and packet loss rate detection on the main data path, and to switch the tags of the video stream data and control command data received by the backup data path as valid data based on the detected heartbeat timeout number, average delay value, and first packet loss rate.

[0015] The technical solution provided by this invention eliminates the single point of failure risk of homogeneous cloud deployments by employing a heterogeneous redundant deployment architecture of a cloud-based main server and a cabin-based backup server. Even when the entire cloud network link fails, the backup server can still establish a direct connection with the vehicle via the cabin's local network, ensuring the effectiveness of the redundancy mechanism in extreme scenarios. By pre-establishing a main data path and a backup data path for parallel transmission of video stream data and control command data, combined with periodic synchronization of vehicle scheduling status, driver session information, and network topology configuration to the backup server, the backup server is always equipped with complete service takeover capabilities without needing to re-initialize session connections or rebuild service instances in the event of a failure. A fault determination mechanism employing heartbeat detection, latency detection, and packet loss rate detection, along with joint judgment criteria, enables rapid and accurate identification of main server faults, reserving an effective time window for service switching. Immediately after fault determination, the data on the backup data path is marked as valid data. Since both paths have been continuously transmitting data before the switch, the switching process only involves modifying the local data source markings, achieving millisecond-level seamless switching. Video stream and control command transmission remain continuous and uninterrupted during the switching process. After the master server recovers, it ensures consistency of status through connection status verification, network performance testing and incremental data synchronization. Based on the switching timestamp, it realizes the synchronous switchback between the vehicle end and the cabin end. This invention does not require manual intervention, avoids delays and errors caused by human operation, and improves the availability, continuity and safety of the remote driving service system. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating the remote driving service method of the dual-service system architecture provided in this application embodiment; Figure 2 This is a schematic diagram of the overall deployment of the dual-service system architecture provided in the embodiments of this application; Figure 3 A schematic diagram of a primary and backup dual-path parallel data transmission architecture provided in an embodiment of this application; Figure 4 This is a flowchart illustrating the fault detection and automatic switching process during normal operation, as provided in an embodiment of this application. Figure 5 A complete flowchart of the state synchronization after the main server fails and recovers, provided in the embodiments of this application; Figure 6 The flowchart for startup initialization and continuous heartbeat monitoring provided in the embodiments of this application; Figure 7 The flowchart for fault type determination and main server recovery process provided in the embodiments of this application; Figure 8 A flowchart of the master server recovery verification and backup server notification provided in this application embodiment; Figure 9 A flowchart illustrating the process of primary / standby status comparison and incremental data synchronization provided in this application embodiment; Figure 10 A schematic block diagram of the structure of a remote driving service system with a dual-service system architecture provided in this application embodiment. Detailed Implementation

[0018] 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, not all, of the embodiments of the present invention. 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.

[0019] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content and operations / steps, nor does it necessarily have to be performed in the described order. For example, some operations / steps can be broken down, combined, or partially merged, so the actual execution order may change based on the actual situation.

[0020] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of the application. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

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

[0022] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features described herein can be combined with each other.

[0023] Please see Figure 1 , Figure 1 A flowchart illustrating the remote driving service method of the dual-service system architecture provided in this application embodiment is shown below. Figure 1 As shown in the embodiments of this application, the remote driving service method of the dual-service system architecture includes: Step S100: Deploy a main server in the cloud and a backup server locally in the cabin, establish a main data path from the vehicle to the cabin via the main server and a backup data path from the vehicle to the cabin via the backup server, and transmit video stream data and control command data to the vehicle and cabin in parallel through the main data path and the backup data path. Step S200: Perform periodic heartbeat detection, delay detection, and packet loss rate detection on the main data path. Based on the detected number of heartbeat timeouts, average delay value, and first packet loss rate, switch the markings of the video stream data and control command data received by the backup data path to valid data.

[0024] In one specific embodiment, the process of performing step S100 may specifically include the following steps: The main server for the vehicle scheduling module and video stream forwarding module is deployed and run in the cloud, and the backup server for the vehicle scheduling module and video stream forwarding module is deployed and run locally in the cabin. An encrypted communication link is established between the main server and the backup server. Vehicle dispatch status, driver session information, video stream data, and network topology configuration are periodically synchronized to the backup server via an encrypted communication link. Establish a main data path from the vehicle end to the cabin end via the main server and a backup data path from the vehicle end to the cabin end via the backup server. Transmit video stream data and control command data to the vehicle end and the cabin end in parallel through the main data path and the backup data path.

[0025] Specifically, a distributed deployment architecture is used to physically implement a primary and backup server located at different sites. The primary server is deployed in the cloud with high bandwidth and wide connectivity. The vehicle scheduling module integrated and continuously running on the primary server is responsible for functions such as route planning, task allocation, and scheduling priority setting for remote vehicles, while the video stream forwarding module is responsible for relaying, compressing, packetizing, and forwarding the video data collected by the vehicle to the cabin display terminal. Simultaneously, a backup server with the same functional modules as the primary server is deployed locally in the cabin. The backup server is in a real-time standby state and can seamlessly take over all tasks in the event of a primary server failure or connection failure. An encrypted communication link is established between the primary and backup servers, which can be based on the SSL / TLS protocol for encrypted handshake and to establish a trusted authentication channel. Through an encrypted communication link, the master server packages and synchronizes vehicle scheduling status (including current task execution node, queue instructions, vehicle number, location status, etc.), driver session information (such as binding ID, control permissions, voice / video channel information, etc.), video stream data (compressed and encoded video frames), and network topology configuration (including current end-to-end connection mapping table, relay path table, QoS policy parameters, etc.) to the backup server at fixed time intervals. The backup server caches, parses, and writes these data in real-time, ensuring that it always maintains a mirror image of the master server's state. A master data path is established between the vehicle, master server, and cabin. The vehicle's uplink first connects to the master server and then reaches the cabin via the scheduling route. Simultaneously, the vehicle and backup server establish independent bidirectional links to form a backup data path, creating a dual-path structure: vehicle → master server → cabin and vehicle → backup server → cabin. During system operation, video stream data and control command data are transmitted in parallel in a dual-redundancy mode. That is, at any given moment, the master server and the backup server will synchronously forward the received uplink data from the vehicle end to the cabin end and send the cabin end control input to the vehicle end. The data packet header will include a source identifier and a validity label so that the cabin end can determine whether to select the master data path or the backup data path as the current master data path under different switching states.

[0026] Figure 2This diagram illustrates the overall deployment of a remote driving service system with a dual-service architecture. It details the deployment locations and connections of four main components: the remote driving terminal, the cloud environment, the backup server, and the vehicle terminal. The remote driving terminal connects to the main server in the cloud environment via the primary data path and simultaneously establishes a backup connection with the backup server via a backup data transfer path. The main server, deployed in the cloud environment, handles vehicle scheduling, route planning, vehicle-specific management, real-time route transmission, video stream forwarding, and control command routing. The backup server, deployed locally in the vehicle terminal, includes modules for backup server functionality, backup node functionality, status synchronization, and application command processing. The vehicle terminal contains functional units for vehicle information, video acquisition, command execution, and status reporting. It connects to the main server via the cloud path and simultaneously establishes a backup data connection with the backup server.

[0027] Figure 3 This is a detailed schematic diagram of the dual-path parallel data transmission architecture. Specifically, it includes the data flow relationships between the remote driving terminal, the vehicle, the backup data path, and the primary data path. The remote driving terminal sends driving control commands to both the backup and primary data paths via control commands. The backup data path is provided by a local backup server in the cabin and includes uplink data, control commands, a driver operation processing unit, video streams, and a time-delayed downlink transmission unit. The primary data path is provided by a cloud-based master server and has an equivalent structure to the backup data path, also including uplink data, control commands, a driver operation processing unit, video streams, and a time-delayed downlink transmission unit. The vehicle synchronously uploads downlink data, vehicle status, and video streams to the remote driving terminal through both paths, achieving redundant data transmission.

[0028] In one specific embodiment, the process of establishing a main data path from the vehicle end to the cabin end via the main server and a backup data path from the vehicle end to the cabin end via the backup server, and transmitting video stream data and control command data to the vehicle end and cabin end in parallel through the main data path and the backup data path, can specifically include the following steps: The vehicle establishes a primary data path with the main server and receives connection information from the backup server. Based on the backup server connection information, a backup data path is established between the vehicle and the backup server. The video stream data collected by the vehicle is synchronously transmitted to the main data path and the backup data path. The control command data generated by the cabin is synchronously transmitted to the vehicle through the main data path and the backup data path. The video stream data and control command data transmitted through the main data path are marked as valid data.

[0029] Specifically, during the initialization phase, the handshake process between the vehicle-mounted terminal and the master server is completed, establishing a main data path that includes two-way authentication and encryption. After the main data path is successfully established, the master server sends the connection information of the currently activated cabin-end backup server, such as its network identifier, address port, and authentication token, to the vehicle-mounted terminal in the form of structured communication packets, enabling the vehicle-mounted terminal to obtain the key parameters required to build the backup path. After parsing the connection information, the vehicle-mounted terminal actively initiates a connection request with the cabin-end backup server and completes key negotiation, identity authentication, and channel encryption according to a preset encryption protocol, establishing a backup data path independent of the main path. This forms two independent two-way data channel structures between the vehicle-mounted terminal, the master server, and the backup server. During normal operation at the vehicle end, the image frame data acquired by its front-facing camera system or video acquisition module is compressed and encoded, and then sent in parallel to the main data path and the backup data path, so that the main server and the backup server receive the equivalent video stream simultaneously. Meanwhile, the control command data (such as speed setting, rudder angle adjustment, mode switching, etc.) issued by the cabin-side operating terminal is synchronously sent to the vehicle end in parallel by the main server and the backup server through their respective channels. During the reception process, the vehicle end will parse and prioritize the data received from each channel by attaching tags. By default, the control commands and video stream data received in the main data path are marked as the current "valid data" and used as the main data source for actual driving control decisions and image rendering. The data in the backup data path is stored as a real-time redundant data buffer, maintaining a state copy that is highly consistent with the content of the main path.

[0030] The video stream data collected by the vehicle end is synchronously transmitted to the main data path and the backup data path. The control command data generated by the cabin end is synchronously transmitted to the vehicle end through the main data path and the backup data path. This includes: when the vehicle end collects video stream data, it assigns an incrementing video frame sequence number to each video frame and synchronously sends the video stream data carrying the video frame sequence number to the main data path and the backup data path. The main server and the backup server receive the video stream data and record the received video frame sequence number. When the cabin end generates control command data, it assigns an incrementing command sequence number to each control command and synchronously sends the control command data carrying the command sequence number to the main data path and the backup data path. The main server and the backup server forward the control command to the vehicle end. The vehicle end and the cabin end respectively detect the continuity of the data packet sequence numbers received by the main data path and the backup data path, and count the number of missing sequence numbers in the two paths within a preset time window. When the number of missing sequence numbers in the main data path exceeds a preset multiple of the number of missing sequence numbers in the backup data path, it is determined that the data transmission quality of the main data path is abnormal.

[0031] The vehicle-mounted terminal establishes a primary data path with the main server and receives connection information from the backup server. Based on the backup server connection information, a backup data path is established between the vehicle-mounted terminal and the backup server. This includes: the vehicle-mounted terminal sending a connection request to the main server via a mobile network, carrying a vehicle authentication token; the main server verifying the vehicle authentication token and establishing a primary data path, and retrieving the backup server's local IP address and listening port number from the server address mapping table; the main server encapsulating the local IP address, listening port number, and session key into backup server connection information via the primary data path and sending it to the vehicle-mounted terminal; the vehicle-mounted terminal receiving the backup server connection information and parsing it to obtain connection parameters; and the vehicle-mounted terminal initiating a backup path connection request to the backup server via a mobile network or the local network of the vehicle-mounted terminal, carrying a session key, and the backup server verifying the session key and establishing a backup data path.

[0032] In one specific embodiment, the process of performing step S200 may specifically include the following steps: Periodic heartbeat detection, latency detection, and packet loss rate detection are performed on the main data path to obtain the number of heartbeat timeouts, average latency value, and first packet loss rate; When the number of heartbeat timeouts exceeds the preset threshold and the average latency exceeds the preset latency threshold, or when the number of heartbeat timeouts exceeds the preset threshold and the first packet loss rate exceeds the preset packet loss rate threshold, the markers for the video stream data and control command data transmitted through the backup data path are switched to valid data.

[0033] Specifically, a multi-dimensional link health monitoring module is integrated into the communication protocol stack of the main data path. After the remote driving service is started, the link health monitoring module sends heartbeat detection data packets to the target node of the main data path at fixed intervals (e.g., 100ms or 200ms). After each response, it records the current round-trip delay and timestamp, constructing a sliding window statistical sequence to calculate the number of heartbeat timeouts, the interval between consecutive heartbeat losses, the average response delay, and the cumulative packet loss rate per unit time. The heartbeat detection module uses the maximum allowed response time set by the system, such as 500ms as the upper limit for heartbeat response. If no response is received within any period, it is counted as a heartbeat timeout, and this timeout event is added to a counter. When the cumulative value of the counter within the set window exceeds a preset threshold (e.g., three consecutive timeouts), it is preliminarily determined that there is a potential link stability problem in the main path. Meanwhile, the latency detection module calculates the average round-trip time of the main data channel packets based on the timestamp difference and compares the average latency value with a preset latency threshold. If it exceeds 800ms, it is considered that there is severe network jitter or intermediate route congestion. The packet loss rate detection module performs packet sequence verification on the received data based on consecutive packet numbering or a sliding packet buffer window, and calculates the percentage of unreceived packets per unit time to obtain the first packet loss rate, which is then compared with a preset packet loss threshold (e.g., 5%). When the number of heartbeat timeouts not only exceeds the threshold, but the average latency value also exceeds the latency threshold, or when a combination of abnormal events occurs, such as the number of heartbeat timeouts exceeding the limit and the packet loss rate exceeding the tolerance level, it is determined that the main data channel has entered an unavailable or unstable state. At this time, the main / backup switchover logic module is triggered to mark the video stream data and control command data in the backup data channel as "valid data" and notifies the cabin display system and control module to switch from the original main data channel data stream to the backup data channel data stream for remote driving visual output and control command execution.

[0034] Figure 4 This is a flowchart illustrating the fault detection and automatic switchover process for the primary data path under normal operating conditions. Starting from normal operation, the primary server's status is periodically monitored via a heartbeat detection module. If the heartbeat detection is normal, monitoring continues; if the heartbeat detection is abnormal, the Bluetooth data path (backup data path) detection phase begins, where latency exceeding the threshold and packet loss rate exceeding the threshold are checked respectively. If either the latency exceeding the threshold or the packet loss rate exceeding the threshold is met, the primary server is deemed to have failed, triggering the switchover process. The data in the backup data path is then made valid, achieving automatic switching from the primary path to the backup path.

[0035] Before switching the marking of video stream data and control command data transmitted through the backup data path to valid data when the number of heartbeat timeouts exceeds a preset threshold and the average latency exceeds a preset latency threshold, or when the number of heartbeat timeouts exceeds a preset threshold and the first packet loss rate exceeds a preset packet loss rate threshold, the process includes: the vehicle end performing fault detection on the main data path to obtain the vehicle end fault determination result, and the cabin end performing fault detection on the main data path to obtain the cabin end fault determination result. The vehicle end fault determination result and the cabin end fault determination result are independent of each other. When the vehicle end fault determination result is that the main server has failed, the vehicle end immediately switches the marking of the backup data path control command data received by the vehicle end to valid data without waiting for cabin end confirmation. When the cabin end fault determination result is that the main server has failed, the cabin end immediately switches the marking of the backup data path video stream data received by the vehicle end to valid data without waiting for vehicle end confirmation. After the vehicle end and the cabin end complete their respective data marking switches, they send a switch completion notification message to the other end through the backup data path. After receiving the switch completion notification message, the other end confirms that the switch status of both ends is consistent.

[0036] In one specific embodiment, the process of switching the markers of the video stream data and control command data transmitted through the backup data path to valid data when the number of heartbeat timeouts exceeds a preset threshold and the average latency value exceeds a preset latency threshold, or when the number of heartbeat timeouts exceeds a preset threshold and the first packet loss rate exceeds a preset packet loss rate threshold, can specifically include the following steps: The flags for video stream data and control command data transmitted through the backup data path are switched from standby data to valid data, while the flags for data transmitted through the primary data path are switched from valid data to invalid data. The vehicle receives control command data from the backup data path and extracts control commands to execute vehicle control; the cabin receives video stream data from the backup data path and extracts video frames for display.

[0037] Specifically, in the architecture of primary and backup channels coexisting, each data packet on a transmission link is encapsulated with a data channel identifier field and a validity flag field. The channel identifier is used to distinguish between the primary data channel and the backup data channel, while the validity flag indicates whether the current data should be used for the primary channel data for vehicle control and video display. When a stability fault is detected in the primary data channel, such as a heartbeat interruption, excessive latency, or packet loss rate exceeding the threshold, and a primary / backup switchover decision is triggered, the switchover control module switches the validity flag of the data in the backup channel from "standby" to "valid," while simultaneously switching the flag of the data in the primary channel back to "invalid." The switchover operation is synchronized to the channel selection modules of the vehicle-side controller and the cabin-side display terminal through a state sharing mechanism, ensuring that all parsing, decoding, and execution processes are based on the data channel marked as valid. The vehicle-side control execution module extracts control fields such as steering angle command, acceleration setting, and driving mode based on the control command data packet received from the backup channel, and maps the parsing results to the control interface of the vehicle drive control system to complete real-time control of the vehicle. At the same time, the cabin-side video rendering module extracts image frames from the video stream data received from the backup data channel, completes decoding, format conversion, and buffer rendering processing, and updates the remote scene image on the driver's display terminal with minimal delay. This enables rapid path migration and uninterrupted operation of remote driving in the event of a main path failure, ensuring the continuous controllability of the system and the timeliness of visual closed-loop feedback.

[0038] Figure 5 This is a complete flowchart of the state synchronization process for the primary server after a failure. Starting from the failure recovery node, the switchover monitoring process is first executed to verify the primary server's connection status. Then, the primary and backup servers' states are synchronized, and the backup server's data synchronization operation is performed. After data synchronization is complete, the state after recovery is evaluated, and the process proceeds to the primary / backup switchover judgment node. If the switchover conditions are not met, synchronization continues. If the switchover conditions are met, the primary / backup role revert and data back to the primary server are executed in parallel. After completion, the primary and backup servers are swapped. Finally, the backup server re-backs up its state, ending at the backup server completion node.

[0039] The cabin receives video stream data from the backup data path and extracts video frames for display. This includes: when the backup server receives video stream data forwarded from the main server, it establishes a video stream buffer queue, stores the received video frames in the video stream buffer queue in timestamp order, and keeps the queue depth constant after the storage time of the video stream buffer queue reaches the preset buffer time; when the data marker of the backup data path is switched to valid data, the cabin reads the video frame corresponding to the current playback timestamp from the video stream buffer queue, sends the video frames to the video decoder in timestamp order for decoding, and renders them continuously on the display screen; the timestamp of the latest video frame in the video stream buffer queue is compared with the timestamp of the last video frame received by the main data path before the switch, and when the difference between the two timestamps is less than a preset time threshold, it is confirmed that the video frame sequence is continuous without frame skipping.

[0040] In one specific embodiment, the remote driving service method of the dual-service system architecture further includes: The backup server sends test data packets to the master server and counts the connection success rate, measures the round-trip latency and counts the second packet loss rate. The verification is successful when the connection success rate reaches the preset success rate threshold, the round-trip latency is lower than the preset latency threshold, and the second packet loss rate is lower than the preset packet loss rate threshold. The vehicle status data and session status data maintained by the backup server are compared with the historical data of the main server to identify the differences. The differences are then synchronously transmitted to the main server and the local data is updated. The main server sends path switching instructions to the vehicle and cabin ends and switches the flags of the video stream data and control command data received by the main data path to valid data.

[0041] Specifically, after the primary server recovers and comes back online, a connection verification process is initiated. This involves the backup server periodically sending test data packets to the primary server. These test packets contain identifiers such as timestamps, checksums, and synchronization flags to verify link quality and responsiveness. After sending the test data packets, the backup server listens for the primary server's response and measures the round-trip latency by calculating the timestamp difference between the responses. It also records the number of responses and packet losses over multiple consecutive test cycles, calculating the connection success rate and the second packet loss rate. The test results are compared to preset threshold standards. If the connection success rate consistently exceeds the preset success rate threshold (e.g., 95%), the round-trip latency is lower than the set maximum latency threshold (e.g., 500ms), and the packet loss rate is lower than the maximum tolerable packet loss rate threshold (e.g., 3%) across multiple consecutive test cycles, then the primary server link status is considered to have recovered to an usable level, and the failback condition verification is passed. After successful verification, the backup server enters the primary / backup status synchronization phase. By comparing its own maintained vehicle status data (such as real-time vehicle location, speed, steering angle, dispatch queue status, etc.) with the historical status data previously stored on the primary server, it identifies data fields with discrepancies, including newly added control command records, driver session context updates, and dispatch process status transitions. These discrepancies are packaged into a status incremental data packet and synchronously transmitted to the primary server via an encrypted link. The primary server's status update module then overwrites and merges the historical data, restoring its status view to be consistent with the current actual execution status. After data synchronization is complete, a role switching process begins. The primary server sends a primary / backup path switching command to both the vehicle and cabin ends through the management channel. The primary / backup path switching command includes a primary path recovery flag, path identifier priority settings, and validity flag switching fields. Upon receiving the primary / backup path switching command, the vehicle and cabin ends switch to the video stream data and control command data received by the primary data path, updating their data flags from "invalid data" to "valid data," and automatically switching the backup data path's flag to standby status. After the switchover is complete, the master server takes over the core service functions of remote driving tasks, such as command scheduling, video stream forwarding, and route planning, while the backup server automatically reverts to standby mode and continues to perform heartbeat detection and main pathway health status monitoring.

[0042] Figure 6This is a flowchart illustrating the initial configuration and subsequent continuous heartbeat monitoring process during startup. Starting from the startup node, initialization steps are executed sequentially, including initial synchronization, sending configuration data, and confirming synchronization completion. After initialization, a heartbeat detection loop is entered to determine if the heartbeat is normal. If the heartbeat is normal, the loop monitoring continues; if the heartbeat is abnormal, it is handled in two ways: one way performs real-time data synchronization, notifies the driver of the main server's abnormality, and then synchronizes vehicle information and session status; the other way directly returns to the heartbeat detection loop. After all synchronization operations converge, the loop returns to the heartbeat detection loop to continuously monitor the main server's operating status.

[0043] Figure 7 This is a flowchart for fault type determination and primary server recovery. Starting from the fault handling node, the fault type is first determined. If the fault is determined to be a primary server fault, a switchover to the backup server is executed, and the primary server continues to provide service, while simultaneously checking whether the primary server has recovered. Once the primary server recovers, a primary / backup role revert and data is transferred back to the primary server, restoring service. Finally, the process returns to the fault handling starting point. If the fault type is determined to be a non-primary server fault, the process directly enters the primary server recovery check loop, restoring normal service after the fault is resolved.

[0044] Before the master server sends a path switching command to the vehicle and cabin ends and switches the markings of the video stream data and control command data received by the master data path as valid data, the process also includes: the master server extracting the currently valid session key and encryption certificate synchronized by the backup server from the differential data, and loading the currently valid session key and encryption certificate into the local key storage module; after receiving the connection recovery notification sent by the master server, the vehicle and cabin ends use the same session key as the backup data path to initiate a master data path reconstruction request to the master server; after the master server verifies the session key match, it directly establishes an encrypted connection; when establishing an encrypted connection, the master server skips the TLS handshake and authentication process and reuses the currently valid session key for encrypted data transmission.

[0045] The process involves comparing the vehicle status data and session status data maintained by the backup server with the historical data of the master server to identify discrepancies. These discrepancies are then synchronously transmitted to the master server to update local data. This includes: the master server retrieving locally stored historical vehicle status data and session status data and calculating a first hash value; requesting and receiving currently maintained vehicle status data and session status data from the backup server and calculating a second hash value; comparing the first and second hash values ​​to identify discrepancies; marking dynamic parameters such as vehicle position, vehicle speed, and vehicle heading angle as high-priority discrepancies; marking driver session status flags and session connection parameters as medium-priority discrepancies; and marking network topology configuration as low-priority discrepancies. The master server then requests the backup server to send the discrepancies in order of priority. Upon receiving the discrepancies, the master server updates the corresponding data items in its local database. After the update, it recalculates the third hash value of the updated data and compares it with the second hash value. Successful data synchronization is confirmed when the two hash values ​​are identical.

[0046] In one specific embodiment, the process of executing the steps of sending a path switching command from the master server to the vehicle end and the cabin end, and switching the flags of the video stream data and control command data received by the master data path to valid data, can specifically include the following steps: The master server sends a path switching command containing a switching timestamp to both the vehicle and cabin ends. The vehicle and cabin ends synchronously perform data tag switching at the switching timestamp, switching the tags of video stream data and control command data transmitted through the main data path to valid data, and switching the tags of video stream data and control command data transmitted through the backup data path to standby data.

[0047] Specifically, after the primary / backup switchback logic verification is completed and the status data synchronization is finished, the primary server initiates a unified path switching command. This command includes a clear "switching timestamp" field, using a standard Coordinated Time format (e.g., UTC) to mark that the vehicle and cabin ends will simultaneously complete the data flow path validity update operation at this specified time. The switching command is sent to the vehicle control unit and cabin display terminal respectively through existing control channels. After receiving the switching command, the vehicle and cabin ends perform local clock alignment processing on the switching timestamp field in the command. If there is a drift error in the local clock, time correction is performed through the primary server's clock synchronization mechanism (e.g., NTP or a time difference compensation algorithm based on heartbeat synchronization calculation) to ensure that the vehicle and cabin ends have a consistent switching time base. When the local timer reaches the time point marked by the switching timestamp, the vehicle and cabin ends synchronously execute the data marking switching logic. The vehicle updates the validity fields of the video stream data and control command data received by the main data path, which was previously marked as "backup data," to "valid data." At the same time, it switches the data received by the backup data path, which was originally the current main path, to "backup data," completing the data source switch for the control path. It then continues to extract and execute control commands based on the updated main data path. At the same time, the cabin end completes the path switching operation for the video rendering source, using the video stream received by the main data path as the current image frame decoding and display input source, and marks the backup data path as a backup buffer path for takeover in case of link degradation. Because the switching process is synchronously triggered based on a unified timestamp, the system's main / backup switchover operation in a distributed environment has high consistency and synchronization, avoiding control drift, image delay, or data source conflicts caused by asynchronous switching delays between the vehicle and cabin ends.

[0048] In one specific embodiment, the vehicle end and the cabin end synchronously perform data tag switching at the switching timestamp, switching the tags of video stream data and control command data transmitted on the main data path to valid data, and switching the tags of video stream data and control command data transmitted on the backup data path to standby data, including: When the switching timestamp arrives, the vehicle end and the cabin end synchronously switch the flag of the data transmitted on the main data path from invalid data to valid data, and switch the flag of the data transmitted on the backup data path from valid data to standby data. The vehicle receives control command data from the main data channel and executes vehicle control, while the cabin receives video stream data from the main data channel and displays it.

[0049] Specifically, the switching timestamp carried in the path switching command issued by the master server serves as the global synchronization trigger point. After the path switching command reaches the vehicle and cabin terminals, both terminals align their local system clocks with the master server's time. A time synchronization mechanism (such as heartbeat time compensation or based on the NTP time synchronization protocol) is used to calibrate the current local clock and the switching timestamp to millisecond-level consistency, ensuring that the switching operation is strictly synchronized between the two terminals. At the instant the local clock reaches the moment corresponding to the switching timestamp, both the vehicle and cabin terminals update the current data path marking status in their marking management modules. The data marking field received by the main data path, previously in an "invalid" state, is switched to "valid," while the data marking field received by the backup data path, previously in an "valid" state, is changed to "standby," thus completing the data layer marking switchover where the main path regains control. After the marking switch is completed, the vehicle-side control execution unit performs the parsing and execution process based on the control command data received from the main data path. The control parameters such as steering angle, acceleration and deceleration control amount, and driving mode setting extracted from the main data path are mapped into actual vehicle control signals and sent to the drive system to realize continuous remote control of the vehicle. At the same time, the cabin-side image processing module parses the image frame content from the video stream data received from the main data path, completes decoding, deinterleaving and image frame buffering processing, and outputs it to the remote driver interface for visualization, so that the operator can immediately obtain continuous and stable remote scene feedback images after the main / standby switch.

[0050] Figure 8 This is a flowchart of the connection verification and backup server notification process after the primary server recovers. Starting from the primary server recovery node, the first step is to check the connection status to determine if the connection is normal. If the connection is abnormal, the process returns to continue checking. If the connection is normal, the next step is to check the data latency to determine if the latency is normal. If the latency is abnormal, the process returns to continue checking the latency. If the latency is normal, the primary path is enabled, and the backup server is notified that the primary server has recovered. Finally, the state synchronization process begins, preparing for the primary / backup role switchover.

[0051] In one specific embodiment, after switching the tags of the video stream data and control command data transmitted through the backup data path to standby data, the method further includes: Switch the backup server's service status from active to standby, stop processing vehicle dispatching and video stream forwarding tasks, and clear temporary session data. The backup server, after switching to standby mode, restarts the heartbeat detection mechanism and periodically sends heartbeat detection messages to the master server.

[0052] Specifically, after the remote driving system completes the role switchover operation on the primary / backup path, the backup server switches its service status from "active service state" to "standby state" to release computing resources and restore the redundant node role. The status switch is executed by the local service control module, which switches the role identifier and sends a stop signal to the video stream forwarding module and vehicle scheduling module, instructing the backup server to terminate the current scheduling link's computing processing tasks and video data forwarding tasks. Furthermore, it clears temporary data still retained in memory, such as session cache, intermediate vehicle control task states, video frame cache, and instruction buffers. The backup node does not retain any historical interaction context after stopping service. Subsequently, the backup server re-enters the standby monitoring phase and restarts the heartbeat detection mechanism, periodically sending heartbeat probe messages to the primary server. The heartbeat probe message is generated by the local heartbeat module and includes fields such as the current timestamp, backup node identifier, status field, and digital signature, and is sent to the primary server's designated heartbeat listening port through an encrypted communication channel. After receiving the heartbeat probe message, the master server returns an acknowledgment message with a response timestamp, enabling the backup server to measure the link status based on round-trip time, record communication latency, and continuously verify the connection validity of the master server.

[0053] Figure 9 This is a flowchart illustrating the process of comparing the status of primary and backup servers and synchronizing incremental data. Starting from the status comparison node, it determines whether the status of the primary and backup servers is consistent. If the statuses are consistent, synchronization is skipped and the process proceeds directly to the next step. If the statuses are inconsistent, data synchronization is performed. After data synchronization is complete, operations such as primary / backup role rollback, backup server standby, and recovery heartbeat detection are executed sequentially, ultimately reaching the normal recovery termination node, completing the entire process of the primary server recovering and resuming its control over core services.

[0054] Please see Figure 10 , Figure 10 A schematic block diagram of the structure of the remote driving service system 200 with a dual-service system architecture provided in this application embodiment, as shown below. Figure 10 As shown, the remote driving service system 200 with a dual-service system architecture includes: Module 210 is established to deploy a main server in the cloud and a backup server locally in the cabin, to establish a main data path from the vehicle to the cabin via the main server and a backup data path from the vehicle to the cabin via the backup server, and to transmit video stream data and control command data to the vehicle and cabin in parallel through the main data path and the backup data path. The tag switching module 220 is used to perform periodic heartbeat detection, delay detection and packet loss rate detection on the main data path, and to switch the tags of the video stream data and control command data received by the backup data path to valid data based on the detected heartbeat timeout number, average delay value and first packet loss rate.

[0055] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0056] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

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

Claims

1. A remote driving service method of a dual-service system architecture, characterized by, include: A main server is deployed in the cloud and a backup server is deployed locally in the cabin. A main data path from the vehicle to the cabin via the main server and a backup data path from the vehicle to the cabin via the backup server are established. Video stream data and control command data are transmitted in parallel to the vehicle and the cabin through the main data path and the backup data path. Periodic heartbeat detection, delay detection, and packet loss rate detection are performed on the main data path. Based on the detected number of heartbeat timeouts, average delay value, and first packet loss rate, the markings of the video stream data and control command data received by the backup data path are switched to valid data. 2.The remote driving service method of the dual-service system architecture of claim 1, wherein, A master server is deployed in the cloud and a backup server is deployed locally in the cabin. A main data path is established from the vehicle to the cabin via the master server and a backup data path is established from the vehicle to the cabin via the backup server. Video stream data and control command data are transmitted in parallel to the vehicle and the cabin via the main data path and the backup data path, including: A main server for deploying and running the vehicle scheduling module and video stream forwarding module is deployed and run in the cloud, and a backup server for deploying and running the vehicle scheduling module and video stream forwarding module is deployed and run locally in the cabin, establishing an encrypted communication link between the main server and the backup server; The vehicle dispatch status, driver session information, video stream data, and network topology configuration are periodically synchronized to the backup server through the encrypted communication link. A main data path is established from the vehicle end to the cabin end via the main server, and a backup data path is established from the vehicle end to the cabin end via the backup server. Video stream data and control command data are transmitted in parallel to the vehicle end and the cabin end through the main data path and the backup data path.

3. The remote driving service method of the dual-service system architecture according to claim 2, characterized in that, Establish a main data path from the vehicle end to the cabin end via the main server and a backup data path from the vehicle end to the cabin end via the backup server. Transmit video stream data and control command data to the vehicle end and the cabin end in parallel through the main data path and the backup data path, including: The vehicle establishes a primary data path with the main server and receives connection information from the backup server. Based on the backup server connection information, a backup data path is established between the vehicle and the backup server. The video stream data collected by the vehicle end is synchronously transmitted to the main data path and the backup data path. The control command data generated by the cabin end is synchronously transmitted to the vehicle end through the main data path and the backup data path. The video stream data and control command data transmitted by the main data path are marked as valid data.

4. The remote driving service method of the dual-service system architecture according to claim 3, characterized in that, The main data path undergoes periodic heartbeat detection, latency detection, and packet loss rate detection. Based on the detected heartbeat timeout count, average latency value, and first packet loss rate, the flags of the video stream data and control command data received by the backup data path are switched to valid data, including: Periodic heartbeat detection, delay detection, and packet loss rate detection are performed on the main data path to obtain the number of heartbeat timeouts, the average delay value, and the first packet loss rate; When the number of heartbeat timeouts exceeds a preset threshold and the average latency exceeds a preset latency threshold, or when the number of heartbeat timeouts exceeds a preset threshold and the first packet loss rate exceeds a preset packet loss rate threshold, the markings of the video stream data and control command data transmitted through the backup data path are switched to valid data.

5. The remote driving service method of the dual-service system architecture according to claim 4, characterized in that, When the number of heartbeat timeouts exceeds a preset threshold and the average latency exceeds a preset latency threshold, or when the number of heartbeat timeouts exceeds a preset threshold and the first packet loss rate exceeds a preset packet loss rate threshold, the markers for the video stream data and control command data transmitted through the backup data path are switched to valid data, including: The flags of the video stream data and control command data transmitted through the backup data path are switched from standby data to valid data, while the flags of the data transmitted through the main data path are switched from valid data to invalid data. The vehicle receives control command data from the backup data path and extracts control commands to execute vehicle control; the cabin receives video stream data from the backup data path and extracts video frames for display.

6. The remote driving service method of the dual-service system architecture according to claim 1, characterized in that, The remote driving service method of the dual-service system architecture also includes: The backup server sends test data packets to the master server and counts the connection success rate, measures the round-trip latency and counts the second packet loss rate. The verification is successful when the connection success rate reaches a preset success rate threshold, the round-trip latency is lower than a preset latency threshold, and the second packet loss rate is lower than a preset packet loss rate threshold. The vehicle status data and session status data maintained by the backup server are compared with the historical data of the main server to identify the differences. The differences are then synchronously transmitted to the main server to update the local data. The main server sends a path switching command to the vehicle end and the cabin end, and switches the flags of the video stream data and control command data received by the main data path to valid data.

7. The remote driving service method of the dual-service system architecture according to claim 6, characterized in that, Based on the main server sending a path switching command to the vehicle end and the cabin end, and switching the flags of the video stream data and control command data received by the main data path to valid data, including: The master server sends a path switching instruction containing a switching timestamp to the vehicle end and the cabin end. The vehicle end and the cabin end synchronously perform data tag switching at the switching timestamp, switching the tags of the video stream data and control command data transmitted through the main data path to valid data, and switching the tags of the video stream data and control command data transmitted through the backup data path to standby data.

8. The remote driving service method of the dual-service system architecture according to claim 7, characterized in that, The vehicle end and the cabin end synchronously perform data tag switching at the switching timestamp, switching the tags of the video stream data and control command data transmitted on the main data path to valid data, and switching the tags of the video stream data and control command data transmitted on the backup data path to standby data, including: When the switching timestamp arrives, the vehicle end and the cabin end simultaneously switch the flag of the data transmitted on the main data path from invalid data to valid data, and switch the flag of the data transmitted on the backup data path from valid data to standby data; The vehicle receives control command data from the main data channel and executes vehicle control, while the cabin receives video stream data from the main data channel and displays it.

9. The remote driving service method of the dual-service system architecture according to claim 7, characterized in that, After switching the tags of the video stream data and control command data transmitted through the backup data path to standby data, the method further includes: Switch the service status of the backup server from active service status to standby status, stop processing vehicle dispatching and video stream forwarding tasks, and clear temporary session data. The backup server, after switching to standby mode, restarts the heartbeat detection mechanism and periodically sends heartbeat detection messages to the master server.

10. A remote driving service system with a dual-service system architecture, characterized in that, A remote driving service method for implementing a dual-service system architecture as described in any one of claims 1-9 includes: A module is established to deploy a main server in the cloud and a backup server locally in the cabin, establishing a main data path from the vehicle to the cabin via the main server and a backup data path from the vehicle to the cabin via the backup server, and transmitting video stream data and control command data to the vehicle and the cabin in parallel through the main data path and the backup data path; The tag switching module is used to perform periodic heartbeat detection, delay detection, and packet loss rate detection on the main data path, and to switch the tags of the video stream data and control command data received by the backup data path as valid data based on the detected heartbeat timeout number, average delay value, and first packet loss rate.

Images