Method for managing aid driving system in vehicle, and aid driving system for vehicle

Abstract

The embodiment of the invention provides a management method of an auxiliary driving system in a vehicle and the auxiliary driving system of the vehicle, the auxiliary driving system comprises a master controller and a slave controller, the master controller is used for controlling the operation state of the auxiliary driving system, and the slave controller is used for synchronously obtaining the operation state and controlling the auxiliary driving system to operate. And a plurality of application programs are installed in the slave controller. The method comprises the following steps: in response to a state switching request of a target application program received by a slave controller, controlling the slave controller to send the state switching request to a master controller; controlling the main controller to evaluate the current running state of the auxiliary driving system to obtain an evaluation result; responding to the evaluation result, indicating that the auxiliary driving system meets the state switching condition, controlling the main controller to respond to the state switching request, switching the state of the target application program from the current state to the target state, and obtaining a state switching result. According to the invention, the technical problem that the state management of the auxiliary driving system is relatively complex in the prior art is solved.

Description

Management methods for driver assistance systems in vehicles, and driver assistance systems in vehicles Technical Field

[0001] This application relates to the field of vehicle technology, and more specifically, to a management method for an assisted driving system in a vehicle, and the assisted driving system of a vehicle. Background Technology

[0002] With the rapid development of autonomous driving technology, vehicle driver assistance systems (ADAS) serve as a crucial transitional stage between fully manual and fully autonomous driving, and their stability and reliability are paramount to ensuring driving safety. The state management of ADAS typically involves managing and controlling the power status of key components, the status of basic system functions, and operational functions.

[0003] In related technologies, the power state, basic system functions, and operational function states in assisted driving systems are typically managed in a distributed manner. Power state management may be implemented on a microcontroller unit (MCU), while basic and operational function states are handled on a system-on-a-chip (SoC). This distributed management strategy simplifies the design of individual components to some extent, but frequent communication is required during state transitions to ensure state consistency. This not only increases the communication burden but may also lead to state management chaos due to communication anomalies.

[0004] There is currently no good solution to the complex technical problems of state management in the aforementioned driver assistance systems. Summary of the Invention

[0005] This application provides a management method for a vehicle's driver assistance system and a vehicle's driver assistance system, to at least solve the technical problem of complex state management of driver assistance systems in related technologies.

[0006] According to one aspect of the embodiments of this application, a management method for a driver assistance system in a vehicle is provided. The driver assistance system includes a main controller and a slave controller. The main controller is used to control the operating state of the driver assistance system, and the slave controller is used to synchronously acquire the operating state. Multiple applications are installed on the slave controller. The method includes: responding to the slave controller receiving a state switching request from a target application, controlling the slave controller to send the state switching request to the main controller, wherein the target application is any one of the multiple applications, and the state switching request is used to request switching the state of the target application from its current state to a target state; controlling the main controller to evaluate the current operating state of the driver assistance system and obtain an evaluation result; responding to the evaluation result indicating that the driver assistance system meets the state switching conditions, controlling the main controller to respond to the state switching request and switch the state of the target application from its current state to the target state, obtaining a state switching result; and controlling the main controller to synchronize the state switching result to the slave controller.

[0007] Optionally, the state switching request is triggered by the target application based on internal preset conditions and / or external operation information, wherein the internal preset conditions are used to characterize the preset rules for the target application to perform state switching, and the external operation information is used to characterize the state switching command from outside the vehicle.

[0008] Optionally, the current operating status of the assisted driving system includes at least: the power supply status of multiple electronic components within the assisted driving system, the operating status of the assisted driving system, and the business function status of the assisted driving system. The main controller evaluates the current operating status of the assisted driving system and obtains the evaluation results, including: the main controller evaluates the power supply status, operating status, and business function status respectively and obtains the evaluation results.

[0009] Optionally, the main controller evaluates the power supply status, operation status, and business function status respectively, and obtains evaluation results, including: in response to the power supply status indicating that multiple electronic components have sufficient power, the operation status indicating that the assisted driving system is in normal operation, and the business function status indicating that the assisted driving system is in assisted safety status, the evaluation result determines that the assisted driving system meets the state switching conditions; in response to the power supply status indicating that multiple electronic components have insufficient power, the operation status indicating that the assisted driving system is not in normal operation, and the business function status indicating that the vehicle is not in assisted safety status, the evaluation result determines that the assisted driving system does not meet the state switching conditions.

[0010] Optionally, the method further includes: in response to an evaluation result indicating that the driver assistance system has not met the state switching conditions, controlling the target application to maintain the current state.

[0011] Optionally, the method further includes: controlling the controller to broadcast the state switching result to multiple applications.

[0012] According to another aspect of the embodiments of this application, a vehicle assisted driving system is also provided. The vehicle assisted driving system includes: a main controller and a slave controller. The main controller is used to control the operating state of the assisted driving system, and the slave controller is used to synchronously acquire the operating state. Multiple applications are installed in the slave controller. The slave controller is used to send a state switching request to the main controller upon receiving a state switching request from a target application. The target application is any one of the multiple applications, and the state switching request requests a change in the state of the target application from its current state to a target state. The main controller is used to evaluate the current operating state of the assisted driving system and obtain an evaluation result. When the evaluation result indicates that the assisted driving system meets the state switching conditions, the main controller, based on the state switching request, switches the state of the target application from its current state to the target state, obtaining a state switching result. The state switching result is then synchronized to the slave controller.

[0013] Optionally, the controller is also used to broadcast the state transition result to multiple applications.

[0014] According to another aspect of the embodiments of this application, a management device for a vehicle-assisted driving system is also provided. The assisted driving system includes a main controller and a slave controller. The main controller is used to control the operating state of the assisted driving system, and the slave controller is used to synchronously acquire the operating state. Multiple applications are installed on the slave controller. The device includes: a first control unit, used to control the slave controller to send a state switching request to the main controller in response to receiving a state switching request from a target application. The target application is any one of the multiple applications, and the state switching request requests to switch the state of the target application from its current state to a target state; a second control unit, used to control the main controller to evaluate the current operating state of the assisted driving system and obtain an evaluation result; a third control unit, used to control the main controller to switch the state of the target application from its current state to the target state in response to the state switching request, in response to the evaluation result indicating that the assisted driving system meets the state switching conditions, and obtain a state switching result; and a fourth control unit, used to control the main controller to synchronize the state switching result to the slave controller.

[0015] According to another aspect of the embodiments of this application, a vehicle is also provided, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods in various embodiments of this application when it runs.

[0016] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0017] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0018] According to another aspect of the embodiments of this application, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods in various embodiments of this application.

[0019] According to another aspect of the embodiments of this application, a computer program is also provided, which, when executed by a processor, implements the methods of the various embodiments of this application.

