Automatic driving system retirement control method, electronic device, and vehicle

Abstract

The present disclosure provides a kind of automatic driving system retirement control method, electronic equipment and vehicle, it is related to intelligent driving technical field.The method comprises: obtaining the vehicle state information capable of reflecting the performance of automatic driving system, the vehicle state information includes the report information of vehicle execution component, the real-time information of the endurance parameter of vehicle execution component and the actual response information of automatic driving system to travel control information;According to the vehicle state information, the life consumption information of automatic driving system is determined;According to the life consumption information, it is judged whether the life of the automatic driving system is exhausted, and when the result of judgment is life exhausted, the automatic driving system is retired, and the present disclosure is used to realize the retirement control of automatic driving system.

Description

Technical Field

[0001] This disclosure relates to the field of intelligent driving technology, specifically to a method for retiring an autonomous driving system, electronic equipment, and a vehicle. Background Technology

[0002] In the field of safety monitoring for autonomous driving systems, the implementation of relevant national standards explicitly requires monitoring the continuous operational capability of vehicles equipped with autonomous driving systems and establishing management mechanisms to ensure timely system retirement. Since autonomous driving systems replace drivers, the aforementioned technical approaches are insufficient to effectively cover the gradual performance degradation and potential anomalies of vehicle mechanical or actuator components that were previously detectable only through driver senses (such as touch and hearing), such as minor sticking in the steering mechanism or abnormal noises from worn brake pads. Furthermore, for the lifespan assessment of actuators, related technologies typically employ simple models strongly tied to mileage or usage time, failing to accurately reflect the actual wear and tear of components directly related to specific operating frequencies and load intensity (such as electronic parking brakes and anti-lock braking system valve bodies). Therefore, a technical solution capable of real-time or near-real-time monitoring of the lifespan of autonomous driving systems is needed to ensure their timely retirement. Summary of the Invention

[0003] In view of this, the present invention provides a method for controlling the decommissioning of an autonomous driving system, an electronic device, and a vehicle to achieve decommissioning control of the autonomous driving system.

[0004] Firstly, this disclosure provides a method for decommissioning an autonomous driving system, including:

[0005] Acquire vehicle status information that reflects the performance of the autonomous driving system. The vehicle status information includes the reported information of the vehicle's actuators, the real-time information of the durability parameters of the vehicle's actuators, and the actual response information of the autonomous driving system to driving control information.

[0006] Based on the vehicle status information, determine the lifespan loss information of the autonomous driving system;

[0007] Based on the lifespan loss information, it is determined whether the lifespan of the autonomous driving system has been exhausted, and when the determination result is that the lifespan has been exhausted, the autonomous driving system is controlled to be decommissioned.

[0008] Secondly, this disclosure provides an electronic device, including:

[0009] At least one processor; and

[0010] A memory communicatively connected to the at least one processor; wherein,

[0011] The memory stores at least one computer program that can be executed by the at least one processor, the at least one computer program being executed by the at least one processor to enable the at least one processor to perform the autonomous driving system decommissioning control method as described in the first aspect.

[0012] Thirdly, this disclosure provides a vehicle including an autonomous driving domain controller configured to perform the autonomous driving system decommissioning control method described in the first aspect.

[0013] The embodiments provided in this disclosure acquire multi-dimensional vehicle status information from vehicle actuators, real-time durability parameters, and actual system response information, and determine lifespan depletion information accordingly to control vehicle retirement. This solution integrates status assessments from different technological sources to construct a comprehensive vehicle health profile, covering the determination of both immediate faults and progressive lifespan depletion. This enables proactive monitoring and safety management of the autonomous driving system's status in unattended environments. This not only effectively overcomes the limitations of traditional reliance on driver experience but also improves the safety and reliability of vehicle operation through pre-assessment of lifespan, avoiding major safety hazards. Attached Figure Description

[0014] To more clearly illustrate the technical solutions in the embodiments of this disclosure 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 only embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0015] Figure 1 The diagram shown is an architectural schematic of the autonomous driving system in an embodiment of this disclosure.

[0016] Figure 2 The diagram shown is a schematic flowchart of the decommissioning control method for an autonomous driving system in an embodiment of this disclosure.

[0017] Figure 3 The diagram shown is a flowchart illustrating the control process of the autonomous driving system in an embodiment of this disclosure.

[0018] Figure 4 The diagram shown is a structural schematic of an electronic device in an embodiment of this disclosure. Detailed Implementation

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

[0020] Where there is no conflict, the various embodiments of this disclosure and the features thereof in the embodiments may be combined with each other.

[0021] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0022] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Words such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0023] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined herein.

[0024] In the field of autonomous driving technology, especially for fully driverless vehicles at Level 4 and above, the common practice to monitor the continuous health status of vehicles and reliably trigger system retirement before safety redundancy is exhausted, thus meeting relevant safety regulations, is to rely on on-board diagnostic systems. Specifically, this approach involves each electronic control unit (ECU) periodically performing self-checks and reporting fault codes conforming to standard protocols. Its basic working principle is that sensors monitor electrical parameters such as voltage, current, resistance, and signal frequency, and the controller compares these parameters to preset normal ranges to determine if components have open circuits, short circuits, or signal over-limit faults. Its widespread application stems primarily from its ability to quickly and systematically detect and locate electronic and electrical faults, providing clear guidance for maintenance.

[0025] However, when this solution is applied to fully autonomous driving scenarios where the system needs to comprehensively assess the overall mechanical health and remaining lifespan of the vehicle, much like a human driver, its performance is less than ideal. A fundamental contradiction lies in the fact that, in order to optimize its diagnostic efficiency and reliability for standard electronic and electrical faults, the inherent design of this solution inevitably impairs its ability to perceive non-electrical characteristics such as mechanical wear, gradual performance changes, and cross-system coupling anomalies, even leading to misjudgments of the vehicle's true health status. Specifically, in the daily operation of autonomous taxis, phenomena such as temporary braking force loss due to high temperatures in brake pads, slight sticking in the steering mechanism due to insufficient lubrication, or decreased linear adjustment accuracy of the brake valve body due to long-term use—phenomena that drivers could normally detect through touch, hearing, or experience—are difficult for a purely electronic diagnostic system to effectively capture. Furthermore, for components not strongly correlated with mileage, such as the frequently used electronic parking brake system, total mileage or time alone cannot accurately assess its remaining lifespan, resulting in the inability to provide early warnings and orderly retirement before substantial performance degradation.

