Service availability guarantee method, device and system

Abstract

The invention relates to the technical field of vehicles, and provides a service availability guarantee method, device and system, and the method comprises the steps: monitoring the availability state of a target service; when it is monitored that the target service is changed from the available state to the unavailable state, a first state notification is sent to a function controller related to the target service, so that the function controller switches communication related to the target service from the first communication mode to a second communication mode, and the service reliability of the second communication mode is higher than that of the first communication mode; and when it is monitored that the target service is recovered to be available, sending a second state notification to the function controllers, so that the plurality of function controllers switch communication related to the target service from the second communication mode to the first communication mode. According to the service availability guarantee method, device and system provided by the invention, the continuity of system functions is fundamentally guaranteed by continuously monitoring the availability state of the target service and combining an automatic switching mechanism when the service is unavailable.

Description

Technical Field

[0001] This invention relates to the field of vehicle technology, and more particularly to a method, apparatus, and system for ensuring service availability. Background Technology

[0002] With the continuous improvement of vehicle intelligence and connectivity, the vehicle's electronic and electrical architecture is transforming from traditional distributed control to a service-oriented architecture. Service-oriented architecture achieves loosely coupled interaction between functional domains through standardized service interfaces, significantly improving system flexibility and scalability, and laying the foundation for software-defined vehicles. In a typical vehicle-cloud integrated SOA architecture, automotive Ethernet, with its high bandwidth, becomes the backbone network for service communication, while the traditional CAN bus continues to play a role in connecting underlying actuators and sensors.

[0003] However, this heterogeneous network coexistence SOA architecture also introduces new challenges, especially in terms of system high availability. The in-vehicle environment is complex and harsh, and service interfaces or electronic control units acting as service providers may fail due to software anomalies, hardware failures, or network interruptions. When critical services (such as autonomous driving decisions and intelligent cockpit interactions) are interrupted, the inability to quickly implement fault-tolerant processing will directly threaten driving safety and user experience.

[0004] In existing technologies, solutions for high service availability are mostly concentrated in the cloud or within a single functional domain, such as through heartbeat detection mechanisms at the redundant hardware or software level. However, these solutions have significant shortcomings: First, they lack a mechanism for unified, real-time monitoring and centralized decision-making of service status at the vehicle level, resulting in fragmented fault detection and high response latency; second, when SOA services on Ethernet fail, they rely on manual configuration or static redundancy switching strategies, which cannot achieve automatic, dynamic, and rapid circuit breaking and degradation of service call paths across heterogeneous networks (such as high-performance Ethernet and high-reliability CAN bus), leading to fault recovery times of up to minutes, which cannot meet real-time requirements; in addition, the propagation and recovery of fault status lack an effective vehicle-level broadcast notification mechanism, making it difficult to synchronize the status of each node, which can easily lead to incomplete functional degradation or inconsistent recovery.

[0005] Therefore, there is an urgent need in this field for an intelligent fault-tolerant mechanism that can be deeply integrated with SOA architecture, capable of sensing the health status of services in real time, and automatically and quickly switching service calls from the failed high-performance path to a reliable backup path when a fault is detected, so that it can automatically switch back after the service is restored, thereby ensuring the continuity and high availability of the whole vehicle functions, especially the critical functions, in complex vehicle environments. Summary of the Invention

[0006] This invention provides a service availability assurance method, apparatus, and system to address the shortcomings of existing technologies in vehicle-cloud integrated SOA architecture, such as slow service failure response, incomplete degradation, and lack of vehicle-level automatic fault tolerance mechanisms. It achieves second-level detection, automatic circuit breaking, dynamic degradation, and rapid recovery of service failures, ensuring the continuity and high availability of critical functions.

[0007] This invention provides a service availability assurance method, comprising: Monitor the availability status of the target service; When the target service is detected to change from an available state to an unavailable state, a first state notification is sent to the function controller associated with the target service, so that the function controller switches the communication associated with the target service from a first communication mode to a second communication mode, wherein the service reliability of the second communication mode is higher than that of the first communication mode; When the target service is detected to be available again, a second status notification is sent to the function controller so that the multiple function controllers switch the communication related to the target service from the second communication mode to the first communication mode.

[0008] According to the service availability assurance method provided by the present invention, monitoring the availability status of the target service includes: The health status of the target service is monitored in real time through a heartbeat detection mechanism and / or a service registry query method. Based on the health status and the preset health threshold, the availability status of the target service is determined.

[0009] According to the service availability assurance method provided by the present invention, sending a first status notification and a second status notification to a function controller related to the target service includes: The first status notification and the second status notification are broadcast to the function controller and the cloud server via Ethernet and vehicle-cloud network, respectively. The first and second status notifications carry service identifiers, status types, and timestamp information.

[0010] According to the service availability assurance method provided by the present invention, after sending a first status notification to the function controller related to the target service, the method further includes: Periodically send service probe requests to the target service; When the target service receives a series of successful responses to the service probe request, it is confirmed that the target service has been restored to availability.

[0011] According to the service availability assurance method provided by the present invention, the first communication method is an Ethernet-based SOA service call, and the second communication method is a CAN bus-based signal call.