[0020] In this embodiment, the assisted driving system includes a master controller and a slave controller. The master controller controls the operating state of the assisted driving system, and the slave controller synchronously acquires the operating state. Multiple applications are installed on the slave controller. The method includes: responding to the slave controller receiving a state switching request from a target application, controlling the slave controller to send the state switching request to the master controller, wherein the target application is any one of the multiple applications, and the state switching request requests to switch the state of the target application from its current state to a target state; controlling the master controller to evaluate the current operating state of the assisted driving system and obtain an evaluation result; responding to the evaluation result indicating that the assisted driving system meets the state switching conditions, controlling the master controller to respond to the state switching request and switch the state of the target application from its current state to the target state, obtaining a state switching result; and controlling the master controller to synchronize the state switching result to the slave controller. In other words, in this embodiment, the main controller controls the operating state of the assisted driving system, while the slave controller synchronously obtains the operating state of the assisted driving system from the main controller. In this way, multiple applications installed on the slave controller can also obtain the operating state of the assisted driving system in real time. When the slave controller receives a state switching request from a certain application, it can send the state switching request to the main controller. The main controller will then make further judgments based on the current operating state of the assisted driving system to determine whether the vehicle's assisted driving system currently meets the state switching conditions. If the state switching conditions are met, the main controller will control the application to switch states and synchronize the state switching result to the slave controller. This master-slave interaction mechanism for application state switching significantly reduces the complexity of application state switching, improves the efficiency and safety of state switching, and thus solves the technical problem of complex state switching logic in assisted driving systems in related technologies. Attached Figure Description

[0021] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0022] Figure 1 is a flowchart of a method for managing an assisted driving system in a vehicle according to an embodiment of this application;

[0023] Figure 2 is a schematic diagram of a vehicle's driver assistance system according to an embodiment of this application;

[0024] Figure 3 is a schematic diagram of a vehicle's driver assistance system according to an embodiment of this application;

[0025] Figure 4 is a schematic diagram of the state management of a driver assistance system in a related art according to an embodiment of this application;

[0026] Figure 5 is a schematic diagram of the state management of a driver assistance system in another related art according to an embodiment of this application;

[0027] Figure 6 is a schematic diagram of the state management of a driver assistance system according to another related art according to an embodiment of this application;

[0028] Figure 7 is a schematic diagram of the state management of a driver assistance system in another related art according to an embodiment of this application;

[0029] Figure 8 is a schematic diagram of the state management of a driver assistance system in a vehicle according to an embodiment of this application;

[0030] Figure 9 is a schematic diagram of a system state according to an embodiment of this application;

[0031] Figure 10 is a schematic diagram of a layered state according to an embodiment of this application;

[0032] Figure 11 is a schematic diagram of a master-slave node deployment according to an embodiment of this application;

[0033] Figure 12 is a schematic diagram of the interaction logic of a master-slave node according to an embodiment of this application;

[0034] Figure 13 is a schematic diagram of the deployment of SOC redundancy backup according to an embodiment of this application;

[0035] Figure 14 is a schematic diagram of a dual redundancy backup deployment of MCU and SOC according to an embodiment of this application;

[0036] Figure 15 is a schematic diagram of a management device for an assisted driving system in a vehicle according to an embodiment of this application. Detailed Implementation

[0037] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0038] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0039] According to an embodiment of this application, an embodiment of a management method for an assisted driving system in a vehicle is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0040] This embodiment provides a management method for a driver assistance system in a vehicle. The driver assistance system includes a main controller and a slave controller. The main controller is used to control the operating status of the driver assistance system, and the slave controller is used to synchronously acquire the operating status. Multiple applications are installed in the slave controller.

[0041] In this embodiment, the main controller (MCU) is the core of the assisted driving state management, and its functions include: global state control and arbitration, state backup and redundancy control, and state machine maintenance and updates. Regarding global state control and arbitration, the MCU is responsible for monitoring and managing the operating status of the entire assisted driving system, including but not limited to power supply status, operational status, and business function status. It can determine the rationality of state transitions based on the overall operating conditions and safety policies of the assisted driving system, ensuring the logical correctness of the state machine and its ability to handle emergencies. Regarding state backup and redundancy control, when the slave controller (SOC) fails, the MCU can take over the management of the state machine, controlling the vehicle to enter a safe state according to preset rules and strategies, such as issuing an alarm, maintaining straight-line driving, or pulling over, ensuring the stability of the assisted driving system and the safety of personnel. Regarding state machine maintenance and updates, the MCU maintains the logical framework and state transition rules of the entire state machine, ensuring the continuity of system states and smooth transitions between states.

[0042] Optionally, the role of the slave controller (SOC) is as follows: real-time state synchronization, application execution environment, and state transition request initiation. Regarding real-time state synchronization, the slave controller can synchronize and obtain system state information provided by the master controller in real time, ensuring that applications on the slave controller can understand the current system state in a timely manner and make corresponding reactions and adjustments. Regarding the application execution environment, multiple applications are installed on the slave controller, including applications for driver assistance functions such as driving, parking, and safety assistance, as well as applications for basic system functions such as upgrades, maintenance, and calibration. Regarding state transition request initiation, when applications on the slave controller detect conditions requiring a state transition, they can send a state transition request to the master controller. For example, an Over-the-Air (OTA) application can request to switch the system to upgrade mode when upgrade conditions are met.

[0043] Optionally, the driver assistance system adopts a master-slave architecture, which ensures that the state information between the master controller and the slave controller is consistent at all times, avoiding the inconsistency problem that may occur in traditional distributed state management and improving the overall system stability.

[0044] Optionally, the decision-making logic for state transitions in the assisted driving system is executed by the main controller, which has a higher functional safety level, while the slave controllers focus on executing application logic and initiating state transition requests. This separation of decision-making and execution reduces complexity, minimizes communication interactions during state transitions, and improves system responsiveness and safety. Furthermore, as the master node of the state machine and the arbitrator of state transitions, the main controller can independently manage the state machine even in the event of a slave controller failure, ensuring the vehicle enters a preset safe state. This significantly enhances the functional safety level of the assisted driving system and provides additional protection for vehicle operation.

[0045] In this embodiment, through the master-slave state management mechanism, the assisted driving system can more effectively switch and manage states while ensuring state consistency, improving system response speed and enhancing functional safety. This ensures the smooth operation of complex driving functions and provides a safer and more comfortable driving experience for drivers and passengers.

[0046] Figure 1 is a flowchart of a management method for an assisted driving system in a vehicle according to an embodiment of this application. As shown in Figure 1, the process includes the following steps.

[0047] Step S101: In response to receiving a state switching request from the target application from the controller, the controller sends the state switching request to the main controller.

[0048] In the technical solution provided in step S101 of this application, multiple applications (APPs) run on the slave controller (SOC) in the driver assistance system. These multiple applications cover various aspects of the driver assistance system, including but not limited to driving assistance (e.g., adaptive cruise control), parking assistance (e.g., automatic parking), and safety assistance (e.g., forward collision warning). The target application is any one of the multiple applications, and the state switching request is used to request the state of the target application to be switched from the current state to the target state.

[0049] In this embodiment, when the target application on the controller detects a situation requiring a change in its operating state, a state switching request is generated. For example, taking an OTA app as an example, when the OTA app detects that the voltage of the Electronic Control Unit (ECU) in the vehicle is within the normal range, the vehicle speed is less than 5 km / h, and the vehicle is in P / N gear, a state switching request can be generated to request a change in the current state of the OTA app.

[0050] Optionally, when the controller responds to a state transition request initiated by the target application, the controller itself does not immediately perform a state transition, but instead passes the state transition request to the master controller.