[0026] Through in-depth analysis, the inventors discovered that the root causes of the aforementioned contradictions are multifaceted: From a perception perspective, the relevant technical solutions lack a comprehensive judgment mechanism that can replace the multi-sensory fusion of human drivers. Their information sources are limited to the electrical signals of the components themselves, failing to acquire deep states such as "deviations between planning and execution" and "cumulative wear and tear over long periods," which require cross-domain calculations or model inference. From an evaluation perspective, diagnosis addresses immediate, sudden fault events, while lifespan assessment addresses gradual, cumulative performance degradation. The relevant technical solutions separate these two aspects, lacking a unified framework to integrate immediate anomalies and gradual wear and tear to form a complete picture of the overall health of the autonomous driving system. From a decision-making and execution perspective, the outputs of the relevant technical solutions are usually isolated fault codes or simple binary states, failing to form a mandatory closed-loop mapping with different levels of degraded control strategies that allow the vehicle to continue operating for a limited time. This results in the system lacking the layered handling capabilities of human drivers when facing complex states. These factors collectively limit the ability of existing solutions to address the continuous health monitoring and proactive retirement requirements of high-level autonomous vehicles.

[0027] To overcome the aforementioned contradictions, this disclosure proposes a retirement control method for an autonomous driving system. Its core concept lies in introducing a comprehensive evaluation system that integrates vehicle state information from three independent yet complementary dimensions: direct reporting from vehicle actuators, cross-validation from the autonomous driving domain controller, and prediction based on a durability model. This improves the health status and lifespan depletion determination process of the autonomous driving system, thereby effectively enhancing the perception and evaluation capabilities for gradual changes in mechanical performance, cross-system anomalies, and component lifespan depletion without sacrificing the rapid response capability to traditional electrical faults. It also avoids hidden risks caused by a single evaluation dimension or a disconnect between decision-making and execution. In other words, it provides a multi-dimensional information fusion and hierarchical control linkage technique to address the problem of not being able to proactively and comprehensively evaluate the overall health status of the system and safely trigger retirement under autonomous driving conditions. This achieves the technical effect of automated, refined management of vehicle health status and orderly retirement control without driver intervention.

[0028] First, combine Figure 1 Describe a typical implementation environment. Figure 1 This is a schematic diagram of the architecture of an autonomous driving system according to an embodiment of the present disclosure. The system mainly includes an autonomous driving domain controller, multiple actuator controllers related to vehicle control, a perception sensor network, and a human-machine interface. The autonomous driving domain controller, as the core decision-making unit, is connected to actuator controllers such as the braking system controller, steering system controller, electronic parking brake controller, and drive motor controller via an onboard bus network, enabling bidirectional communication for issuing control commands and reporting status information. Simultaneously, the autonomous driving domain controller receives data from perception sensors such as cameras, lidar, and millimeter-wave radar, as well as data from vehicle motion sensors such as wheel speed sensors and inertial measurement units. The human-machine interface can be used to provide status prompts to a remote monitoring center or vehicle passengers. In this environment, the autonomous driving domain controller is configured to execute the following vehicle health status assessment and decommissioning control process: it obtains local diagnostic information reported by each actuator controller through the bus network, processes perception and planning data using its own algorithms to generate system-level verification information, and calls an internally stored durability model to calculate the cumulative consumption of specific components, ultimately fusing this multi-source information to make a comprehensive decision.

[0029] In this application, "vehicle status information" refers to any set of data that can reflect the current performance and health status of the autonomous driving system and its actuators. This data can originate from messages on the vehicle bus, calculations within the controller, or pre-stored data models. For example, it can include codes representing transient faults, numerical values ​​representing performance deviations, or counts representing cumulative consumption. "Lifespan depletion information" refers to a processed indicator or status description used to quantify the remaining availability of the autonomous driving system as a whole or its key components. This can be a specific percentage value, a rating label, or a Boolean flag. For example, it can be represented as "System health 85%", "Lifespan level: Warning", or "Lifespan exhaustion flag: True". "Retirement" refers to the process of limiting or ceasing the use of the autonomous driving system's functions. This can include a gradual degradation of functional performance until complete disabling, rather than simply physical scrapping. For example, it can be represented by prohibiting the activation of new autonomous driving trips, limiting vehicle speed or operating area, or locking the system after completing the current trip.

[0030] Figure 2 The diagram shown is a schematic flowchart of an autonomous driving system decommissioning control method according to an embodiment of the present disclosure. This method can be executed by the autonomous driving domain controller on the vehicle, or by other electronic devices or servers capable of communicating with the various domain controllers of the vehicle. The method includes the following:

[0031] Step S210: Obtain vehicle status information that reflects the performance of the autonomous driving system. The vehicle status information includes the reported information of the vehicle's actuators, the real-time information of the durability parameters of the vehicle's actuators, and the actual response information of the autonomous driving system to the driving control information.

[0032] This step aims to collect raw data from multiple complementary technical dimensions for assessing system health and lifespan. Reported information from vehicle actuators comes directly from internal diagnostic functions of components such as brake controllers and steering controllers, reflecting the immediate status monitored by the components' own sensors. Real-time information on the durability parameters of vehicle actuators focuses on recording cumulative quantities related to performance degradation that occur during long-term use, such as the number of cycles, force, or torque integrals. The actual response information of the autonomous driving system to driving control information comes from the domain controller, which compares the "expected" and "actual" system-level performance to identify coupling or systemic deviations that cannot be captured by the self-diagnosis of individual components. These three types of information together constitute a three-dimensional, point-to-surface integrated health perception network.