[0012] The present invention also provides a service availability assurance method, comprising: When a first status notification is received, communication related to the target service will be switched from the first communication method to the second communication method, where the service reliability of the second communication method is higher than that of the first communication method. When a second status notification is received, communication related to the target service will be switched from the second communication method to the first communication method. The first status notification is sent by the control center when it detects that the target service has changed from an available state to an unavailable state, and the second status notification is sent by the control center when it detects that the target service has been restored to an available state.

[0013] According to the service availability assurance method provided by the present invention, after switching the communication related to the target service from the first communication mode to the second communication mode, or after switching the communication related to the target service from the second communication mode to the first communication mode, the method further includes: Report the current service communication status to the control center.

[0014] The present invention also provides a service availability assurance device, comprising: The status monitoring unit is used to monitor the availability status of the target service; The first notification sending unit is used to send a first status notification to the function controller related to the target service when it is detected that the target service changes from an available state to an unavailable state, so that the function controller switches the communication related to the target service from a first communication mode to a second communication mode, wherein the service reliability of the second communication mode is higher than that of the first communication mode. The second notification sending unit is used to send a second status notification to the function controller when the target service is detected to be available again, so that the plurality of function controllers switch the communication related to the target service from the second communication mode to the first communication mode.

[0015] The present invention also provides a service availability assurance device, comprising: The first switching unit is used to switch the communication related to the target service from the first communication mode to the second communication mode when a first status notification is received, wherein the service reliability of the second communication mode is higher than that of the first communication mode. The second switching unit is used to switch the communication related to the target service from the second communication method to the first communication method when a second status notification is received. The first status notification is sent by the control center when it detects that the target service has changed from an available state to an unavailable state, and the second status notification is sent by the control center when it detects that the target service has been restored to an available state.

[0016] The present invention also provides a service availability assurance system, comprising: The control center is used to monitor the availability status of the target service. When the target service is detected to change from an available state to an unavailable state, a first status notification is sent to the functional controllers associated with the target service. The function controller is configured to receive the first status notification and switch the communication related to the target service from the first communication mode to the second communication mode, wherein the service reliability of the second communication mode is higher than that of the first communication mode. The control center is also used to send a second status notification to the function controller when it detects that the target service has been restored to availability; The function controller is further configured to receive the second status notification and switch communication related to the target service from the second communication mode to the first communication mode.

[0017] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the service availability assurance method as described above.

[0018] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the service availability assurance method as described above.

[0019] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the service availability assurance method as described above.

[0020] The service availability assurance method, apparatus, and system provided by this invention fundamentally ensure the continuity of system functions by continuously monitoring the availability status of the target service and combining it with an automatic switching mechanism when the service is unavailable. The combination of centralized monitoring and broadcast notification mechanisms enables real-time fault response and rapid business recovery. Compared to traditional distributed detection or manual intervention schemes, this invention avoids state negotiation delays through unified decision-making and instantaneous broadcasting by a central node, enabling the entire system to respond synchronously to fault events. When the service is restored, the system can automatically switch back to the optimal communication path, achieving a smooth transition between degraded and optimal modes and minimizing the window of performance loss. Attached Figure Description

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

[0022] Figure 1 This is one of the flowcharts illustrating the service availability assurance method provided by the present invention.

[0023] Figure 2 This is the second flowchart illustrating the service availability assurance method provided by the present invention.

[0024] Figure 3 This is the third flowchart of the service availability assurance method provided by the present invention.

[0025] Figure 4 This is the fourth flowchart of the service availability assurance method provided by the present invention.

[0026] Figure 5 This is the fifth flowchart illustrating the service availability assurance method provided by the present invention.

[0027] Figure 6 This is one of the structural schematic diagrams of the service availability assurance device provided by the present invention.

[0028] Figure 7 This is the second structural schematic diagram of the service availability assurance device provided by the present invention.

[0029] Figure 8 This is a schematic diagram of the service availability assurance system provided by the present invention.

[0030] Figure 9 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0031] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this 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 this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0032] As the Electronic / Electrical Architecture (EEA) of intelligent connected vehicles evolves towards a centralized Service-Oriented Architecture (SOA), vehicle functions rely on cross-domain SOA service calls to achieve loosely coupled interaction. However, in real-world in-vehicle operating environments, target services (such as autonomous driving decision-making services, cockpit voice recognition services, and vehicle status aggregation services) are susceptible to ECU hardware failures, network congestion, software anomalies, or power supply fluctuations, leading to service interface response timeouts, error code returns, or complete disconnection. Existing high-availability solutions are mostly limited to heartbeat detection within a single controller or redundant deployment in the cloud, lacking a unified monitoring view covering the entire vehicle's domain control nodes and the vehicle-cloud network. After a service failure, the system typically passively waits for retries or manual intervention, unable to complete communication path reconstruction within milliseconds to seconds. When the Ethernet SOA service is interrupted, there is currently no mechanism to drive all relevant vehicle function controllers to synchronously degrade to a lower-level deterministic communication path (such as the CAN bus), resulting in unacceptable interruption risks for critical functions such as ADAS, intelligent driving takeover, and emergency alarms. Therefore, there is an urgent need for a vehicle-level service availability assurance method that can achieve global awareness of service status, instantaneous circuit breaking of faults, autonomous switching of communication paths, and automatic recovery and upgrade, in order to solve the problem of functional link breakage caused by single point service failure under SOA architecture.