[0051] In this step, after receiving a state transition request from the target application, the slave controller sends the request to the master controller, which then makes the decision. This division of labor between the master and slave controllers establishes an arbitration and communication mechanism based on the state transition request, effectively improving the system's robustness, responsiveness, and security.

[0052] Step S102: Control the main controller to evaluate the current operating status of the assisted driving system and obtain the evaluation results.

[0053] In the technical solution provided in step S102 of this application, after receiving the state switching request sent by the controller, the main controller can evaluate the current operating state of the assisted driving system to determine whether the assisted driving system can safely perform a state switching.

[0054] In this embodiment, the main controller can evaluate the current operating status of the assisted driving system according to preset rules and safety policies. The evaluation content may include, but is not limited to, power supply status, operational status, and business function status.

[0055] Optionally, regarding the power supply status, the main controller can check the power supply status of key components in the driver assistance system, such as the MCU, SOC, and sensors, to confirm whether the power supply is stable and meets the requirements for the upcoming state transition. Regarding the operational status, the main controller can check whether the driver assistance system is undergoing a system upgrade, is in low-power mode, or has maintenance operations pending, ensuring that basic functionalities do not conflict with state transitions. Regarding the service function status, the main controller can evaluate the driver assistance services currently being executed in the system, such as driving assistance, parking assistance, or safety assistance functions, to confirm whether the driver assistance system can safely exit the current service state and enter a new state.

[0056] For example, suppose the OTA app on the controller detects an opportune time for a software upgrade (e.g., the vehicle is stationary and the connection is stable) and sends a "Enter Upgrade" command to the main controller. At this point, the main controller can perform the following checks: check if the ECU voltage is stable within the normal range to ensure the upgrade process is not interrupted by voltage fluctuations; verify if the vehicle is in a safe parking state, i.e., whether the vehicle speed is below a set threshold and whether the gear is in P or N; and detect if there are any other critical operations currently being performed, such as whether auxiliary safety functions are being used, ensuring that the immediate disengagement of these functions will not pose a danger to the vehicle or passengers.

[0057] Optionally, after obtaining the evaluation results, it can be determined whether the driver assistance system meets the state switching conditions based on the evaluation results.

[0058] In this step, after receiving a state transition request, the main controller does not directly execute the state transition, but instead conducts a comprehensive safety and feasibility assessment of the system to ensure that each state transition is reasonable and safe.

[0059] In step S103, in response to the evaluation result indicating that the assisted driving system meets the state switching conditions, the main controller responds to the state switching request and switches the state of the target application from the current state to the target state, thereby obtaining the state switching result.

[0060] In the technical solution provided in step S103 of this application, after obtaining the evaluation result, if the evaluation result indicates that the assisted driving system meets the state switching conditions, the main controller controls the target application's state from the current state to the target state, and obtains the state switching result.

[0061] Optionally, if the evaluation results indicate that the assisted driving system meets the state switching conditions, the main controller switches the state of the target application from the current state to the target state, ensuring that the decision-making and execution of the state switching comply with the established strategies and safety standards.

[0062] Optionally, after the state transition is complete, the main controller generates a state transition result, which includes information on whether the state transition was successful and the new state of the system after the transition. For the target application, the state transition result means that it can begin operating or providing services according to the new state. For example, switching from driving mode to parking mode, the vehicle's driver assistance functions will change from highway navigation assistance to automatic parking assistance. In addition, the state transition result also includes possible warning messages or abnormal conditions, which are very important for subsequent system monitoring and maintenance.

[0063] In this step, by conducting detailed evaluations before the state switching request and having the main controller perform the state switching based on the evaluation results, the robustness and safety of the assisted driving system when performing state changes are ensured, state switching without sufficient evaluation is avoided, and system failures or safety accidents that may be caused by improper state switching are reduced.

[0064] Step S104: The main controller synchronizes the state switching result to the slave controller.

[0065] In the technical solution provided in step S104 of this application, after executing the state switching logic, the master controller synchronizes the state switching result back to the slave controller. This step is a key link in the master-slave state management mechanism, ensuring that the application on the slave controller can obtain the latest system state in a timely manner for further operation or adjustment.

[0066] In this embodiment, the state transition request is first issued by the target application on the slave controller. Then, the master controller evaluates and arbitrates the request to determine whether the state transition is feasible and the subsequent actions. Once the decision is made, whether to confirm the state transition, maintain the current state, or transition to another state, the master controller will communicate the result to the slave controller, completing one state management cycle.

[0067] Alternatively, communication between the master controller and the slave controller typically follows a specific protocol, such as Controller Area Network (CAN), Local Interconnect Network (LIN), or a higher bandwidth Flexible Bus (FlexRay) or Ethernet. These protocols ensure fast and reliable transmission of status information.

[0068] Optionally, during the synchronization of state transition results, a state feedback mechanism is involved. That is, after receiving the latest state from the main controller, the controller reports the state transition result to the application, and the application performs corresponding operations accordingly, such as enabling new functions, terminating the current task, or entering safe mode.

[0069] Optionally, to ensure the accuracy of state transition results, a verification mechanism may be added during the synchronization process to check the integrity of data transmission. If a data error or communication failure is detected, the system will initiate a redundancy recovery process, ensuring the correct transmission of state information by retransmitting the status information or using a backup communication channel.

[0070] In this step, the synchronization of state transition results not only ensures the execution of state transition decisions, but also enhances functional safety and system response speed through effective communication and feedback mechanisms, promotes seamless collaboration between applications and the system, and is an important guarantee for the stable operation of the driver assistance system and the improvement of user experience.

[0071] In steps S101 to S104 above, the main controller controls the operating state of the assisted driving system, while the slave controller is used to synchronously obtain the operating state of the assisted driving system from the main controller. In this way, multiple applications installed on the slave controller can also obtain the operating state of the assisted driving system in real time. When the slave controller receives a state switching request from a certain application, it can send the state switching request to the main controller. The main controller will then make further judgments based on the current operating state of the assisted driving system to determine whether the vehicle's assisted driving system currently meets the state switching conditions. If the state switching conditions are met, the main controller will control the application to switch states and synchronize the state switching result to the slave controller. This master-slave interaction mechanism for application state switching significantly reduces the complexity of application state switching, improves the efficiency and safety of state switching, and thus solves the technical problem of complex state switching logic in assisted driving systems in related technologies.

[0072] The management method of the driver assistance system in the vehicle described in this application is further described below.

[0073] As an optional implementation, the state switching request is triggered by the target application based on internal preset conditions and / or external operation information, wherein the internal preset conditions are used to characterize the preset rules for the target application to perform state switching, and the external operation information is used to characterize the state switching command from outside the vehicle.

[0074] In this embodiment, the aforementioned internal preset conditions refer to a series of rules and thresholds set by the target application to switch from the current state to the target state. These conditions are typically customized based on the application's functional characteristics and safety requirements, aiming to ensure that the state switch occurs at the appropriate time, without interfering with the normal operation of other critical functions or jeopardizing driving safety. For example, for OTA applications, internal preset conditions may include: vehicle speed below a speed threshold, gear in park or neutral, ECU voltage within the normal range, etc., to ensure software upgrades are performed in a safe environment. For Automatic Emergency Braking (AEB) applications, internal preset conditions may include: the detection distance of obstacles ahead, the vehicle's speed range, and the obstacle's motion state, etc., to ensure that the AEB function is activated only when emergency braking is truly needed. The existence of internal preset conditions allows the application to autonomously judge and prepare for state switching, but the final switching decision is still reviewed by the main controller from a global perspective, ensuring the accuracy and safety of the state switch.