[0033] In a specific example, during each planned control cycle, the autonomous driving domain controller, in addition to sending control commands to the actuators, also listens to the bus in parallel. For instance, it parses information such as the actual feedback value of brake pressure and brake pad overheat warning signs from messages reported by the brake controller; simultaneously, it reads the cumulative value of the current electronic parking brake execution count from internally maintained variables; furthermore, it calls a trajectory deviation calculation module to output the lateral deviation of the current vehicle's actual position from the planned path. Understandably, the specific content and update frequency of vehicle status information can be adjusted according to system design requirements. For example, durability parameters can be summarized once per kilometer or per ignition cycle, while emergency fault reporting information is transmitted in real time using event triggering.

[0034] In this embodiment of the disclosure, vehicle actuators refer to any mechanism or controller that receives control commands and performs physical actions during autonomous driving. This can refer to the entire actuator assembly or a key sub-component within it. Specifically, it can refer to the hydraulic adjustment unit of the braking system, the motor and gear mechanism of the steering system, the clamping motor of the electronic parking brake system, etc. Driving control information refers to the set of commands generated by the autonomous driving system that are intended to cause the vehicle to produce specific movements, such as target steering angle, target deceleration, target gear, etc.

[0035] Step S220: Determine the lifespan loss information of the autonomous driving system based on the vehicle status information.

[0036] This step involves fusing and evaluating the collected multi-dimensional raw information to generate a comprehensive judgment on the overall lifespan depletion of the system. Through specific algorithms or rules, multi-dimensional vehicle status information is mapped to a unified metric that characterizes the system's remaining availability. For example, a sudden emergency mechanical failure may cause a sharp deterioration in lifespan depletion information, while the gradual depletion of durability parameters of multiple components accumulating to a threshold can also cause lifespan depletion information to reach a critical point of "exhaustion."

[0037] As a specific implementation, this determination step can be broken down into several parallel sub-information generation steps and a final fusion step. For example, firstly, a first type of loss information is generated based on information reported by the execution component; secondly, a second type of loss information is generated based on durability parameters; and thirdly, a third type of loss information is generated based on actual response information. Then, these three types of information are combined to determine the final lifetime loss information. This approach enables modular processing and allows for the use of different evaluation models for losses in different dimensions, improving the flexibility and accuracy of the method.

[0038] More generally, lifetime loss information can be determined in various ways. For example, it can include, but is not limited to: using a weighted fusion algorithm to assign weights to the three types of information or their derived sub-loss information and sum them; using a rule-based expert system to define a series of rules to determine lifetime status based on a combination of input information; or using a machine learning model trained on historical data to directly output a lifetime loss assessment. All these approaches can achieve the function of deriving a comprehensive assessment result from heterogeneous, multi-source information.

[0039] In a specific example, the domain controller's life assessment module maintains a system health score, initially set at 100%. When a routine mechanical maintenance fault is reported, 5 points are deducted according to preset rules; when the accumulated brake pressure integral value reaches 80% of the threshold, 15 points are deducted according to a preset curve; when a path lateral tracking deviation consistently exceeds 50 cm, 10 points are deducted. The module calculates the current health score in real time and uses it as a representation of lifespan depletion information. It is understandable that the specific algorithm used for fusion is not limited to simple point deduction; it can also be a multi-factor fuzzy evaluation or state machine transition. The health score can also be replaced with discrete levels, such as "Healthy," "Attention," "Warning," and "Critical."

[0040] Step S230: Determine whether the lifespan of the autonomous driving system has been exhausted based on the lifespan loss information, and control the autonomous driving system to retire when the determination result is that the lifespan has been exhausted.

[0041] Determining whether the vehicle's lifespan has been exhausted can be achieved by comparing the lifespan depletion information generated in step S220 with a preset threshold or condition. Once lifespan is determined to be exhausted, an orderly retirement control process needs to be initiated, rather than immediately and abruptly stopping all functions, to ensure that the vehicle can safely transition to a non-autonomous driving state or undergo maintenance.

[0042] As a specific implementation method, the judgment and decommissioning control can be carried out by first issuing a lifespan expiration reminder, and then initiating and executing a preset decommissioning control process. This approach provides operators or maintenance systems with the necessary early warning and response time, complying with safe operating procedures.

[0043] More generally, the retirement of an autonomous driving system can be achieved in a variety of ways. These may include, but are not limited to: immediately prohibiting the initiation of new autonomous driving trips while allowing the completion of the current trip; limiting the maximum speed and available area in autonomous driving mode; or gradually reducing the control authority of the autonomous driving system, ultimately switching to manual takeover or a minimum risk strategy mode. These approaches all achieve the overarching function of stopping or limiting the functionality of the autonomous driving system.

[0044] In a specific example, when the system health score falls below 20, the lifespan assessment module determines that the system's lifespan has expired. First, it sends a "Lifespan expired, please arrange maintenance" reminder to the remote monitoring center via the vehicle communication module and displays a similar message on the vehicle's screen. Simultaneously, it activates a retirement control process that allows the vehicle to continue in autonomous driving mode for up to 10 preset short-distance shuttle missions (e.g., returning to the operations center from the current location). After this, the autonomous driving domain controller automatically disables the power-on activation permission for the autonomous driving function, and the vehicle can only be driven manually. It is understandable that the allowed number of runs before retirement can be fixed or dynamically calculated, for example, by estimating a safety margin based on the remaining health score.

[0045] It should be noted that the multi-dimensional information obtained in step S210 provides an indispensable data foundation for the accurate and comprehensive lifespan loss assessment in step S220. The comprehensive assessment result obtained in step S220, in turn, serves as the direct basis for making a reasonable retirement decision in step S230. The synergy of these three elements enables the system to comprehensively consider both immediate anomalies and long-term losses, making a series of decisions ranging from early warning and degraded operation to final functional exit. This collectively solves the technical problem of lacking comprehensive perception and forward-looking retirement control capabilities for vehicle health status under autonomous driving conditions.

[0046] To further optimize the handling process after the lifespan of the above embodiments and improve safety and user predictability, this application also provides the following solution.