[0033] Against the above background, embodiments of the present invention provide a service availability assurance method. In this method, a control center monitors the availability status of a target service; when the target service is detected to change from an available state to an unavailable state, a first status notification is sent to the functional controllers related to the target service, so that the functional controllers switch the communication related to the target service from a first communication mode to a second communication mode, wherein the service reliability of the second communication mode is higher than that of the first communication mode; when the target service is detected to be restored to availability, a second status notification is sent to the functional controllers, so that multiple functional controllers switch the communication related to the target service from the second communication mode to the first communication mode.

[0034] The service availability assurance method provided in this invention, through continuous monitoring of the target service availability status by the control center and combined with an automatic switching mechanism when services are unavailable, fundamentally ensures the continuity of system functions. When a service failure is detected, the system can immediately drive the relevant function controller to seamlessly switch communication from a high-performance first communication mode to a high-reliability second communication mode. This allows critical in-vehicle services (such as autonomous driving and intelligent cockpit interaction) to continue operating even when facing a single point of failure, thereby transforming the passive waiting for service interruption into an active guarantee of functional availability, significantly improving vehicle safety and user experience.

[0035] Secondly, the combination of centralized monitoring and broadcast notification mechanisms enables real-time fault response and rapid business recovery. Compared to traditional distributed detection or manual intervention solutions, this method avoids state negotiation delays through unified decision-making and instantaneous broadcasting by the central node, allowing the entire system to respond to fault events synchronously and reducing fault recovery time from minutes to seconds. Furthermore, once service is restored, the system automatically switches back to the optimal communication path, achieving a smooth transition between degraded and optimal modes and minimizing the window of performance loss.

[0036] The embodiments of the present invention can be applied to service availability assurance scenarios for vehicles. The executing entity of this method can be an electronic device such as a terminal device, computer, server, server cluster, or specially designed service availability assurance device. The electronic device can be, for example, a central computing unit (CCU) or a service availability assurance device installed in the electronic device, which can be implemented through software, hardware, or a combination of both.

[0037] In the description of the embodiments of the present invention, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the stated features. In the description of the embodiments of the present invention, "multiple" means two or more, unless otherwise explicitly specified.

[0038] Figure 1 This is one of the flowcharts illustrating the service availability assurance method provided by the present invention. The executing entity of this method can be a control center, such as a central computing unit (CCU). Figure 1 As shown, the method includes the following steps 110-130.

[0039] Step 110: Monitor the availability status of the target service.

[0040] Specifically, the target service refers to the specific software service unit being monitored, such as "autonomous driving map data service" or "intelligent cockpit voice recognition service." Availability status refers to whether the service can normally receive requests and return the expected response; it is usually a binary value: available or unavailable.

[0041] The control center, such as the SOA service health monitoring component built into the central computing unit, can continuously assess the status of target service instances deployed on various functional domain controllers of the vehicle (such as the Intelligent Driving Domain Controller (ADC), Cockpit Domain Controller (CDC), Zone Controller (ZCU), T-Box, etc.). This monitoring component achieves status monitoring by periodically collecting multi-dimensional operational metrics of the service interfaces. These multi-dimensional operational metrics may include, for example, interface response time (RTT), number of consecutive failed calls, service heartbeat reporting status in the service registry, sudden changes in service process memory usage, and ECU underlying CAN / LIN message transmission and reception integrity verification results.

[0042] In some embodiments, monitoring the availability status of a target service specifically includes: The health status of the target service is monitored in real time through a heartbeat detection mechanism and / or a service registry query method; based on the health status and preset health thresholds, the availability status of the target service is determined.

[0043] Specifically, monitoring the availability status of the target service is a prerequisite for achieving fault detection and response decisions in service availability assurance methods. Its core lies in building a quantifiable, configurable, and low-false-report dynamic judgment mechanism. This monitoring behavior is not a one-time snapshot judgment, but a continuous, periodic, and multi-source integrated runtime evaluation process, covering multiple dimensions such as service process liveness, interface reachability, response quality, and context consistency, providing a reliable basis for subsequent circuit breaking and degradation.

[0044] The heartbeat detection mechanism involves the control center proactively initiating a lightweight probe request (such as a Ping command) to the target service and receiving a response signal from the server. If no response is received multiple times consecutively, the service is deemed unavailable.