[0075] Alternatively, external operational information originates from outside the vehicle and is typically generated by driver behavior, changes in road conditions, or signals from other external systems to instruct the driver assistance system to switch states. This information may come from various vehicle sensors, communication systems, or requests made by the driver through a human-machine interface (e.g., touchscreen, voice commands).

[0076] For example, a driver requests automatic parking through the human-machine interface, a typical external operation message used to instruct the driver assistance system to switch from driving to parking mode. Traffic signals or accident alerts received by the vehicle-to-everything (V2X) communication system trigger the driver assistance system to enter low-speed driving or safety assistance mode to cope with complex traffic environments.

[0077] Optionally, external operational information enables the driver assistance system to react quickly to changes in the external environment, enhancing the system's adaptability and user experience. However, since this information may be subject to external interference, the processing of external operational information can be reviewed by the main controller to prevent misoperation or improper state switching.

[0078] In this step, the state transition request triggering mechanism in the design of the driver assistance system integrates the autonomy of internal preset conditions and external operational information, reflecting the flexibility of the state transition request of the driver assistance system.

[0079] As an optional implementation, the current operating state of the assisted driving system includes at least: the power supply status of multiple electronic components in the assisted driving system, the operation status of the assisted driving system, and the business function status of the assisted driving system. Step S103: Control the main controller to evaluate the current operating state of the assisted driving system and obtain the evaluation results, including: controlling the main controller to evaluate the power supply status, operation status, and business function status respectively, and obtain the evaluation results.

[0080] In this embodiment, the current operating status of the driver assistance system includes at least three dimensions of evaluation: power supply status, operation status, and business function status.

[0081] Optionally, the evaluation of power supply status involves checking the power supply status of various key electronic components within the driver assistance system. This ensures that each key electronic component receives a stable and sufficient power supply before state switching can be performed. These key electronic components include, but are not limited to: MCU, SOC, radar, camera, Global Positioning System (GPS), and Inertial Measurement Unit (IMU). For example, when attempting to enter OTA upgrade mode, checking that the ECU voltage is within the normal range helps prevent system crashes or data corruption due to power issues during the upgrade process.

[0082] Optionally, the evaluation of operational status primarily focuses on the operating mode of the driver assistance system, including whether an operation is in progress and whether the vehicle is ready. Before switching modes, it can be confirmed that there are no ongoing or uninterruptible operations, and whether the vehicle's current operating conditions (e.g., speed and gear position) allow for a safe mode switch. For example, when switching from driving mode to parking mode, it can be confirmed that the vehicle has decelerated to a safe stopping speed and the gear is appropriate to ensure that there is no harm to the vehicle or the surrounding environment.

[0083] Optionally, the evaluation of the operational function status involves checking the current status of specific functions performed by the driver assistance system (such as highway navigation assist, automatic parking, emergency braking, etc.) to confirm that disabling the current function will not pose a safety risk, and to assess whether the function can be safely started or continue to operate in the new state. For example, when switching from an assisted safety state (such as AEB) to an upgraded state, it must be ensured that all necessary safety functions are disabled or in a safe standby state to avoid affecting the vehicle's immediate safety functions.

[0084] Optionally, the main controller performs a detailed evaluation of the above three aspects based on preset rules and safety policies to determine whether state switching is feasible. The MCU's evaluation logic is not limited to confirming whether the states in each dimension meet the switching conditions; it can also assess the impact of state switching on the overall system stability, including but not limited to: state compatibility, redundancy and backup states, and external environmental factors. State compatibility ensures that the new state does not conflict with other currently running system states. For example, it confirms that the vehicle will not need to perform emergency braking simultaneously when entering an upgrade state. Regarding redundancy and backup states, in certain situations, such as when the slave controller fails, the main controller checks whether its own backup state is sufficient to support a safe state transition, such as whether it can control the vehicle to enter a parking maneuver or other safe modes. External environmental factors consider the impact of the vehicle's external environment (e.g., road conditions, weather conditions) on state switching to ensure safe and controllable state switching even under adverse conditions.

[0085] In this step, the evaluation results are an indispensable part of the state transition decision-making process, providing a scientific basis for the state transition. If the evaluation results show that all conditions are met and the state transition will not jeopardize the system's stability or safety, then the main controller will execute the state transition; otherwise, it will reject the request. The accuracy of the evaluation results directly affects the success of the state transition, thus impacting the overall performance and reliability of the driver assistance system.

[0086] As an optional implementation, the main controller evaluates the power supply status, operation status, and service function status respectively, and obtains evaluation results, including: in response to the power supply status indicating that multiple electronic components have sufficient power, the operation status indicating that the assisted driving system is in normal operation status, and the service function status indicating that the assisted driving system is in assisted safety status, the evaluation result determines that the assisted driving system meets the state switching conditions; in response to the power supply status indicating that multiple electronic components have insufficient power, the operation status indicating that the assisted driving system is not in normal operation status, and the service function status indicating that the vehicle is not in assisted safety status, the evaluation result determines that the assisted driving system does not meet the state switching conditions.

[0087] In this embodiment, as described above, the main controller performs detailed evaluations of three key aspects of the assisted driving system: power supply status, operational status, and business function status, to determine whether the assisted driving system meets the conditions for state switching. This evaluation process is the basis for the entire system's decision-making regarding state switching, ensuring the safety and rationality of state transitions.

[0088] Optionally, if the power supply status indicates that multiple electronic components in the driver assistance system have sufficient power, the operation status indicates that the driver assistance system is in normal operation, and the business function status indicates that the driver assistance system is in an assisted safety state, then the evaluation result indicates that the driver assistance system meets the state switching conditions, that is, the state switching operation of the target application can be executed.

[0089] Optionally, if the power supply status indicates that multiple electronic components have insufficient power, the operation status indicates that the driver assistance system is not in normal operation, and the business function status indicates that the vehicle is not in an assisted safety state, and the evaluation result indicates that the driver assistance system does not meet the state switching conditions, then the state switching operation of the target application cannot be performed.

[0090] In this step, the main controller integrates the evaluation results from the three aspects mentioned above and makes a conditional judgment. When the power supply is sufficient, the operation is normal, and the business function status allows, the main controller determines that the evaluation results indicate the assisted driving system meets the state switching conditions. Conversely, if a problem occurs in any link or the conditions are not met, the main controller determines that the current system state is not suitable for switching, thereby preventing unsafe or unreasonable state transitions from occurring. Through this comprehensive evaluation and conditional judgment, it can be ensured that each state switch is carried out under strict safety conditions, reducing potential risks. On the other hand, through detailed condition checks, it is possible to more accurately determine when and how to switch states, improving the availability and response speed of assisted driving functions and providing users with a better service experience.

[0091] As an optional implementation, the method further includes: controlling the controller to broadcast the state switching result to multiple applications.