[0047] As mentioned earlier, controlling the retirement of an autonomous driving system can include specific steps. In a preferred embodiment, when the determination result indicates that the autonomous driving system's lifespan has expired due to damage information, a lifespan expiration reminder is issued, and the retirement control process is initiated. This limitation aims to divide the retirement process into two distinct phases: "early warning" and "execution." The initial reminder creates conditions for external intervention (such as remote dispatch or personnel takeover), followed by a pre-defined retirement control process. This ensures that even without timely external intervention, the system can automatically and safely execute the retirement process according to a predetermined procedure, avoiding the risk of an unresolved state. The reminder mechanism adds a safety buffer to the system, providing a window for fault mitigation or maintenance arrangements; while the structured retirement process ensures the standardization and consistency of the final execution action, preventing arbitrary or dangerous handling. It is understood that alternative sequences or combinations of steps to achieve the same purpose include: first entering a restrictive operating mode as a reminder, then completely disabling the system after the conditions are triggered again; or synchronizing the reminder with the retirement process (such as restricting functions).

[0048] Specifically, end-of-life warnings can be implemented through various human-machine interfaces. For example, the autonomous driving domain controller can send commands to the instrument cluster or central control screen via the vehicle network to display specific icons and text messages, such as "Autonomous driving system lifespan is about to expire, please contact service." Simultaneously, it can also send a warning message containing the vehicle identifier and end-of-life status to the cloud-based fleet management platform via the onboard telematics unit. Entering the retirement control process can be initiated by setting an internal status flag, triggering the execution of a series of subsequent sub-steps.

[0049] By adopting the aforementioned "warning before execution" process, a clear distinction can be made between status notification and action execution, making the entire decommissioning process more in line with the basic principles of human-computer interaction and safety management. This further helps to address the safety issues that may arise from sudden system failures or unpredictable behavior, thereby synergistically strengthening the core technical effects of the invention's multi-dimensional assessment and graded safety control.

[0050] Furthermore, the content and form of the reminder are not limited to text; they may also include voice prompts, flashing indicator lights, or push notifications linked to a mobile application. The triggering condition for "entering the retirement control process" can be related to the lifespan reaching its limit, or it may be linked to the time of no response after the reminder. For example, if no maintenance confirmation is received within 24 hours of issuing the reminder, the retirement process will be automatically initiated.

[0051] To provide a specific, safe, and usability-balanced implementation scheme for the retirement control process, this application also provides the following further solutions. As mentioned above, the retirement control process can have various connotations. In one specific implementation, the retirement control process includes disabling the autonomous driving system after a limited number of applications. In this solution, this specific limitation defines the core method of retirement execution: instead of immediately stripping the function, the system is allowed to perform a limited number of autonomous driving tasks in a "lifespan exhausted" state before being completely disabled. This design allows the system to retain a certain degree of maneuverability after the lifespan exhaustion criterion is triggered. Its advantage lies in providing the possibility for the vehicle to autonomously complete the current task, safely arrive at the repair point, or return to the base, avoiding the secondary risks of the vehicle breaking down in complex or dangerous traffic environments due to immediate disabling, and significantly improving practicality and safety. It is understood that alternative technical means to achieve the "disabling after a limited number of applications" logic also include: limiting the remaining total mileage, limiting the remaining total operating time, or limiting the geofenced area for operation.

[0052] Specifically, the limited number of applications can be based on a preset fixed number of times. For example, after the autonomous driving domain controller determines that its lifespan has expired and enters the retirement process, it initializes a counter with an initial value of N (e.g., N=5). Then, each successful completion of an autonomous driving trip (from start-up to shutdown) decrements the counter by 1. When the counter reaches zero, the domain controller performs a disabling operation, such as locking the autonomous driving function enable signal, preventing it from entering autonomous driving mode upon the next power-on. Furthermore, the limited number of applications N can also be a configurable parameter, dynamically adjusted based on vehicle type, operating strategy, or severity of wear and tear.

[0053] By employing the aforementioned method of disabling after limited applications, this solution provides a deterministic buffer period before final disabling, making the retirement process predictable and planned. This further helps to address the risks of vehicle congestion and operational disruptions caused by immediate disabling, thereby synergistically achieving the technical effect of maximizing the remaining value and ease of use of vehicles while ensuring a safety baseline.

[0054] Furthermore, the determination of the "limited number of times" is not limited to a fixed number of times. For example, different numbers of times can be obtained linearly or by looking up a table based on the severity of the current lifespan depletion determination (such as health score); alternatively, it can be associated with the vehicle's current geographical location and the location of a preset repair point to dynamically calculate an estimated number of trips that can safely reach the destination. The disabled operation is not necessarily permanent; the function can be restored after authorized maintenance and a reset of the lifespan status.

[0055] To further clarify how to comprehensively determine lifetime loss from multi-dimensional information, this application also provides the following detailed implementation scheme for step S220.

[0056] As mentioned above, determining lifespan loss information based on vehicle status information can take many forms. In a preferred embodiment, it specifically includes: generating a first type of loss information based on reported information from vehicle actuators; generating a second type of loss information based on real-time information of durability parameters of vehicle actuators; generating a third type of loss information based on the actual response information of the autonomous driving system to driving control information; and determining the lifespan loss information of the autonomous driving system based on the first type of loss information, the second type of loss information, and the third type of loss information.

[0057] In this scheme, this constraint structures the comprehensive evaluation process into three parallel information flow processing channels and a central fusion node. The first type of loss information focuses on immediate failures actively reported by components; the second type focuses on incremental consumption based on models and historical data; and the third type focuses on deviations in the overall system performance. Finally, the fusion is performed to determine the overall health cues, reflecting a holistic consideration of health cues at different levels: point, line, and surface.

[0058] This design makes the life assessment model clearer and more modular. Its advantage lies in allowing the most suitable independent algorithms to be used to process the three different types of information (e.g., fault classification, integral accumulation, and deviation statistical analysis), improving the accuracy of each assessment; while the subsequent fusion ensures the comprehensiveness of the final conclusion, avoiding misjudgments based on a single dimension. Understandably, the generation of the three types of loss information is logically parallel, but in actual software implementation, it can be executed sequentially or processed by tasks of different priorities.