[0045] The service registry query method refers to the control center periodically polling the registration metadata of the target service through the standard service discovery protocol. The registry is completed by each functional controller (such as the Automated Driving Domain Controller (ADC) and the Intelligent Driving Domain Controller (ZCU) when the service starts. The registration information includes at least: service unique identifier, host IP address or CAN node address, service version number, health check endpoint, last heartbeat timestamp, and service status.

[0046] The control center sends requests to the registry center every 1–3 seconds, parsing the fields in the returned JSON response body to see if they are within a preset timeout window (if not updated within 6 seconds, it is marked as an exception). This method provides a global perspective and can identify "zombie services" caused by process crashes or improper deregistration, making up for the problem that single heartbeats cannot detect service logic deadlocks.

[0047] The heartbeat detection mechanism and service registry query method can be used independently or in combination. For example, heartbeat detection can be used first to obtain real-time response quality indicators (such as error rate and P99 latency), and then the service lifecycle status can be verified by data from the registry, forming a dual verification model of "real-time performance + static metadata", which significantly reduces the false positive rate.

[0048] The health status of the target service is a structured data set output by the monitoring process, which includes at least the following parameters: response success rate, average response time, error code distribution, heartbeat survival rate, registry report status, and service load metrics.

[0049] The preset health threshold is a configurable criterion set by the OEM based on the functional safety level (ASIL) and user experience requirements. For example, for ASIL-B level brake assist services, the threshold is configured as follows: three consecutive heartbeat timeouts (>500ms) or a success rate below 95% are considered unavailable; for ASIL-A level infotainment services, a more lenient threshold is allowed (such as five timeouts or a success rate of 90%).

[0050] In this embodiment, the heartbeat detection mechanism and the service registry query method constitute the data acquisition layer, providing a heterogeneous input source for status determination; the health status serves as an intermediate data carrier, carrying the original monitoring results and forming stable indicators through time-series processing; the preset health threshold serves as a set of decision rules, giving the system configurable intelligent discrimination capabilities. The three work together to achieve accurate, real-time, and adaptive determination of the availability of the target service.

[0051] Step 120: When the target service is detected to change from available to unavailable, a first status notification is sent to the function controller related to the target service so that the function controller switches the communication related to the target service from the first communication mode to the second communication mode. The service reliability of the second communication mode is higher than that of the first communication mode.

[0052] Specifically, the first status notification is a specific signal or message stating "Target service unavailable," used to trigger the degradation process. Functional controllers related to the target service refer to clients or consumers that depend on the target service, such as autonomous driving domain controllers that need to call "map data services."

[0053] The first communication method refers to a high-performance but potentially less reliable communication path used under normal conditions, such as an Ethernet-based SOA service call (e.g., SOME / IP). The second communication method refers to a highly reliable but relatively low-performance communication path used under degraded conditions, such as a CAN bus signal.

[0054] In this step, when a fault is detected, all relevant parties are quickly and consistently notified, and the system is driven to execute the predetermined degradation strategy. The aim is to isolate the impact of the fault at the higher service layer and ensure the continuity of core hardware functions through backup paths. This achieves rapid fault isolation and rapid service resumption, preventing the entire functional module from being paralyzed due to a single service failure, transforming service interruption into service degradation, and ensuring the availability of the most basic functions.

[0055] Figure 2 This is the second flowchart illustrating the service availability assurance method provided by the present invention, as shown below. Figure 2 As shown, the complete process from the occurrence of a fault to system degradation is described. Under normal conditions, the service caller (such as ADC), the monitoring and decision-making unit (CCU), and the service provider (such as CDC) interact normally. When the CCU actively detects a fault, that is, when the target service changes from an available state to an unavailable state, the CCU decides to disconnect the original SOA Ethernet link and broadcasts it. Each node automatically performs degradation and switches the communication mode from SOA service to CAN signal, thereby ensuring the continued availability of core hardware functions.

[0056] Step 130: When the target service is detected to be available again, a second status notification is sent to the function controller so that multiple function controllers switch the communication related to the target service from the second communication mode to the first communication mode.

[0057] Specifically, the second status notification is a specific signal or message stating "The target service has been restored to availability," used to trigger the recovery process. Restoring availability means that the target service is now able to stably process requests and return correct responses.

[0058] This step, once the service failure is confirmed to be resolved, notifies all system components to switch back to the optimal operating mode. The aim is to promptly restore the system's full performance and functionality after the risk has been eliminated, ending the degraded state. This achieves self-healing and optimization of system performance and functionality, ensuring that the degraded state is not permanent. Once the underlying issues are resolved, the system can automatically return to its optimal configuration, providing users with a complete service experience.

[0059] Understandably, the notification methods for the first and second state statuses can be either a structured message sent by the control center to the entire network or a specific multicast group via the vehicle's Ethernet, or a publish-subscribe model. When implemented using the publish-subscribe model, the control center acts as the publisher, subscribing all functional controllers to the service state topic. When the state changes, the control center publishes a message, which is received by all subscribers.

[0060] Figure 3 This is the third flowchart illustrating the service availability assurance method provided by the present invention, as follows: Figure 3 The diagram illustrates the service recovery process. Initially, the system is in degraded mode, with each node invoking functions via the CAN network. The CCU continuously probes the availability of the circuit-broken service, sending SOA-level test requests. Once the service provider node can stably respond to SOA requests, the CCU confirms service recovery and broadcasts a "service restored" notification. Upon receiving the broadcast, each node automatically upgrades its invocation strategy from CAN back to SOA and re-initiates service calls via Ethernet. Service calls and responses proceed normally on Ethernet, and the system fully recovers to the optimal SOA communication mode.

[0061] In some embodiments, sending a first status notification and a second status notification to a function controller associated with the target service includes: The first and second status notifications are broadcast to the function controller and cloud server via Ethernet and vehicle-to-cloud network, respectively; the first and second status notifications carry service identifiers, status types and timestamp information.

[0062] Specifically, Ethernet refers to automotive Ethernet, which operates in a star topology within the vehicle domain, connecting nodes such as the central computing unit of the control center, area controllers, intelligent driving domain controllers, intelligent cockpit domain controllers, and communication terminals. This Ethernet carries high-bandwidth, low-latency communication tasks such as SOA service discovery, invocation, and event subscription.

[0063] The vehicle-to-cloud network refers to the wide area network channel accessed by the vehicle-mounted TBOX via a cellular communication module (supporting 4G LTE or 5G NR), used to realize two-way reliable communication between the vehicle and the cloud-based remote diagnostic platform, OTA management server, and cloud service registration center.

[0064] On the Ethernet side, broadcast mode refers to a multicast mechanism based on TSN configuration. The control center encapsulates the first or second status notification into UDP packets, setting the destination IP address to the pre-assigned multicast address for vehicle service status announcements. This ensures propagation is limited to the local vehicle Ethernet segment, avoiding cross-segment flooding. On the vehicle-cloud network side, broadcast mode refers to the control center initiating a one-time publish operation to the cloud service bus via TBOX, targeting all registered subscribers. The cloud message middleware automatically distributes this message to all cloud microservice instances listening to the topic.

[0065] This dual-path broadcast mechanism features heterogeneous collaboration: Ethernet broadcast ensures millisecond-level state synchronization within the vehicle, meeting the functional safety ASIL-B level response requirements; vehicle-to-cloud network broadcast ensures minute-level perception capabilities in the cloud, supporting remote early warning, big data clustering analysis, and proactive service intervention. The two constitute a dual-track state distribution system with strong real-time capability within the vehicle and broad cloud coverage, serving as redundant backups for each other—if the Ethernet connection is partially interrupted, the vehicle-to-cloud network can still upload state changes to the cloud and trigger remote alarms; if cellular signals are lost, in-vehicle broadcast still ensures that critical controllers such as the ZCU and ADC are immediately degraded, without relying on a cloud-based closed loop.

[0066] The first and second status notifications carry a service identifier, status type, and timestamp information. The format of the first status notification is as follows: {Service ID, Status: Unavailable, Timestamp}, and the format of the second status notification is as follows: {Service ID, Status: Available, Timestamp}.

[0067] In other embodiments, after sending a first status notification to the functional controller associated with the target service, the method further includes: periodically sending service probe requests to the target service; and confirming that the target service has been restored to availability when successful responses to the service probe requests are continuously received from the target service.

[0068] Specifically, "periodic" refers to repeatedly performing probe operations at preset time intervals. These intervals can be dynamically configured based on service type, security level, and network load, typically ranging from 100ms to 5s. For example, a high-frequency probe of 200ms can be used for services involving braking control in the autonomous driving domain; a medium-frequency probe of 2s can be used for voice wake-up services in intelligent cockpits. This periodic parameter can be updated online through the configuration management module in the control center, supporting OTA remote deployment. The probe request content must at least carry a unique transaction identifier and a timestamp for subsequent response matching and timeout determination.

[0069] A successful response refers to returning a positive response that conforms to the protocol specifications within a preset timeout window. The response body includes a predefined success status code and verification fields, such as CRC32 checksum and service version number hash digest, to exclude false responses caused by network jitter.

[0070] Here, "continuous reception" refers to receiving a successful response for every probe within a set threshold number of consecutive attempts. This threshold is a configurable integer, typically set to 3, 5, or 7 times. For example, when set to 5 times, the system must receive valid successful responses in all of the most recent 5 probe cycles, with no failures allowed in between (including timeouts, protocol errors, abnormal status codes, or verification failures). This avoids misjudging occasional transient recovery as stable recovery, significantly suppresses oscillations during communication path switching, and prevents functional jitter and resource overhead spikes caused by frequent upgrades and downgrades.

[0071] In this embodiment of the invention, after the target service experiences an unavailable state and triggers a first state notification, a closed-loop assessment of the service's true availability is conducted through an active probing mechanism that is self-initiated, protocol-level verified, and continuously confirmed over multiple cycles.

[0072] In some embodiments, the first communication method is an Ethernet-based SOA service call, and the second communication method is a CAN bus-based signal call.

[0073] Specifically, the first communication method refers to the primary communication path used when the target service is in a normal and available state. Its core is a service-oriented architecture (SOA) service invocation mechanism based on in-vehicle Ethernet. This mechanism achieves cross-domain functional decoupling through standardized service interfaces and supports service discovery, subscription, remote procedure calls, and event notification.

[0074] The second communication method refers to a backup communication path that is automatically activated when the target service becomes unavailable. Its core is a signal-level hardwired function call mechanism based on the CAN bus of the controller area network. This mechanism reuses the CAN physical layer and data link layer already deployed in the vehicle, directly transmitting function control signals or status feedback through predefined CAN identifiers and fixed-length data frames. For example, the "air conditioning temperature setting" service is downgraded to sending 2 bytes of hexadecimal data (0x1E corresponds to 20℃) to CAN ID 0x2A1, or the "brake request" service is downgraded to setting bit 0 to CAN ID 0x3F8. This method does not rely on service discovery and session management, has no protocol stack overhead, and possesses microsecond-level deterministic response and vehicle-wide hardware redundancy, making it suitable for essential safety functions such as emergency braking, lighting control, and door / window locking.

[0075] This method leverages existing heterogeneous networks, Ethernet, and CAN buses, to construct a redundant backup system, achieving resource optimization and cost control. By using the highly reliable CAN network as a backup path for the high-performance Ethernet, a multi-layered protection system is built by fully utilizing existing resources without increasing additional hardware costs, significantly improving the system's cost-effectiveness and engineering feasibility. This design maintains the flexibility of the SOA architecture while reserving space for system expansion through a dynamically configurable switching strategy, providing solid technical support for the continuous evolution of software-defined vehicles.

[0076] Based on the above embodiments, Figure 4 This is the fourth flowchart illustrating the service availability assurance method provided by this invention. The executing entity of this method can be a functional controller, such as the Intelligent Driving Domain Controller (ADC), the Cockpit Domain Controller (CDC), the Zone Controller (ZCU), or a T-Box. Figure 4 As shown, a service availability assurance method is provided, including: Step 410: When the first status notification is received, the communication related to the target service is switched from the first communication method to the second communication method. The service reliability of the second communication method is higher than that of the first communication method. Step 420: When the second status notification is received, switch the communication related to the target service from the second communication method to the first communication method; The first status notification is sent by the control center when it detects that the target service has changed from an available state to an unavailable state, and the second status notification is sent by the control center when it detects that the target service has been restored to an available state.

[0077] It should be noted that the descriptions of the technical features in this embodiment can be referred to the foregoing embodiments, and will not be repeated here.

[0078] In other embodiments, after switching communication related to the target service from the first communication method to the second communication method, or after switching communication related to the target service from the second communication method to the first communication method, the method further includes: Report the current service communication status to the control center.

[0079] Specifically, within a preset time window (e.g., ≤100ms) after completing the aforementioned switching action, each functional controller generates and sends a status feedback message. This message contains at least three core fields: a service identifier (used to uniquely identify the target service being switched), a current communication mode identifier (corresponding to the second and first communication modes respectively), and a reporting timestamp. This feedback message is sent to the control center via unicast over the vehicle's Ethernet network, or it can be synchronously uploaded to the cloud server using the vehicle-cloud network channel, achieving dual-backup status awareness on both the vehicle and cloud sides.

[0080] In some embodiments, Figure 5 This is the fifth flowchart illustrating the service availability assurance method provided by the present invention, as shown below. Figure 5 As shown, a service availability assurance method is provided, including: 1. Start: The system starts up and enters normal operation.

[0081] 2. Normal state interaction: Each functional domain makes service calls and subscriptions on the Ethernet through the SOA service interface.

[0082] 3. CCU Monitoring: The SOA monitoring component in CCU monitors the health of service interfaces in real time, such as response time, error rate, and ECU failures, such as heartbeat loss.

[0083] 4. Fault Detection and Circuit Breaker: If the CCU detects a service failure, it will execute a circuit breaker: The CCU will send a broadcast message within the vehicle and vehicle-cloud network segments to notify all nodes that the service is unavailable. The CCU sends broadcast messages (format: {Service ID, Status: Unavailable, Timestamp}) via Ethernet and the vehicle-cloud network to ensure synchronization between all nodes and the cloud.

[0084] 5. Degradation Processing: Upon receiving the broadcast, each node (such as CDC and ADC) immediately downgrades its service call method from Ethernet SOA to CAN network, sending CAN signals to directly invoke the ECU hardware function. The node parses the broadcast message and switches to a predefined CAN signal mapping table (e.g., Service A → CAN ID 0x100) to implement the function call.

[0085] 6. Recovery Detection and Upgrade: The CCU continues to monitor service availability. When the service recovers, it sends a broadcast message ({Service ID, Status: Available, Timestamp}). Upon receiving the broadcast, each node immediately upgrades its calling method back to the SOA service interface.

[0086] 7. End: The system continues to run, cyclically performing monitoring and switching to achieve dynamic fault tolerance.

[0087] The method provided in this invention ensures that critical functions (such as autonomous driving and cockpit interaction) are unaffected during service failures through automatic circuit breaking and degradation, thereby improving vehicle safety and user experience. The CCU centralized monitoring and broadcast mechanism reduces fault detection and propagation latency, reducing service recovery time from minutes to seconds. Utilizing the existing CAN network as redundancy eliminates the need for additional hardware, reducing system complexity and cost. Based on SOA architecture, the mechanism can be extended to new functional domains or cloud services, supporting the future evolution of software-defined vehicles (SDV). By synchronizing the vehicle's status with the cloud, the reliability of remote diagnostics and OTA (over-the-air) updates is enhanced.

[0088] The service availability assurance device provided by the present invention is described below. The service availability assurance device described below can be referred to in correspondence with the service availability assurance method described above.

[0089] Based on the above embodiments, Figure 6 This is one of the structural schematic diagrams of the service availability assurance device provided by the present invention, such as... Figure 6 As shown, the device includes: Status monitoring unit 610 is used to monitor the availability status of the target service; The first notification sending unit 620 is used to send a first status notification to the function controller related to the target service when it is detected that the target service changes from an available state to an unavailable state, so that the function controller switches the communication related to the target service from a first communication mode to a second communication mode, wherein the service reliability of the second communication mode is higher than that of the first communication mode. The second notification sending unit 630 is used to send a second status notification to the function controller when the target service is detected to be available again, so that the plurality of function controllers switch the communication related to the target service from the second communication mode to the first communication mode.

[0090] Based on the above embodiments, the status monitoring unit is specifically used for: The health status of the target service is monitored in real time through a heartbeat detection mechanism and / or a service registry query method. Based on the health status and the preset health threshold, the availability status of the target service is determined.

[0091] Based on the above embodiments, the first notification sending unit and the second notification sending unit are specifically used for: The first status notification and the second status notification are broadcast to the function controller and the cloud server via Ethernet and vehicle-cloud network, respectively. The first and second status notifications carry service identifiers, status types, and timestamp information.

[0092] Based on the above embodiments, the device further includes a request sending unit, used for: Periodically send service probe requests to the target service; When the target service receives a series of successful responses to the service probe request, it is confirmed that the target service has been restored to availability.

[0093] Based on the above embodiments, Figure 7 This is a second structural schematic diagram of the service availability assurance device provided by the present invention, as shown below. Figure 7 As shown, the device includes: The first switching unit 710 is used to switch the communication related to the target service from the first communication mode to the second communication mode when a first status notification is received, wherein the service reliability of the second communication mode is higher than that of the first communication mode. The second switching unit 720 is used to switch the communication related to the target service from the second communication mode to the first communication mode when a second status notification is received; The first status notification is sent by the control center when it detects that the target service has changed from an available state to an unavailable state, and the second status notification is sent by the control center when it detects that the target service has been restored to an available state.

[0094] Based on the above embodiments, the device further includes a status reporting unit, used for: Report the current service communication status to the control center.

[0095] Based on the above embodiments, Figure 8 This is a schematic diagram of the service availability assurance system provided by the present invention, as shown below. Figure 8 As shown, the system includes: Control center 810 is used to monitor the availability status of the target service. When the target service is detected to change from an available status to an unavailable status, a first status notification is sent to the functional controller related to the target service. The function controller 820 is used to receive the first status notification and switch the communication related to the target service from the first communication mode to the second communication mode, wherein the service reliability of the second communication mode is higher than that of the first communication mode. The control center 810 is also used to send a second status notification to the function controller when it detects that the target service has been restored to availability; The function controller 820 is also configured to receive the second status notification and switch the communication related to the target service from the second communication mode to the first communication mode.

[0096] The service availability assurance system provided in this invention continuously monitors the availability status of target services and combines this with an automatic failover mechanism when services are unavailable, fundamentally ensuring the continuity of system functions. The combination of centralized monitoring and broadcast notification mechanisms enables real-time fault response and rapid business recovery.

[0097] Figure 9 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 9As shown, the electronic device may include a processor 910, a communications interface 920, a memory 930, and a communication bus 940, wherein the processor 910, communications interface 920, and memory 930 communicate with each other via the communication bus 940. The processor 910 can invoke logical instructions in the memory 930 to execute a service availability assurance method, which includes: monitoring the availability status of a target service; when the target service is detected to change from an available state to an unavailable state, sending a first status notification to a functional controller associated with the target service, causing the functional controller to switch communication related to the target service from a first communication mode to a second communication mode, wherein the service reliability of the second communication mode is higher than that of the first communication mode; and when the target service is detected to have recovered to an available state, sending a second status notification to the functional controller, causing the multiple functional controllers to switch communication related to the target service from the second communication mode back to the first communication mode. Alternatively, upon receiving a first status notification, communication related to the target service is switched from a first communication method to a second communication method, where the service reliability of the second communication method is higher than that of the first communication method; upon receiving a second status notification, communication related to the target service is switched from the second communication method back to the first communication method; wherein, the first status notification is sent by the control center when it detects that the target service has changed from an available state to an unavailable state, and the second status notification is sent by the control center when it detects that the target service has been restored to an available state.

[0098] Furthermore, the logical instructions in the aforementioned memory 930 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a 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 the present invention. 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.

[0099] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can perform the service availability assurance method provided by the above methods. The method includes: monitoring the availability status of a target service; when the target service is detected to change from an available state to an unavailable state, sending a first status notification to a functional controller associated with the target service, so that the functional controller switches the communication associated with the target service from a first communication mode to a second communication mode, wherein the service reliability of the second communication mode is higher than that of the first communication mode; when the target service is detected to have recovered to an available state, sending a second status notification to the functional controller, so that the plurality of functional controllers switch the communication associated with the target service from the second communication mode to the first communication mode. Alternatively, upon receiving a first status notification, communication related to the target service is switched from a first communication method to a second communication method, where the service reliability of the second communication method is higher than that of the first communication method; upon receiving a second status notification, communication related to the target service is switched from the second communication method back to the first communication method; wherein, the first status notification is sent by the control center when it detects that the target service has changed from an available state to an unavailable state, and the second status notification is sent by the control center when it detects that the target service has been restored to an available state.

[0100] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements a service availability assurance method provided by the methods described above. The method includes: monitoring the availability status of a target service; when the target service is detected to change from an available state to an unavailable state, sending a first status notification to a functional controller associated with the target service, causing the functional controller to switch communication related to the target service from a first communication mode to a second communication mode, wherein the service reliability of the second communication mode is higher than that of the first communication mode; and when the target service is detected to have recovered to an available state, sending a second status notification to the functional controller, causing the plurality of functional controllers to switch communication related to the target service from the second communication mode to the first communication mode. Alternatively, upon receiving a first status notification, communication related to the target service is switched from a first communication method to a second communication method, where the service reliability of the second communication method is higher than that of the first communication method; upon receiving a second status notification, communication related to the target service is switched from the second communication method back to the first communication method; wherein, the first status notification is sent by the control center when it detects that the target service has changed from an available state to an unavailable state, and the second status notification is sent by the control center when it detects that the target service has been restored to an available state.

[0101] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0102] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, 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 computer-readable 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, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0103] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention 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; and these 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 the present invention.