[0092] In this embodiment, after the main controller performs a state switching operation on the target application based on the evaluation results and synchronizes the state switching results to the slave controller, it can control the slave controller to broadcast the state switching results to multiple applications. This ensures that the relevant applications in the slave controller can receive the system state update notification in a timely manner, thereby adjusting their own operating strategies to adapt to the new system state.

[0093] Optionally, the controller can use its own hardware resources and network architecture, such as an internal bus or wireless communication module, to ensure that each application receives the state transition notification. Upon receiving the state transition broadcast, each application can adjust its behavior to adapt to the new system state according to its own functions and preset operating rules. For example, when the system switches from driving to parking, the driving assistance application will stop its relevant functions, while the parking assistance application will start and take over control.

[0094] In this step, the broadcasting mechanism of state transition results enables effective communication between the application on the controller and the main controller, enhancing the collaborative work among the various components within the driver assistance system. This helps improve the overall system response speed and operational efficiency, ensuring that all applications can quickly adjust when states change, providing a consistent service experience.

[0095] According to an embodiment of this application, an embodiment of a vehicle driver assistance system is provided. FIG2 is a schematic diagram of a vehicle driver assistance system according to an embodiment of this application. As shown in FIG2, the vehicle driver assistance system 200 includes: a main controller 201 and a slave controller 202. The main controller 201 is used to control the operating state of the driver assistance system, and the slave controller 202 is used to synchronously acquire the operating state. Multiple applications are installed in the slave controller 202.

[0096] The controller 202 is used to send a state transition request to the main controller upon receiving a state transition request from a target application. The target application can be any one of multiple applications, and the state transition request is used to request that the state of the target application be switched from its current state to the target state.

[0097] In this embodiment, multiple applications run on the slave controller (SOC) in the driver assistance system. These multiple applications cover various aspects of the driver assistance system, including but not limited to driving assistance (e.g., adaptive cruise control), parking assistance (e.g., automatic parking), and safety assistance (e.g., forward collision warning). The target application can be any one of these multiple applications, and the state transition request is used to request a change in the state of the target application from its current state to a target state.

[0098] In this embodiment, when the target application on the controller detects a situation requiring a change in its operating state, a state switching request is generated. For example, in the case of an OTA app, when the OTA app detects that the ECU voltage is within the normal range, the vehicle speed is less than 5 km / h, and the vehicle is in P / N gear, a state switching request can be generated to request a change in the current state of the OTA app.

[0099] Optionally, when the controller responds to a state transition request initiated by the target application, the controller itself does not immediately perform a state transition, but instead passes the state transition request to the master controller.

[0100] In this step, after receiving a state transition request from the target application, the slave controller sends the request to the master controller, which then makes the decision. This division of labor between the master and slave controllers establishes an arbitration and communication mechanism based on the state transition request, effectively improving the system's robustness, responsiveness, and security.

[0101] The main controller 201 is used to evaluate the current operating state of the assisted driving system and obtain the evaluation result; when the evaluation result indicates that the assisted driving system meets the state switching conditions, it switches the state of the target application from the current state to the target state based on the state switching request and obtains the state switching result; and it synchronizes the state switching result to the slave controller.

[0102] In this embodiment, the main controller can evaluate the current operating state of the assisted driving system according to preset rules and safety policies. The evaluation may include, but is not limited to, power supply status, operational status, and business function status. After obtaining the evaluation results, if the results indicate that the assisted driving system meets the state transition conditions, the main controller switches the target application's state from its current state to the target state, obtaining a state transition result. After obtaining the state transition result, it can be synchronized to the slave controller to ensure that the application on the slave controller can obtain the latest system status in real time for further operation or adjustment.

[0103] As an optional implementation, the controller is also used to broadcast the state transition result to multiple applications.

[0104] In the vehicle's driver assistance system, when the main controller executes the state switching operation of the target application based on the evaluation results and synchronizes the state switching results to the slave controller, it can control the slave controller to broadcast the state switching results to multiple applications. This ensures that the relevant applications in the slave controller can receive the system state update notification in a timely manner, thereby adjusting their operating strategies to adapt to the new system state.

[0105] In the vehicle's assisted driving system of this application embodiment, the main controller controls the operating state of the assisted driving system, while the slave controller is used to synchronously obtain the operating state of the assisted driving system from the main controller. In this way, multiple applications installed on the slave controller can also obtain the operating state of the assisted driving system in real time. When the slave controller receives a state switching request from a certain application, it can send the state switching request to the main controller. The main controller will then make further judgments based on the current operating state of the assisted driving system to determine whether the vehicle's assisted driving system currently meets the state switching conditions. If the state switching conditions are met, the main controller will control the application to switch states and synchronize the state switching result to the slave controller. This master-slave interaction mechanism for application state switching significantly reduces the complexity of application state switching, improves the efficiency and safety of state switching, and thus solves the technical problem of complex state switching logic in assisted driving systems in related technologies.

[0106] The above technical solutions of the embodiments of this application will be further illustrated below with reference to preferred embodiments of the present invention.

[0107] Driving assistance state management is the core logical framework of the autonomous driving control module. By dividing the system behavior into states, complex driving behaviors are decomposed into independent state modules, with each state handling only a single function, ensuring the safe and efficient operation of the system.

[0108] Figure 3 is a schematic diagram of a vehicle assisted driving system according to an embodiment of this application. As shown in Figure 3, the assisted driving system state management includes: power state management, basic state management, and business state management. Power state management focuses on the power control and monitoring of key sensor components within the assisted driving system, including but not limited to: MCU, SOC, network switch, Global Navigation Satellite System (GNSS), IMU, Ultrasonic Sensor System (USS), Radio Detection and Ranging (RADAR), and Light Detection and Ranging (or Laser Imaging Detection and Ranging) systems. Ranging (LIDAR) and camera (CAMERA) power-on / off management, sleep / wake-up management, etc.; Basic status management focuses on the fundamental level of system operation, including but not limited to: system software upgrade management, covering online (OTA) upgrades and offline (USB flash drive) upgrades; maintenance activities, including health diagnosis and after-sales service operations; standardized calibration process to ensure sensor accuracy and consistency; activation of energy-saving mode to reduce unnecessary power consumption; special modes such as sentry mode to improve vehicle safety in idle state; transportation mode, adapted to vehicles; Business status management targets the core application scenarios of assisted driving, including but not limited to: driving assistance functions, such as highway navigation assistance and urban road navigation; parking assistance technology, covering automatic parking and remote parking; active safety functions, such as automatic emergency braking (AEB) and lane keeping assist (LKA), to protect the safety of people and property in different driving situations.

[0109] In related technologies, traditional autonomous driving systems typically design and manage power state, basic function state, and business state separately. However, because these three states are interdependent, the arbitration logic becomes complex, and the deployment relationships become chaotic, making efficient and safe management difficult. Figure 4 is a schematic diagram of state management in an assisted driving system according to an embodiment of this application. As shown in Figure 4, the state management of the assisted driving system is entirely deployed on the SOC. While this deployment method seems simple, it actually poses security risks. For example, when the SOC encounters a fault or needs to be restarted, although the MCU is still running, the entire system will stop operating. In this situation, it is possible to attempt to execute a low-power mode (e.g., only keeping the MCU running) or keep some critical sensors (e.g., surround-view cameras) working, but due to the lack of a state management mechanism, system chaos is easily triggered. The blurred boundaries between different states (e.g., low power consumption and sensor keep-alive) make state transitions uncertain events, increasing system instability and security risks.