[0059] For example, the first type of loss information generation module continuously monitors fault messages. Once a specific fault code is parsed, it outputs a weighted value representing the degree of impact of the fault on the system's lifespan (e.g., 1.0 for emergency faults and 0.3 for regular faults) based on a preset mapping table. The second type of loss information generation module periodically reads data from the EPB action counter, brake pressure integrator, etc., and outputs a component-level percentage of remaining lifespan by comparing it with a built-in threshold curve. The third type of loss information generation module calculates the root mean square value of the path tracking error in real time. When this value exceeds a threshold, it outputs a system performance degradation coefficient. The fusion determination module receives these three outputs and may use a weighted formula (e.g., total loss = W1 first type of impact + W2(1 - second type of lifespan percentage) + W3). The third type of attenuation coefficient is used to calculate the final system lifetime loss information. It is understandable that the fusion algorithm is not limited to weighted summation; it can also be a more complex multi-input inference engine.

[0060] By employing an architecture that generates and fuses the three types of information in parallel, this solution can systematically organize and synthesize heterogeneous vehicle status information from different dimensions to form a unified lifespan loss assessment. This further helps to solve the problem of how to uniformly quantify and assess multiple factors such as faults, aging, and performance deviations, thereby synergistically enhancing the overall technical effect of this invention in constructing a comprehensive and reliable system health profile.

[0061] Furthermore, it is not necessary for all three types of loss information to be present; in some simplified embodiments, only two types may be included. During fusion, a rule-based arbitration mechanism can also be used. For example, if an emergency fault occurs in the first type of information, regardless of other information, it can be directly determined that the lifetime loss has reached its limit.

[0062] To further specify the generation logic of the first type of loss information, enabling it to cover various faults originally perceived by the driver and achieve differentiated processing, this application also provides the following further implementation scheme.

[0063] As mentioned above, generating the first type of wear information based on the reported information from the vehicle's actuators can have several specific meanings. In one specific implementation, this step includes: generating performance loss fault information when performance loss is detected in the vehicle's actuator based on the reported information, wherein the performance loss fault is a non-emergency fault; generating routine mechanical maintenance fault information when a mechanical abnormality is detected in the vehicle's actuator based on the reported information and it is currently capable of supporting limp driving, wherein the routine mechanical maintenance fault is a non-emergency fault; and generating emergency mechanical fault information when a mechanical abnormality is detected in the vehicle's actuator based on the reported information and an emergency stop is required, wherein the emergency mechanical fault is an emergency fault. The first type of wear information includes at least one of the performance loss fault, the routine mechanical maintenance fault, and the emergency mechanical fault.

[0064] In this scheme, this limitation provides a refined classification model for faults reported by the actuators. Performance loss faults (such as brake fade due to overheating) are typically temporary and environment-related; routine mechanical maintenance faults (such as friction pad wear to the limit) are progressive and repairable, but the vehicle still retains basic driving capability; emergency mechanical faults (such as steering column jamming or tire blowout) are sudden and dangerous, requiring immediate evasive action. This classification directly relates to different subsequent handling strategies and forms the basis of hierarchical control.

[0065] This design enables the system to differentiate between the nature and urgency of faults, thereby making differentiated responses consistent with human driver experience. Its advantage lies in avoiding overreactions (such as emergency stops for any fault) or underreactions (such as attempting limp driving even for an emergency fault) that result from treating all faults the same, greatly improving the safety and rationality of the system in handling complex fault states. Understandably, the fault category determination logic is embedded in the diagnostic software of the component controller or domain controller, typically based on comparisons of sensor readings with multi-level thresholds or on feature model identification.

[0066] Specifically, fault detection and classification are completed at the information source or during initial processing. For example, the algorithm inside the brake controller continuously estimates the brake pad temperature. When the temperature exceeds a first threshold (e.g., 300°C), a fault code for "brake performance thermal fade" is generated, which belongs to the performance loss category. When the estimation model determines that the brake pad thickness is below the maintenance threshold, a fault code for "brake pad wear requiring replacement" is generated, which belongs to the routine mechanical maintenance category. The steering controller monitors motor current and steering angle feedback. If it detects an abnormal increase in torque without a change in steering angle, which matches the "sticking" characteristic model, a fault code for "steering mechanism sticking" is generated, which belongs to the emergency mechanical category. These fault codes with category attributes are reported via the bus, thus constituting the source of the first type of wear information. It is understandable that the classification of fault categories and specific detection thresholds can be calibrated and adjusted according to different vehicle models and components.

[0067] By adopting the three-level classification scheme for faults reported by the actuators described above, this scheme can specifically define and handle faults of different severity levels, providing precise input for subsequent matching of differentiated control strategies. This further helps to solve the problem of how autonomous driving systems can simulate drivers to take different measures for faults of different natures, thereby synergistically achieving the technical effects of refined fault response and graded management of safety risks.

[0068] Furthermore, the fault categories are not limited to the three mentioned above and can be further subdivided. The generated information is not limited to the fault code itself, but can also include the fault confidence level, occurrence time, relevant parameter snapshots, etc., to allow the fusion module to more accurately assess its impact.

[0069] To further specify the generation logic of the second type of loss information, and especially to provide a quantitative life assessment method for components that are not strongly correlated with mileage, this application also provides the following further implementation scheme.

[0070] As mentioned above, generating the second type of wear information based on real-time durability parameters of vehicle actuators can have various specific meanings. In one specific implementation, this step includes: the real-time durability parameters including real-time mileage and real-time driving environment; determining the lifespan wear of the vehicle actuators based on the real-time mileage and driving environment, using the maximum mileage under different driving environments in the durability test data; the real-time durability parameters including the driving duration of each trip and the driving environment of each trip; determining the lifespan wear of the vehicle actuators based on the driving duration of each trip and the driving environment of each trip, using the maximum driving duration under different driving environments in the durability test data; the real-time durability parameters including the cumulative number of triggers; determining the lifespan wear of the vehicle actuators based on the cumulative number of triggers, using the maximum number of triggers in the durability test data.