Claims

1. A service availability assurance method, characterized in that, include: Monitor the availability status of the target service; When the target service is detected to change from an available state to an unavailable state, a first state notification is sent to the function controller associated with the target service, so that the function controller switches the communication associated with the target service from a first communication mode to a second communication mode, wherein the service reliability of the second communication mode is higher than that of the first communication mode; When the target service is detected to be available again, a second status notification is sent to the function controller so that the multiple function controllers switch the communication related to the target service from the second communication mode to the first communication mode.

2. The service availability assurance method according to claim 1, characterized in that, The availability status of the monitored target service includes: The health status of the target service is monitored in real time through a heartbeat detection mechanism and / or a service registry query method. Based on the health status and the preset health threshold, the availability status of the target service is determined.

3. The service availability assurance method according to claim 2, characterized in that, Sending a first status notification and a second status notification to the function controller associated with the target service, including: The first status notification and the second status notification are broadcast to the function controller and the cloud server via Ethernet and vehicle-cloud network, respectively. The first and second status notifications carry service identifiers, status types, and timestamp information.

4. The service availability assurance method according to claim 1, characterized in that, After sending the first status notification to the function controller associated with the target service, the method further includes: Periodically send service probe requests to the target service; When the target service receives a series of successful responses to the service probe request, it is confirmed that the target service has been restored to availability.