[0110] Optionally, Figure 5 is a schematic diagram of the state management of an assisted driving system according to another related technology of this application embodiment. As shown in Figure 5, the state management of the assisted driving system is deployed entirely in the MCU. This deployment centralizes the entire control logic in the MCU. Since the functional safety level of the MCU is higher than that of the SOC, it is more stable than the deployment method in Figure 3. Because the centralized state management is implemented in the MCU, it means that all state detection, logic judgment and switching arbitration will be handled by the MCU. The SOC does not have state management, but many autonomous driving services (such as city navigation assistance and parking assistance) run on the SOC. When relying on state management, it needs to frequently interact with the MCU, resulting in an increase in system communication interaction messages, which will increase communication risks (such as communication message loss). In addition, the communication interaction between the SOC and the MCU will also increase the transmission latency.

[0111] Optionally, Figure 6 is a schematic diagram of the state management of an assisted driving system according to another related technology of this application embodiment. As shown in Figure 6, the power state and basic state are deployed on the MCU, and the business state is deployed on the SOC. Since the state management of the SOC is closely dependent on the power and basic state management of the MCU, especially in the scenario of state switching, ensuring seamless connection and information synchronization between the two becomes particularly important. For example, when the system is running in driving assistance mode, such as highway navigation assistance or urban road navigation, if a software upgrade (e.g., OTA upgrade) instruction is received at this time, it needs to smoothly transition from the driving state to the upgrade state. This requires a high degree of coordination between the business state module and the basic state module. The business state module needs to orderly exit the driving assistance function, while the basic state module gradually shuts down unnecessary system processes, preparing to enter the low-power upgrade mode. If the operation sequence or timing of these two is not properly coordinated, for example, if the business state has not completely exited driving assistance while the basic state has begun to shut down critical driving support, it may cause a sudden interruption of driving operation, impair the user experience, or even cause safety risks.

[0112] Optionally, Figure 7 is a schematic diagram of the state management of an assisted driving system according to another related art embodiment of this application. As shown in Figure 7, the power state is deployed on the MCU, and the basic state and business state are deployed on the SOC. Since the state management of the SOC is closely dependent on the state management of the MCU, there is also the problem of mutual dependence between the two states and complex arbitration logic. For example, when the system is in the process of OTA upgrade, it suddenly receives a command to power down the entire vehicle or does not receive any wake-up message for a long time. At this time, based on its power state management responsibilities, the MCU will determine that a power-down operation should be performed to save energy and protect the hardware from potential damage. However, the basic state module on the SOC, given the sensitivity of the upgrade process, tends to maintain the current state until the upgrade is completed to ensure data integrity and security. If this logical divergence is not properly coordinated, it will lead to inconsistency between the states of the SOC and the MCU, thereby causing processing abnormalities, and in severe cases, it may even lead to system paralysis or upgrade failure.

[0113] However, this application provides a management method for a vehicle's assisted driving system. Through a master-slave state management mechanism, various states of the assisted driving system (e.g., power state, basic state, and operational state) are uniformly deployed on the MCU, while the SOC acts as a slave node, synchronizing state information from the MCU in real time. The state switching logic of the assisted driving system is determined by the SOC, while state switching and arbitration are determined by the MCU, forming a closely collaborative but clearly defined dual-system architecture. This solves both the inconsistency between the MCU and SOC states and the state switching arbitration problem, while also providing redundancy backup capabilities. When the SOC fails, the MCU can take over state management and control state transitions to ensure stable system operation. In other words, the master-slave state management mechanism, through clear functional division and efficient communication strategies, effectively solves the problems of inconsistency between the MCU and SOC states and complex state switching arbitration in traditional assisted driving systems, while also enhancing system stability and security.

[0114] Figure 8 is a schematic diagram of state management in a vehicle-mounted assisted driving system according to an embodiment of this application. As shown in Figure 8, in the assisted driving system, the microcontroller unit (MCU) acts as the master node, responsible for managing the entire system's state machine. The MCU can manage the entire system's state machine in two ways: hierarchical logic management and composite state machine management. For hierarchical state management, the MCU can organize the state machine hierarchically, dividing the system's states into three main categories: power state, basic state, and business state. Each category is further subdivided into several specific sub-states. The advantage of this management method is that it clearly defines the scope and priority of each state, making the transition logic between states more orderly and easier to understand and maintain. For single composite state machine management, the MCU can construct a large-scale composite state machine containing all states, including all sub-states of the power state, basic state, and business state. The advantage of this management method is that state management is more compact; all possible transition paths are defined within a single framework, which is beneficial for achieving unified management of complex state transitions. Whether using layered logic or composite state machine management, the MCU is responsible for monitoring and adjudicating the timing and conditions of state transitions, ensuring that each state switch follows preset security rules and business logic.

[0115] As shown in Figure 8, in an assisted driving system, the System-on-a-Chip (SOC) acts as a slave node, dynamically maintaining its system state in sync with the master node (MCU). The SOC's main tasks include: real-time state synchronization, state interaction and feedback, and state transition request uploading. Real-time state synchronization refers to the SOC continuously receiving state information from the MCU, ensuring a complete understanding of the current state of the entire assisted driving system. This is crucial for applications on the SOC to understand and respond to system changes. State interaction and feedback refers to the ability of each application within the SOC to perform localized state transition business logic judgments based on the real-time perceived system state and submit state transition requests to the SOC's internal state management module. This process demonstrates the autonomy and intelligence of the SOC, enabling applications to quickly respond to changes in the driving environment. State transition request uploading means that when an application on the SOC decides a state transition is needed, the request is first passed to the SOC's internal state management module, and then forwarded by the SOC to the MCU, which executes the final state transition logic arbitration. This mechanism ensures that the state transition decision-making process incorporates both the SOC's real-time perception and business requirements, while also being subject to the MCU's stable control and security verification.

[0116] In this embodiment, by positioning the MCU as the master node controller, responsible for global state management and state transition arbitration, and supplementing it with the SOC as the slave node controller for real-time state synchronization and uploading of state transition requests, not only is the efficiency and accuracy of state transition improved, but the overall stability and security of the system are also enhanced through the redundancy backup capability of the MCU. Moreover, this master-slave state management mechanism effectively solves the problems of poor coordination, communication delay and insufficient functional security in traditional state management.