[0071] In this scheme, this limitation clarifies several core calculation models for generating the second type of wear information. The first is based on mileage and environment, applicable to components such as tires and chassis bushings whose wear is strongly correlated with mileage and greatly affected by road conditions. The second is based on time and environment, applicable to certain components that also experience wear under specific conditions such as idling and high temperatures. The third is based on the number of actuations, applicable to components such as electronic parking brakes and anti-lock braking systems whose lifespan mainly depends on the frequency of actuation. By calling the "maximum value" model pre-stored based on durability test data, the conversion from real-time parameters to the percentage of remaining lifespan can be achieved.

[0072] This design evolves component lifespan assessment from a simple univariate model based on "mileage" or "usage time" to a multivariate, refined model that considers environmental severity and usage frequency. Its advantage lies in the fact that the assessment results more closely reflect the actual physical wear and tear process of the component, resulting in more accurate predictions and a better ability to achieve the goal of providing early warnings "before the safety redundancy is exhausted." Those skilled in the art will understand that these models can be used individually or in combination; for example, for braking systems, both mileage-based wear and brake pressure integral-based fatigue can be considered simultaneously.

[0073] Specifically, let's take the cumulative trigger count model as an example. For the electronic parking brake system, the controller maintains a non-volatile memory variable to accumulate the number of times the EPB performs parking actions. Each successful parking increments this counter by 1. Before the vehicle leaves the factory, bench durability tests are conducted to determine the average number of failure cycles for this model of EPB under specific parking force requirements (e.g., able to park on a 20% slope), for example, 50,000 cycles. In the second type of loss information generation module, the real-time cumulative count is divided by the number of test failures to obtain the component's lifespan consumption ratio. For example, if 40,000 cycles have been accumulated, the lifespan consumption ratio is 80%, and the remaining lifespan ratio is 20%. Those skilled in the art will understand that the model can be more complex, for example, distinguishing between normal parking and slope parking (corresponding to different loads) and assigning different loss weights. The mileage and duration model is similar. Through testing, the lifespan mileage or duration under different road conditions (urban, highway, off-road) is obtained. During actual operation, the current road condition is determined based on environmental perception or navigation information, and the equivalent consumption under that road condition is calculated cumulatively.

[0074] By employing the aforementioned scheme of establishing a multi-parameter lifespan model based on durability test data, this scheme enables real-time, quantitative lifespan assessment of components not directly related to mileage or those highly affected by the environment. This further helps to address the problem of accurately assessing the remaining lifespan of components by simply relying on mileage or time, thereby synergistically improving the foresight and accuracy of the lifespan prediction technology of this invention.

[0075] Furthermore, the definition of "driving environment" can be more detailed, including dimensions such as temperature, humidity, and load. The "utilization of durability test data" does not necessarily store the complete curve directly; it can also store the parameters of the fitted curve. The determination of lifespan loss can be a continuous proportional value or a discrete level such as "healthy," "warning," or "expiration."

[0076] To further specify the generation logic of the third type of loss information, namely how to utilize the autonomous driving system's own capabilities to proactively detect performance degradation, this application also provides the following further implementation scheme.

[0077] As mentioned above, generating the third type of loss information based on the actual response information of the autonomous driving system to the driving control information can have several specific meanings. In one specific implementation, this step includes performing at least one of the following detections based on the actual response information of the autonomous driving system to the driving control information: detecting path deviation information of the vehicle's lateral or longitudinal travel, and determining the lifespan loss of the autonomous driving system based on the path deviation information; detecting the distance deviation between the perceived distance and the feedback distance, and determining the lifespan damage of the autonomous driving system based on the distance deviation; wherein the perceived distance is the distance between the vehicle and the target as perceived by the vehicle; the feedback distance is the distance between the vehicle and the target calculated based on the driving control information and the actual response information; detecting the response deviation between the driving control command and the vehicle's actual execution result of the driving control command, and determining the lifespan loss of the autonomous driving system based on the response deviation; wherein the actual response information includes the actual execution result.

[0078] In this scheme, this constraint defines three key dimensions for system-level performance verification. Path deviation detection reflects a decrease in the accuracy of steering, braking, and other actuators in tracking commands. Deviation detection between perceived distance and feedback distance (also known as "consistency verification") assesses the accuracy of the "perception-control" closed loop, such as whether the actual braking effect matches expectations, which can detect problems such as sensor attenuation or model inaccuracies. Response deviation detection assesses the "smoothness" or "dynamic characteristics" of command execution, such as whether there are abnormal fluctuations in steering response on fixed road sections, which can detect gaps or early signs of jamming in the mechanism. These detections are all effective means of inferring the health status from the overall system output performance.

[0079] This design fully leverages the dual role of the autonomous driving system as both a command issuer and an effect observer, enabling proactive cross-validation of its own performance. Its advantage lies in its ability to detect systemic performance degradation caused by the combined performance decline or mismatch of multiple components, which cannot be detected by the self-diagnosis of individual components. This serves as an important supplement to the first two types of information. Those skilled in the art will understand that these detections can be based on statistical methods, such as calculating the mean and variance of deviations over a period of time and comparing them to a calibrated normal range.

[0080] Specifically, consider the detection of the discrepancy between perceived distance and feedback distance. Assume an autonomous driving system plans to brake at a deceleration of 3 m / s² towards a stationary target ahead, aiming to stop 10 meters in front of the target. The system continuously senses the actual distance to the target using forward-facing radar. Simultaneously, based on real-time feedback from vehicle speed and deceleration sensors, and through inverse integration using a vehicle dynamics model, a "predicted distance to the target based on its own motion feedback" can be calculated. Theoretically, these two distance values ​​should be consistent during braking. The third type of loss information generation module continuously calculates the difference between these two distance values. If the difference consistently exceeds a reasonable range (e.g., the feedback calculation predicts stopping 5 meters in front of the target, but perception shows 15 meters remaining), it indicates a systematic performance deviation in one or more links of the "perception-model-execution" chain. The module then outputs a quantitative indicator representing system performance degradation as part of the third type of loss information. Those skilled in the art will understand that the detection trigger condition can be set to the deviation exceeding a certain threshold and persisting for a certain period to avoid instantaneous interference.