5. The service availability assurance method according to any one of claims 1 to 4, characterized in that, The first communication method is an Ethernet-based SOA service call, and the second communication method is a CAN bus-based signal call.

6. A service availability assurance method, characterized in that, include: When a first status notification is received, communication related to the target service will be switched from the first communication method to the second communication method, where the service reliability of the second communication method is higher than that of the first communication method. When a second status notification is received, communication related to the target service will be switched from the second communication method to the first communication method. The first status notification is sent by the control center when it detects that the target service has changed from an available state to an unavailable state, and the second status notification is sent by the control center when it detects that the target service has been restored to an available state.

7. The service availability assurance method according to claim 6, characterized in that, After switching the communication related to the target service from the first communication method to the second communication method, or after switching the communication related to the target service from the second communication method to the first communication method, the method further includes: Report the current service communication status to the control center.

8. A service availability assurance device, characterized in that, include: The status monitoring unit is used to monitor the availability status of the target service; The first notification sending unit is used to send a first status notification to the function controller related to the target service when it is detected that the target service changes from an available state to an unavailable state, so that the function controller switches the communication related to the target service from a first communication mode to a second communication mode, wherein the service reliability of the second communication mode is higher than that of the first communication mode. The second notification sending unit is used to send a second status notification to the function controller when the target service is detected to be available again, so that the plurality of function controllers switch the communication related to the target service from the second communication mode to the first communication mode.

9. A service availability assurance device, characterized in that, include: The first switching unit is used to switch the communication related to the target service from the first communication mode to the second communication mode when a first status notification is received, wherein the service reliability of the second communication mode is higher than that of the first communication mode. The second switching unit is used to switch the communication related to the target service from the second communication method to the first communication method when a second status notification is received. The first status notification is sent by the control center when it detects that the target service has changed from an available state to an unavailable state, and the second status notification is sent by the control center when it detects that the target service has been restored to an available state.

10. A service availability assurance system, characterized in that, include: The control center is used to monitor the availability status of the target service. When the target service is detected to change from an available state to an unavailable state, a first status notification is sent to the functional controllers associated with the target service. The function controller is configured to receive the first status notification and switch the communication related to the target service from the first communication mode to the second communication mode, wherein the service reliability of the second communication mode is higher than that of the first communication mode. The control center is also used to send a second status notification to the function controller when it detects that the target service has been restored to availability; The function controller is further configured to receive the second status notification and switch communication related to the target service from the second communication mode to the first communication mode.

Images