[0117] The state management method for the vehicle's assisted driving system in this application mainly involves the definition of system states, the deployment of system states, and the logical detection and switching of system states. The definition of system states refers to the process of clearly identifying and describing the various operating states or working modes that the entire system may be in within the assisted driving system. Figure 9 is a schematic diagram of a system state according to an embodiment of this application. This system state covers multiple levels, from basic power management and system initialization to advanced automated driving assistance function activation and software upgrades, including but not limited to: driving state, parking state, power-down state, sleep state, fault state, MCU operating state, SOC operating state, upgrade state, calibration state, low-power / power-saving state, sentry state, and transportation state. Among them, the following states are defined as follows: Power-down state: The system is completely shut down, with no electronic components operating; Hibernation state: The system is in a low-power mode, with some electronic components suspending operation, but it can still quickly recover to a fully functional state; Fault state: The system detects an error in a critical component or software that may affect driving safety; MCU running state: The microcontroller unit (MCU) is active, performing basic control and management functions; SOC running state: The SOC is active, undertaking complex data processing and advanced driver assistance functions; Upgrade state: The system is performing software or firmware updates, such as OTA upgrades; Calibration state: The system is performing sensor calibration or system parameter adjustments; Low power / power saving state: The system operates at the lowest possible energy consumption level, suitable for inactive or waiting-to-wake-up scenarios; Sentinel state: The system maintains monitoring of the surrounding environment and can react to potential threats even when the vehicle is not running; Transportation state: The system is configured in a mode suitable for vehicle logistics transportation or long-term parking.

[0118] Optionally, the various states of the system can be placed in a system state machine and divided into power states, basic states, and service states in a hierarchical manner. Figure 10 is a schematic diagram of a hierarchical state according to an embodiment of this application. As shown in Figure 10, the power states mainly include power-down state, sleep state, MCU running state, SOC running state, fault state, etc.; the basic states mainly include calibration state, power-saving state, upgrade state, maintenance state, normal state, etc.; the service states mainly include driving state (e.g., highway navigation state, city navigation state, etc.), parking state (e.g., automatic parking, memory parking, etc.), auxiliary safety state (e.g., AEB, LKA, etc.); wherein, the basic states operate in the SOC running state of the power states, and the service states operate in the normal state of the basic states.

[0119] Optionally, the deployment of system states involves the specific arrangement of state management logic on the hardware platform. The main deployment strategies for system state management include master node deployment and slave node deployment. Figure 11 is a schematic diagram of a master-slave node deployment according to an embodiment of this application. As shown in Figure 11, for master node deployment, the MCU acts as the master node, undertaking the management responsibility of the entire system state machine, including the control and arbitration of power state, basic state, and business state. For slave node deployment, the SOC acts as the slave node, its state management logic is synchronized with the MCU, responsible for receiving the latest state information from the MCU and adjusting its own operating mode accordingly. Simultaneously, the SOC interacts with the APP module in the system, collecting the APP's requirements and state switching requests, and then forwarding these requests to the MCU for review and execution.

[0120] Optionally, the logical detection and switching of system states determines how the system smoothly transitions from one state to another, mainly accomplished by the APP in the slave node. The synchronization and switching of system states involve the interaction between the MCU master module and the SOC slave module. Figure 12 is a schematic diagram of the interaction logic of a master-slave node according to an embodiment of this application. As shown in Figure 12, when each APP module detects that the corresponding business conditions are met, it needs to notify the state machine to enter the corresponding state. Common state switching instructions include: entering / exiting upgrade, entering / exiting calibration, entering / exiting maintenance, entering / exiting driving, entering / exiting parking, entering / exiting auxiliary safety, and other instructions. The SOC slave system state machine sends mode switching instructions to the MCU master system state machine. Common instructions include: entering / exiting normal mode, entering / exiting upgrade mode, entering / exiting calibration mode, entering / exiting maintenance mode, entering / exiting driving mode, entering / exiting parking mode, entering / exiting auxiliary safety mode, and other instructions.

[0121] Optionally, the MCU's master system state machine can perform state transition arbitration after receiving a state transition command. For example, if the master state machine detects that the system transition condition is not met, it maintains the current state; if the master state machine detects that the system transition condition is met, it switches to the new state.

[0122] Optionally, after the MCU's master system state machine switches states, it can synchronize the latest state to the SOC's slave state machine. The SOC's slave state machine then broadcasts the current state to each application. After receiving the system state, each application determines whether it meets expectations and performs corresponding post-processing.

[0123] Next, we will take the OTA APP as an example to further explain the state switching process.

[0124] When the OTA app detects that the ECU voltage is within the normal range, the vehicle speed is less than 5 km / h, and the gear is in P / N, the OTA app can send an "Enter Upgrade" command to the SOC's slave system state machine. Upon receiving the "Enter Upgrade" command, the SOC's slave system state machine can send an "Enter Upgrade Mode" message to the MCU's master system state machine. The MCU's master state machine performs a state switch. If it is currently in calibration mode and receives the OTA upgrade mode switch command, it will maintain calibration mode. If it is currently in sentry mode and receives the OTA mode switch command, and the gear is in P / N and the vehicle speed is less than 5 km / h, it is allowed to switch to OTA mode. Afterwards, the MCU's master system state machine synchronizes the latest state to the SOC's slave system state machine; the SOC's slave system state machine broadcasts the latest state to the app; the app checks if the current system state is the desired state. If the current system state does not meet the requirements, it performs corresponding post-processing, such as logging or providing appropriate user prompts.

[0125] Optionally, based on the master-slave deployment method of the assisted driving system described above in this application, multiple SOCs can also be deployed in the assisted driving system, so that each SOC forms a redundant backup for each other. Figure 13 is a schematic diagram of SOC redundant backup deployment according to an embodiment of this application. In this deployment architecture, multiple SOCs can independently perceive and process their respective task states, but can also work collaboratively and share the state information of the master node MCU. For example, the MCU remains the master node and continues to assume the responsibility for global system state management, including: control and arbitration of power state, basic state, and business state. Multiple SOCs run multiple applications in parallel as slave nodes, while maintaining consistency with the MCU state. When any SOC fails, the other SOCs can take over its tasks to ensure that the system function is not interrupted. Even in a multi-SOC environment, the final decision on state switching is still made by the MCU, which avoids decision conflicts caused by too many slave nodes and ensures the uniformity and security of system state transitions. In order to maintain state consistency, each SOC must periodically exchange state information with the MCU, and SOCs may also need to perform necessary state synchronization to ensure that all slave nodes know the current system state and any upcoming state transitions. In this deployment method, the reliability of the entire driver assistance system is improved by redundant deployment of SOCs, the impact of single point of failure is reduced, and the system can still operate stably when any SOC malfunctions.

[0126] Optionally, based on the master-slave deployment method of the assisted driving system described above in this application, redundancy backup can also be introduced at both the SOC and MCU levels. That is, not only are multiple SOCs deployed, but multiple nodes are also deployed at the MCU level, forming a dual redundancy mechanism. Figure 14 is a schematic diagram of a dual redundancy backup deployment of MCU and SOC according to an embodiment of this application. As shown in Figure 14, multiple MCUs are deployed, one of which serves as the master control center, and the rest as backups. When the master MCU fails, the backup MCUs can quickly take over the responsibility of system state management and maintain system stability. Similarly, multiple SOCs are deployed, and the multiple SOCs are redundant with each other. When any SOC fails, the other SOCs can continue to operate and take over the affected tasks. An efficient state synchronization mechanism can be established between multiple MCUs and multiple SOCs, as well as between each SOC, to ensure that all nodes can obtain system state updates in a timely manner. In a multi-MCU environment, arbitration decisions may first be initially processed by the local MCU, then consensus is reached through negotiation among multiple MCUs, and finally, a certain MCU (usually the one with the best health) uniformly executes the state switch to maintain system consistency. This deployment approach significantly enhances system redundancy and fault tolerance by introducing redundancy at both the MCU and SOC layers. Even in the event of a failure in the main control center or critical modules, the system can still maintain operation through the remaining healthy modules, significantly improving its survivability under extreme conditions and enhancing the user experience.