[0081] By employing the aforementioned multi-system-level performance deviation detection scheme, this approach can quantitatively assess the overall performance degradation of the autonomous driving system itself. This further helps to address the problem that relying solely on component self-reporting cannot detect system-level coupling faults or performance degradation, thereby synergistically improving the technical effectiveness of a multi-dimensional, three-dimensional health assessment system.

[0082] Furthermore, path deviation detection can be subdivided into lateral deviation and longitudinal deviation, with different sensitivity thresholds set for each. Response deviation detection can be performed on specific test sections with fixed road alignments to obtain purer evaluation results.

[0083] In order to ensure immediate response capability to sudden safety failures during operation, in addition to the life-based gradual retirement main process, the embodiments of this disclosure also provide the following preferred solutions that take into account real-time safety response.

[0084] like Figure 3 The diagram illustrates the control flow of an autonomous driving system in an embodiment of this disclosure. The autonomous driving system decommissioning control method may further include additional safety processing logic. In a preferred embodiment, the method further includes: determining, based on the vehicle status information, that an emergency hazard avoidance operation is performed when an emergency malfunction occurs; and determining, based on the vehicle status information, that a non-emergency malfunction occurs when a limp driving strategy is performed.

[0085] In this solution, a parallel, real-time safety response path based on the urgency of the fault is added on top of the main process. It prioritizes emergency situations that may directly jeopardize safety, such as tire blowouts or axle breakage, requiring the system to immediately execute evasive maneuvers (such as emergency braking, vehicle stabilization, or pulling over). For non-emergency faults, a degraded limp-riding strategy (such as speed limits, lane restriction, or malfunction indicator lamps) is activated, allowing the vehicle to safely reach its destination or repair shop. Only after this does the retirement control process, centered on lifespan assessment, continue.

[0086] This design clearly separates the logic of "safety emergency response" and "lifespan management" into distinct layers. Its advantage lies in ensuring that, under any circumstances, the vehicle's response to direct safety threats is of the highest priority and fastest speed, aligning with fundamental principles of functional safety. Simultaneously, the degraded operation strategy for non-emergency failures guarantees vehicle availability. Together with the lifespan retirement process, these two elements constitute a complete tiered safety control system.

[0087] Specifically, this logic can serve as a pre-processing step of the main flow or as a high-priority task running independently. For example, after the autonomous driving domain controller acquires vehicle status information, it is first parsed by the safety monitoring module. If any information defined as an "emergency mechanical fault" is parsed (see the previous classification), the current regular control loop is immediately interrupted, a preset emergency avoidance maneuver function is invoked, the vehicle is controlled to apply maximum braking force, maintain the current steering wheel angle or make minor corrections to stabilize the trajectory, and the hazard warning lights are activated. If the parsed fault is a performance loss type or a regular mechanical fault, the safety monitoring module sends an instruction to the main control module, requiring it to switch to limp-home mode. This mode may include behavioral constraints such as speed limits, prohibition of aggressive lane changes, and priority selection of the rightmost lane. After executing these immediate safety responses, the system continues with the calculation and judgment process of lifespan loss information. Understandably, the specific action sequences of emergency avoidance and limp-home strategies need to be verified through extensive simulation and real-vehicle testing to ensure their effectiveness.

[0088] By employing the aforementioned embedded instant safety response path, this solution can seamlessly handle sudden safety failures within the main lifespan monitoring process, ensuring the system's real-time safety. This further helps address unexpected dangerous situations that vehicles may encounter during operation, thereby synergistically building the comprehensive safety assurance technology effect of this invention, encompassing instant safety, degraded operation, and long-term retirement.

[0089] Furthermore, the triggering conditions for emergency avoidance operations are not limited to emergency faults reported by components. They can also come from extreme outputs of the third type of loss information generation module, such as a sudden and sharp increase in lateral deviation of the path, which may indicate tire pressure loss and can directly trigger emergency avoidance. The limp driving strategy can also be customized in more detail according to the type of non-emergency fault.

[0090] It should be noted that combining various specific technical features in this embodiment, such as combining a durability model based on the number of actions, a three-level fault classification, and a system-level path deviation detection, can simultaneously obtain accurate component life prediction, differentiated fault handling, and system performance verification capabilities, which should also fall within the protection scope of this disclosure.

[0091] It is understood that the various method embodiments mentioned above in this disclosure can be combined with each other to form combined embodiments without violating the principle and logic. Due to space limitations, this disclosure will not elaborate further. Those skilled in the art will understand that in the above methods of specific implementation, the specific execution order of each step should be determined by its function and possible internal logic, and the execution order between steps is not limited to implementation according to step number.

[0092] In addition, this disclosure also provides apparatus, electronic equipment, vehicles, and computer program products, all of which can be used to implement the autonomous driving system decommissioning control method of any of the autonomous driving systems provided in this disclosure. The corresponding technical solutions and descriptions are described in the corresponding records in the method section and will not be repeated here.

[0093] This disclosure provides a decommissioning control device for an automated driving system, which mainly includes:

[0094] The acquisition module is used to acquire vehicle status information that reflects the performance of the autonomous driving system. The vehicle status information includes the reported information of the vehicle's actuators, the real-time information of the durability parameters of the vehicle's actuators, and the actual response information of the autonomous driving system to the driving control information.

[0095] The determination module is used to determine the lifespan loss information of the autonomous driving system based on the vehicle status information.

[0096] The retirement module is used to determine whether the lifespan of the autonomous driving system has been exhausted based on the lifespan loss information, and to control the autonomous driving system to retire when the determination result is that the lifespan has been exhausted.

[0097] This disclosure also provides a vehicle including an autonomous driving domain controller configured to execute the autonomous driving system decommissioning control method described above.

[0098] This disclosure also provides an electronic device. Figure 4This is a block diagram of an electronic device provided in an embodiment of the present disclosure.

[0099] This disclosure provides an electronic device comprising: at least one processor 401; at least one memory 402; and one or more I / O interfaces 403 connected between the processor 401 and the memory 402; wherein the memory 402 stores one or more computer programs executable by the at least one processor 401, the one or more computer programs being executed by the at least one processor 401 to enable the at least one processor 401 to execute the above-described autonomous driving system decommissioning control method.

[0100] The modules in the aforementioned electronic device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of the computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0101] This disclosure also provides a computer program product, including a computer program that, when run in a processor, implements the operating logic of each module in the aforementioned autonomous driving health assessment system.

[0102] The computer program may be stored on a readable storage medium of a computer device or in the cloud; the processor of the computer device reads the computer program from the readable storage medium or in the cloud.

[0103] The aforementioned computer program product can be implemented through hardware, software, or a combination thereof. In one optional embodiment, the computer program product is specifically manifested as a computer storage medium; in another optional embodiment, the computer program product is specifically manifested as a software product, such as a software development kit (SDK), etc.

[0104] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0105] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0106] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0107] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0108] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0109] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0110] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0111] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0112] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0113] The above description is merely a preferred embodiment of this disclosure and is not intended to limit this disclosure. Any modifications or equivalent substitutions made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for controlling the decommissioning of an autonomous driving system, characterized in that, include: Acquire vehicle status information that reflects the performance of the autonomous driving system. The vehicle status information includes the reported information of the vehicle's actuators, the real-time information of the durability parameters of the vehicle's actuators, and the actual response information of the autonomous driving system to driving control information. Based on the vehicle status information, determine the lifespan loss information of the autonomous driving system; Based on the lifespan loss information, it is determined whether the lifespan of the autonomous driving system has been exhausted, and when the determination result is that the lifespan has been exhausted, the autonomous driving system is controlled to be decommissioned.

2. The method according to claim 1, characterized in that, The step of retiring the autonomous driving system when the determination result is that its lifespan has expired includes: If the judgment result indicates that the life loss information indicates that the life of the autonomous driving system has reached its life limit, a life expiration reminder is issued and the retirement control process is initiated.

3. The method according to claim 2, characterized in that, The retirement control process includes disabling the autonomous driving system after a limited number of applications.

4. The method according to any one of claims 1-3, characterized in that, The step of determining the lifespan degradation information of the autonomous driving system based on the vehicle status information includes: First type of loss information is generated based on the information reported by the vehicle's actuators; A second type of wear information is generated based on real-time information of the durability parameters of the vehicle's actuators; The third type of loss information is generated based on the actual response information of the autonomous driving system to driving control information; Based on the first type of loss information, the second type of loss information, and the third type of loss information, the lifespan loss information of the autonomous driving system is determined.

5. The method according to claim 4, characterized in that, The step of generating the first type of loss information based on the reported information from the vehicle's actuators includes: Based on the information reported by the actuator, when a performance loss is detected in the vehicle actuator, information on a performance loss type fault is generated, which is a non-emergency type fault. Based on the information reported by the actuator, when a mechanical abnormality is detected in the vehicle actuator and it is currently able to support limp driving, information on a routine mechanical maintenance fault is generated. The routine mechanical maintenance fault is a non-emergency fault. Based on the information reported by the actuator, when a mechanical abnormality is detected in the vehicle actuator and an emergency stop is required, information on an emergency mechanical fault is generated, and the emergency mechanical fault belongs to the category of emergency faults. The first type of loss information includes information on at least one of the following three types of failures: performance loss failures, routine mechanical maintenance failures, and emergency mechanical failures.

6. The method according to claim 4, characterized in that, The generation of the second type of wear information based on the real-time information of the durability parameters of the vehicle's actuators includes: The real-time information of the durability parameters includes real-time mileage and real-time driving environment; based on the real-time mileage and real-time driving environment of the vehicle actuators, the life loss of the vehicle actuators is determined by using the maximum mileage under different driving environments in the durability test data. The real-time information of the durability parameters includes the driving time and driving environment of each trip; based on the driving time and driving environment of each trip of the vehicle actuator, the life loss of the vehicle actuator is determined by using the maximum driving time under different driving environments in the durability test data. The real-time information of the durability parameters includes the cumulative number of triggers; based on the cumulative number of triggers of the vehicle actuators, the maximum number of triggers in the durability test data is used to determine the lifespan loss of the vehicle actuators.

7. The method according to claim 4, characterized in that, The generation of the third type of loss information based on the actual response information of the autonomous driving system to the driving control information includes: Based on the actual response information of the autonomous driving system to the driving control information, at least one of the following checks will be performed: Detect path deviation information of the vehicle in lateral or longitudinal direction, and determine the lifespan loss of the autonomous driving system based on the path deviation information; The distance deviation between the perceived distance and the feedback distance is detected, and the lifespan loss of the autonomous driving system is determined based on the distance deviation; the perceived distance is the distance between the vehicle and the target as perceived by the vehicle; the feedback distance is the distance between the vehicle and the target calculated based on the driving control information and the actual response information. The system detects the deviation between driving control commands and the vehicle's actual execution results of the driving control commands, and determines the lifespan loss of the autonomous driving system based on the response deviation; the actual response information includes the actual execution results.

8. The method according to claim 1, characterized in that, The method further includes: Based on the vehicle status information, if an emergency malfunction is detected, an emergency avoidance operation shall be performed. Based on the vehicle status information, if a non-emergency fault occurs, a limp driving strategy is executed.

9. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores at least one computer program that can be executed by the at least one processor, the at least one computer program being executed by the at least one processor to enable the at least one processor to perform the autonomous driving system decommissioning control method as described in any one of claims 1-8.

10. A vehicle, characterized in that, It includes an autonomous driving domain controller, which is configured to perform the autonomous driving system decommissioning control method according to any one of claims 1-8.

Images