[0127] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0128] According to an embodiment of this application, an embodiment of a management device for a vehicle's driver assistance system is provided. It should be noted that this device can be used to execute the aforementioned management method for a vehicle's driver assistance system.

[0129] Figure 15 is a schematic diagram of a management device for an assisted driving system in a vehicle according to an embodiment of the present application. As shown in Figure 15, the management device 1500 for the assisted driving system in the vehicle includes: a first control unit 1501, a second control unit 1502, a third control unit 1503, and a fourth control unit 1504.

[0130] The first control unit 1501 is configured to, in response to receiving a state switching request from a target application from the controller, control the slave controller to send the state switching request to the main controller, wherein the target application is any one of multiple applications, and the state switching request is used to request the state of the target application to be switched from the current state to the target state.

[0131] The second control unit 1502 is used to control the main controller to evaluate the current operating status of the driver assistance system and obtain the evaluation results.

[0132] The third control unit 1503 is used to respond to the evaluation result indicating that the assisted driving system meets the state switching conditions, and control the main controller to respond to the state switching request, switch the state of the target application from the current state to the target state, and obtain the state switching result.

[0133] The fourth control unit 1504 is used to control the main controller to synchronize the state switching results to the slave controller.

[0134] Optionally, the second control unit 1502 is also used to: control the main controller to evaluate the power supply status, operation status and business function status respectively, and obtain the evaluation results.

[0135] Optionally, the second control unit 1502 is further configured to: in response to a power supply status indicating that multiple electronic components have sufficient power, an operation status indicating that the driver assistance system is in normal operation, and a business function status indicating that the driver assistance system is in an assisted safety state, determine that the evaluation result indicates that the driver assistance system meets the state switching conditions; and in response to a power supply status indicating that multiple electronic components have insufficient power, an operation status indicating that the driver assistance system is not in normal operation, and a business function status indicating that the vehicle is not in an assisted safety state, determine that the evaluation result indicates that the driver assistance system does not meet the state switching conditions.

[0136] Optionally, the device 1500 is also used to: control the target application to maintain its current state in response to an evaluation result indicating that the driver assistance system has not met the state switching conditions.

[0137] Optionally, the device 1500 is also used to: control the broadcast of state switching results from the controller to multiple applications.

[0138] In the management device for the driver assistance system in the vehicle described in this application, the main controller controls the operating state of the driver assistance system, while the slave controller is used to synchronously obtain the operating state of the driver assistance system from the main controller. In this way, multiple applications installed on the slave controller can also obtain the operating state of the driver assistance system in real time. When the slave controller receives a state switching request from a certain application, it can send the state switching request to the main controller. The main controller will then make further judgments based on the current operating state of the driver assistance system to determine whether the current state switching conditions of the vehicle's driver assistance system are met. If the state switching conditions are met, the main controller will control the application to switch states and synchronize the state switching result to the slave controller. This master-slave interaction mechanism for application state switching significantly reduces the complexity of application state switching, improves the efficiency and safety of state switching, and thus solves the technical problem of complex state switching logic in related technologies.

[0139] Embodiments of this application also provide a vehicle, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods described in various embodiments of this application when it runs.

[0140] Embodiments of this application also provide a computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0141] Embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0142] Embodiments of this application also provide a computer program product, including a non-volatile computer-readable storage medium for storing a computer program that, when executed by a processor, implements the methods in various embodiments of this application.

[0143] Embodiments of this application also provide a computer program that, when executed by a processor, implements the methods described in the various embodiments of this application.

[0144] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0145] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0146] 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 units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0147] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

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

[0149] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A management method for a driver assistance system in a vehicle, characterized in that, The assisted driving system includes a master controller and a slave controller. The master controller controls the operating state of the assisted driving system, and the slave controller synchronously acquires the operating state. Multiple applications are installed on the slave controller. The method includes: responding to the slave controller receiving a state switching request from a target application, controlling the slave controller to send the state switching request to the master controller, wherein the target application is any one of the multiple applications, and the state switching request requests to switch the state of the target application from its current state to a target state; controlling the master controller to evaluate the current operating state of the assisted driving system and obtain an evaluation result; responding to the evaluation result indicating that the assisted driving system meets the state switching conditions, controlling the master controller to respond to the state switching request and switch the state of the target application from its current state to the target state, obtaining a state switching result; and controlling the master controller to synchronize the state switching result to the slave controller.

2. The method according to claim 1, characterized in that, The state switching request is triggered by the target application based on internal preset conditions and / or external operation information, wherein the internal preset conditions are used to characterize the preset rules for the target application to perform state switching, and the external operation information is used to characterize the state switching command from outside the vehicle.

3. The method according to claim 1, characterized in that, The current operating state of the assisted driving system includes at least: the power supply status of multiple electronic components within the assisted driving system, the operation status of the assisted driving system, and the business function status of the assisted driving system. Controlling the main controller to evaluate the current operating state of the assisted driving system and obtain evaluation results includes: controlling the main controller to evaluate the power supply status, the operation status, and the business function status respectively, and obtaining the evaluation results.

4. The method according to claim 3, characterized in that, The main controller is controlled to evaluate the power supply status, the operation status, and the service function status respectively, and obtain the evaluation results, including: in response to the power supply status indicating that the multiple electronic components have sufficient power, the operation status indicating that the driver assistance system is in normal operation status, and the service function status indicating that the driver assistance system is in assisted safety status, determining that the evaluation results indicate that the driver assistance system meets the state switching conditions; in response to the power supply status indicating that the multiple electronic components have insufficient power, the operation status indicating that the driver assistance system is not in the normal operation status, and the service function status indicating that the vehicle is not in the assisted safety status, determining that the evaluation results indicate that the driver assistance system does not meet the state switching conditions.

5. The method according to claim 1, characterized in that, The method further includes: in response to the evaluation result indicating that the driver assistance system has not met the state switching condition, controlling the target application to maintain the current state.

6. The method according to claim 1, characterized in that, The method further includes controlling the controller to broadcast the state switching result to the multiple applications.

7. A vehicle driver assistance system, characterized in that, include: The system comprises a master controller and a slave controller. The master controller controls the operating state of the assisted driving system. The slave controller synchronously acquires the operating state and has multiple applications installed on it. Upon receiving a state switching request from a target application, the slave controller sends the request to the master controller. The target application is any one of the multiple applications. The state switching request requests a change from the current state to a target state for the target application. The master controller evaluates the current operating state of the assisted driving system and obtains an evaluation result. When the evaluation result indicates that the assisted driving system meets the state switching conditions, the master controller, based on the state switching request, switches the state of the target application from the current state to the target state, obtaining a state switching result. The master controller then synchronizes the state switching result to the slave controller.

8. The system according to claim 7, characterized in that, The slave controller is also used to broadcast the state switching result to the multiple applications.

9. A vehicle, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, performs the method according to any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, it controls the device on which the storage medium is located to perform the method according to any one of claims 1 to 6.

Images