Hierarchical power management system and method for a vehicle

Abstract

A power management system and method for a vehicle are provided. The system includes a pre-power-on module and a full-power-on module configured in a controller, the controller being configured to monitor vehicle data; and an operating system (OS) startup module configured in a system-on-a-processor, the system-on-a-processor being configured to run the vehicle's operating system. The pre-power-on module is activated in response to an ignition operation on the vehicle and is configured to: pre-power on at least one of the controller and the system-on-a-processor; acquire state parameters of the vehicle's battery; and activate the full-power-on module in response to determining that the state parameters are normal. The full-power-on module is configured to: fully power on the controller; acquire vehicle data; and activate the OS startup module in response to determining that the vehicle data meets predefined startup conditions. The OS startup module is configured to: cause the system-on-a-processor to play a boot animation in response to being activated.

Description

Technical Field

[0001] This disclosure relates to the field of power supply technology, and more particularly to a hierarchical power management system and method for a vehicle. Background Technology

[0002] With the development of automotive intelligence, in-vehicle intelligent entertainment control systems are playing an increasingly important role in intelligent cockpits.

[0003] The in-vehicle intelligent entertainment control system couples components such as the vehicle's central control screen, sound system (including speakers and amplifiers), internal and external cameras, and various operation buttons to the host unit to achieve functions such as media playback, vehicle navigation, vehicle status monitoring, intelligent interaction, network connectivity, reversing camera, and safety warnings.

[0004] In-vehicle intelligent entertainment control systems typically include an operating system, applications, drivers, application programming interfaces (APIs), databases, and software upgrade mechanisms. The operating system generally uses Linux or Android-based systems to manage various system applications and functions, such as audio and video playback, navigation, voice recognition, and Bluetooth connectivity.

[0005] Operating systems are typically deployed within a System-on-a-Chip (SoC). An SoC integrates all or most of the functionality of an electronic system. It can contain various functional modules such as a CPU (Central Processing Unit), GPU (Graphics Processing Unit), DSP (Digital Signal Processing), memory, and network interfaces, and may also have dedicated hardware accelerators for efficient computing and data processing. SoCs are commonly used in in-vehicle entertainment and infotainment systems, responsible for processing high-speed, complex image and audio data and providing high-performance computing and storage capabilities. For example, in in-vehicle entertainment systems, SoCs can be used to process high-definition video and complex graphical user interfaces, providing a smooth playback experience.

[0006] On the other hand, vehicles are also equipped with MCUs (Microcontroller Units). An MCU is a single-chip microcomputer. Compared to a System-on-a-Chip (SoC), MCUs are typically used in low-power, low-cost applications. For example, MCUs can be used in vehicle control systems such as ECUs (Engine Control Units), braking systems, and BCMs (Body Control Modules), responsible for processing real-time control commands and sensor data, and controlling the operating status of various vehicle systems. For instance, in the engine control unit, the MCU can control parameters such as fuel supply and ignition timing to ensure smooth, economical, and reliable engine operation.

[0007] To ensure the correct startup and shutdown of the MCU, SoC, and the operating system deployed within them, vehicles are equipped with a power management system. Current power management systems are deployed within the SoC and only begin operation after both the MCU and SoC are fully powered on. After the power management system starts, it waits for the SoC and MCU to complete data checks and exchanges before the operating system can boot. This results in a significant delay in the boot animation, boot music, and even the operating system startup. Furthermore, if signal anomalies occur during startup, especially on the MCU side, additional power consumption will result. Summary of the Invention

[0008] One aspect of this disclosure provides a power management system for a vehicle, which may include: a pre-power-on module and a full-power-on module configured in a controller, the controller being configured to monitor vehicle data; and an operating system (OS) startup module configured in a system-on-a-processor, the system-on-a-processor being configured to run the vehicle's operating system. The pre-power-on module may be activated in response to an ignition operation on the vehicle and is configured to: pre-power on at least one of the controller and the system-on-a-processor; acquire state parameters of the vehicle's battery; and activate the full-power-on module in response to determining that the state parameters are normal. The full-power-on module may be configured to: fully power on the controller; acquire vehicle data; and activate the OS startup module in response to determining that the vehicle data meets predefined startup conditions. The OS startup module may be configured to: cause the system-on-a-processor to play a boot animation in response to being activated.

[0009] One aspect of this disclosure provides a power management method for a vehicle, which may include: in response to an ignition operation of the vehicle, activating a pre-power-on module in a controller, the controller being configured to monitor vehicle data; pre-powering at least one of the controller and a system-level processor by the pre-power-on module, wherein the system-level processor is configured to run an operating system of the vehicle; acquiring state parameters of the vehicle's battery by the pre-power-on module; in response to determining that the state parameters are normal, activating a full-power-on module in the controller by the pre-power-on module to fully power on the controller; acquiring vehicle data by the full-power-on module; in response to determining that the vehicle data meets predefined startup conditions, activating an OS startup module in the system-level processor by the full-power-on module; and causing the system-level processor to play a boot animation by the OS startup module. Attached Figure Description

[0010] Figure 1 This diagram shows the power-on process 100 of a conventional vehicle's power management system.

[0011] Figure 2 This diagram shows the timing of the power-down process 200 in a conventional vehicle's power management system.

[0012] Figure 3 A block diagram of an example in-vehicle entertainment control system 300 with an example power management system deployed according to the technology of this disclosure is shown.

[0013] Figure 4 The figure illustrates a timing diagram of an example power-on process 400 of an example in-vehicle entertainment control system 300 of the present disclosure.

[0014] Figure 5 The figure illustrates a timing diagram of an example power-down process 500 of an example in-vehicle entertainment control system 300 of the present disclosure; and

[0015] Figure 6 A block diagram of another example of an in-vehicle entertainment control system 600 according to the technology of this disclosure is shown.

[0016] Figure 7 A flowchart illustrating an example process 700 for data protection of MCU 1 and SoC 2 according to the technology of this disclosure is shown. Detailed Implementation

[0017] Numerous specific details are set forth in the following description. However, it should be understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in detail so as not to obscure the understanding of this description.

[0018] References to "an embodiment," "an embodiment," "an exemplary embodiment," etc., in the specification indicate that the described embodiment may include a specific feature, structure, or characteristic; however, not every embodiment necessarily includes that specific feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Additionally, when a specific feature, structure, or characteristic is described in connection with an embodiment, it is believed that the influence of such feature, structure, or characteristic on such feature, structure, or characteristic in conjunction with other embodiments, whether explicitly described or not, is within the knowledge of those skilled in the art.

[0019] For the purposes of this disclosure, the phrase "A and / or B" means (A), (B), or (A and B). For the purposes of this disclosure, the phrase "A, B, and / or C" means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C). Overview

[0020] The term "vehicle" as described herein can refer to various types of motorized vehicles (e.g., cars, motorcycles, buses, tractors, semi-trailers), rail vehicles (e.g., trains), water vehicles (e.g., boats), aircraft (e.g., airplanes), or spacecraft (e.g., satellites). All such vehicles can incorporate the SoCs and MCUs described herein to implement specific entertainment and control functions.

[0021] The "vehicle data" described in this article refers to the data transmitted between various modules within a vehicle to determine the operational status of the vehicle and its systems. Vehicle data can provide various key information. For example, in automotive applications, vehicle data may include: engine data, such as engine speed, throttle opening, coolant temperature, and oil pressure; vehicle speed data, such as vehicle speed, steering angle, and braking status; body data, such as door status, seat position, and window status; suspension system data, such as suspension travel and spring compression; braking system data, such as brake pedal status and brake disc temperature; safety system data, such as airbag status and ESP (Electronic Stability Program) control status; entertainment system data, such as radio channels and volume; and fuel data, such as fuel level and fuel consumption. This vehicle data can be collected by sensors, control units, and other devices and provided to the MCU via protocols such as CAN (Controller Area Network) and / or Flexray. By monitoring vehicle data, the MCU can understand the real-time status of the onboard systems, including the operating status, error states, and potential problems of various components. Vehicle data can also help the MCU determine the vehicle's driving status and environmental conditions, thereby adjusting the operating mode and power consumption of the onboard system as needed. For example, during driving, the MCU can adjust the engine's workload and energy-saving mode by monitoring data such as vehicle speed and fuel level, thereby achieving more efficient fuel utilization and a longer driving range. Examples of power-on and power-off management systems

[0022] Figure 1 This diagram shows the power-on process 100 of a conventional vehicle's power management system.

[0023] After MCU1 starts up, its operating system MCU_OS 11 notifies the power management system 21 deployed in SoC 2 to start up (notifying "power management system" startup()), and at the same time, SoC 2 starts up. At this time, SoC 2's operating system SoC_OS 23 has not yet started up, the animation module 22 has not yet been loaded, and the system's load current (e.g., from 0A) rises to 0.5A.

[0024] After receiving the startup notification from MCU_OS 11, the power management system 21 notifies the animation module 22 to start (notifies "animation" startup()). At this time, the animation module 22 starts loading the startup animation, but will not play the startup animation until it receives further instructions. This is because the playback of the startup animation requires the vehicle data to meet specific signal conditions, for example, (1) when the driver turns the key or presses the ignition button, the vehicle intelligent entertainment control system (hereinafter sometimes referred to as "vehicle system") starts to supply power. The startup animation can only start playing after the entire system has started up; (2) the vehicle system will perform a self-test during startup, including checking the status of each subsystem, such as the engine, transmission, vehicle communication, etc. If the system finds a fault or abnormality, the startup animation may be canceled or interrupted; (3) the startup animation can only start playing after the system is stable to ensure that there will be no stuttering or abnormality during the playback. The signs of system stability may include stable engine speed, stable vehicle speed, stable power supply, etc.; (4) if the vehicle system uses an LCD screen to play the startup animation, the LCD screen needs to complete the self-test and be ready before it can start playing. These conditions need to be determined using whole vehicle data.

[0025] Therefore, the power management system 21 waits after notifying the animation module 22 to start until it receives a specific signal from the MCU 1 indicating that the conditions for starting the power-on animation are met.

[0026] Upon receiving the specific signal, the power management system 21 determines that the conditions for starting the boot animation are met, and therefore notifies the animation module 22 to play the boot animation (notification "animation" play()).

[0027] During the playback of the power-on animation, the animation module 22 reports this status to the power management system 21 (report play()). At this time, the load current rises to about 1A due to the playback of the power-on animation.

[0028] After the boot animation finishes playing, the power management system 21 can further launch SoC_OS 23 (not shown) to start the operating system.

[0029] During power-on process 100, MCU 1 starts up, and SoC 2 starts up immediately afterward. In other words, MCU 1 and SoC 2 begin consuming battery power almost simultaneously. Therefore, even if MCU 1 detects an anomaly in the vehicle data that prevents the vehicle system from starting (e.g., a fault or anomaly is detected during self-test), SoC 2 will still be unnecessarily started, resulting in additional power consumption. Furthermore, to determine the conditions for starting the boot animation, various vehicle data needs to be continuously received from MCU 1 via inter-domain communication until the vehicle data meets the playback conditions. The more playback conditions there are, the more time is consumed in the interaction between SoC 2 and MCU 1, and the slower the boot animation and SoC_OS 23 start.

[0030] Furthermore, this design cannot change the power-on timing of MCU 1 and SoC 2 as needed, failing to meet the requirements of different manufacturers. For example, some manufacturers require MCU 1 and SoC 2 to power on synchronously, meaning they power on at the same time. In this mode, MCU 1 and SoC 2 can enter the working state simultaneously and begin normal operation. Other manufacturers require MCU 1 and SoC 2 to power on asynchronously, meaning their power-on timing is independent. Typically, MCU 1 will power on first, and SoC 2 will power on after a certain period. However, the existing power management system 21 design cannot meet these different power-on requirements.

[0031] Figure 2 This diagram shows the timing of the power-down process 200 in a conventional vehicle's power management system.

[0032] During normal power-on of SoC 2, the power management system 21 continuously exchanges vehicle data with MCU 1. The vehicle data is obtained by MCU 1 via bus 12, for example, through CAN, Flexray and / or other vehicle communication protocols.

[0033] If the vehicle data contains a specific signal that meets the conditions for shutting down the vehicle system, the power management system 21 notifies the animation module 22 and SoC_OS 23 to prepare for power-down (notifies sleep prepare()). The conditions for shutting down the vehicle system may include, for example: (1) parking state; (2) the vehicle is in a safe state and no faults or abnormalities have occurred; and / or (3) the system is in a stable state and no tasks or operations are being performed, etc.

[0034] After notifying the animation module 22 and SoC_OS 23 to prepare for power-down, the power management system 21 waits until it no longer receives vehicle data from MCU 1, and then notifies the animation module 22 and SoC_OS 23 to power-down.

[0035] In the power-down process 200 described above, the power management system 21 allows SoC 2 to determine whether it has successfully powered down based on vehicle data from MCU1, which is a one-way process. MCU1 cannot determine whether SoC 2 has successfully powered down. Therefore, conventional designs set a timeout period, such as milliseconds to seconds, on the MCU1 side. If the vehicle system is functioning normally, MCU1 starts a countdown timer and waits for the timeout to expire. During this period, the MCU continuously monitors the vehicle system's status using vehicle data. If no vehicle data indicating normal system operation is received within the timeout period (i.e., the countdown timer expires), the vehicle system is considered to be in a powered-off state, and MCU1 triggers a power-down operation. Power-down operations include, for example, shutting down the operating system, releasing resources, and disconnecting the power supply. However, this power-down method requires waiting for the timeout period to elapse. On the one hand, it cannot immediately perform the power-down operation when the power-down conditions are met; on the other hand, there is a possibility of erroneous power-down operations, posing issues of power consumption and safety. Example Power Management System

[0036] This disclosure provides a power management system for vehicles that enables more efficient, energy-saving, and safe power-on and power-off of in-vehicle entertainment control systems. Example implementations of the power management system described below are illustrated with reference to automotive applications. However, it should be understood that this is not intended to limit the application scenarios of the power management system. The power management system of this disclosure can be applied to any vehicle that incorporates a system-on-a-chip (SoC) such as a System-on-Chip (SoC) and a controller such as an Microcontroller Unit (MCU) to implement an in-vehicle entertainment control system.

[0037] Figure 3 A block diagram of an example in-vehicle entertainment control system 300 with an example power management system deployed according to the technology of this disclosure is shown. The power management system of this embodiment is deployed in the vehicle's MCU1 (also referred to as a "controller") and SoC2 (also referred to as a "system-on-a-processor"), including a pre-power-on module 15 and a full-power-on module 16 configured in the MCU1, and an OS boot module 25 configured in the SoC2. The MCU1 and SoC2 can draw power from a battery 5 disposed in the vehicle.

[0038] The pre-power-on module 15, the full power-on module 16, and the OS startup module 25 work together to control the power-on and power-off of MCU 1 and SoC 2, the startup and shutdown of SoC_OS 23, and the playback of the boot animation by the animation module 22.

[0039] The pre-power-on module 15, as the first stage of the power management system, is activated immediately after vehicle ignition. Upon activation, the pre-power-on module 15 puts at least one of the MCU 1 and SoC 2 into a pre-power-on state, including powering on the bus communication module 17. The bus communication module 17 is used to acquire vehicle data, for example, via protocols such as CAN and Flexray.

[0040] Compared to power-on (full power-on), pre-power-on can not only power on the bus communication module 17, but also gradually initialize the registers and circuits inside MCU 1 and / or SoC 2, ensuring that MCU 1 and / or SoC 2 can start and run normally in the correct state, avoiding abnormal operation, data errors and system failures caused by uninitialized registers and circuits. Pre-power-up operations may include, for example,: powering on peripheral devices of MCU 1 and / or SoC 2, such as memory, clock, AD converter, DA converter, etc.; verifying power supply voltage stability to ensure that the power supply voltage to MCU 1 and / or SoC 2 is stable and meets the set requirements, avoiding abnormal operation of MCU 1 and / or SoC 2 due to unstable power supply voltage; initializing the internal clock circuit of MCU 1 and / or SoC 2 to ensure that MCU 1 and / or SoC 2 can use the clock normally for operation and timing; initializing the input / output (I / O) ports of MCU 1 and / or SoC 2, including setting the input / output mode, input level, and output level of the pins; initializing the system clock source, including setting the clock division factor and clock frequency; and initializing the interrupt controller of MCU 1 and / or SoC 2, including setting the interrupt priority and interrupt triggering mode. In the pre-power-up state, the load current of MCU 1 and / or SoC 2 is small, for example, about 0.1A. In the fully powered-on state, the load current of MCU 1 and / or SoC 2 is greater than that in the pre-power-on state, for example, greater than 0.5A, greater than 1A, greater than 2A, or higher.

[0041] In some embodiments, the pre-power-on module 15 can pre-power on MCU 1 and SoC 2 based on a predetermined timing sequence. For example, the pre-power-on module 15 can pre-power on MCU 1 and SoC 2 simultaneously, or asynchronously according to a specified sequence and time interval. Different pre-power-on timing sequences can be set according to the requirements of different manufacturers. In other words, the timing sequence is changeable. In some embodiments, MCU 1 can be pre-powered on before vehicle ignition. In this case, the predetermined timing sequence can be applied only to SoC 2.

[0042] After completing the pre-power-on of MCU 1 and / or SoC 2, the pre-power-on module 15 monitors the status parameters of battery 5. These status parameters may include temperature and voltage, which can be obtained via sensors 3 located within battery 5. By monitoring the status parameters of battery 5, the pre-power-on module 15 can avoid performing a full power-on operation when the power supply system is in an abnormal state.

[0043] If the pre-power-on module 15 determines that the status parameters of the battery 5 are normal, it can notify the full power-on module 16 of this status. If the status parameters of the battery 5 are abnormal, it will not send a notification to the full power-on module 16 to allow full power-on.

[0044] The full power-on module 16, acting as the second stage of the power management system, is coupled to the pre-power-on module 15. Upon receiving a notification from the pre-power-on module 15 allowing full power-on, the full power-on module 16 fully powers on the MCU 1. Subsequently, the full power-on module 16 acquires the vehicle's overall data from the bus communication module 17. If the full power-on module 16 determines that the vehicle data meets predefined startup conditions, it notifies the OS startup module 25 of this condition to allow the startup of SoC_OS 23 and the boot animation.

[0045] The predefined startup conditions include, for example: (1) normal power supply voltage; (2) normal status of each subsystem, such as engine, transmission, vehicle communication, etc.; (3) stable engine speed, stable vehicle speed, stable power supply, etc.; (4) the display has completed self-test and is ready. Startup conditions can be set arbitrarily according to the manufacturer's requirements. Different startup conditions can be achieved by monitoring different vehicle data.

[0046] If the vehicle data does not meet the startup conditions, the fully powered-on module 16 can continue to monitor the vehicle data until the startup conditions are met. In some embodiments, the fully powered-on module 16 may also request power-off from the pre-power-on module 15 after the vehicle data has not met the startup conditions for a certain period of time.

[0047] The OS boot module 25 is started based on a notification from the full power-on module 16. The OS boot module 25 is used to start the operating system of SoC 2 (i.e., SoC_OS 23, such as Android, QNX, etc.) and control the animation module 22 to play the boot animation.

[0048] Since the vehicle data already meets the conditions for playing the boot animation when the startup notification is received from the fully powered-on module 16, the OS startup module 25 can immediately notify the animation module 22 to start playing the boot animation after startup, without needing to refer to... Figure 1 As described, it requires waiting to receive specific vehicle data. The OS startup module 25 can start the SoC_OS23 after the boot animation has finished playing.

[0049] In this embodiment, although the power-on module 16 needs to acquire vehicle data to determine the startup conditions, it is not necessary to send the vehicle data to the SoC 2 side via inter-domain communication as in the past. Compared to the previous method that required inter-domain communication... Figure 1 As shown, this embodiment can significantly shorten the time for vehicle data transmission, thereby advancing the playback time of the boot animation. Example power-on process

[0050] Figure 4 The figure illustrates a timing diagram of an example power-on process 400 of an example in-vehicle entertainment control system 300 of the present disclosure. The process 400 includes the following steps:

[0051] (1) When the vehicle is ignited, the pre-power-on module 15 is first activated and pre-powers on at least one of the MCU 1 and SoC 2. After the pre-power-on is completed, the load current is, for example, about 0.1A.

[0052] (2) After the pre-power-on is completed, the pre-power-on module 15 obtains the status parameters (such as voltage and temperature) of the battery 5. If the status parameters meet the conditions, it notifies the full power-on module 16 to start.

[0053] (3) After the fully powered-on module 16 starts up, it fully powers on the MCU 1, and the load current rises to about 0.5A, for example.

[0054] (4) The fully powered-on module 16 acquires the vehicle data and, when the vehicle data meets the predefined startup conditions, notifies the OS startup module 25 on the SoC 2 side to start.

[0055] (5) After the OS startup module 25 starts, it notifies the animation module 22 to play the startup animation.

[0056] (6) During the playback of the power-on animation by the animation module 22, the OS startup module 25 may request status information from the fully powered-on module 16. The status information may be generated based on vehicle data and indicates whether the conditions for starting the operating system, i.e., SoC_OS23, are met. Due to the playback of the power-on animation, the load current may rise to, for example, 1A.

[0057] (7) The fully powered-on module 16 then reports the status information to the OS boot module 25.

[0058] (8) Upon receiving the status information from the fully powered-on module 16, and confirming that the conditions for starting the operating system are met, the OS startup module 25 calculates the application states of the applications in the operating system. For example, it can calculate the various applications that were running when the operating system was last shut down, such as music players, navigation systems, and communication applications. Calculating the application states allows the system to read the status information of these applications upon the next operating system startup, enabling automatic restoration to the previous application state. This allows the user to immediately continue their previous tasks after the operating system starts, without needing to reconfigure and reopen applications.

[0059] (9) After calculating the application status, the OS startup module 25 reports the application status to the fully powered-on module 16. This is because some applications may need to interact with MCU 1 so that MCU 1 can update and coordinate the operation of various vehicle subsystems accordingly. For example, if the navigation system application was running before the last system shutdown and recorded destination information, then the OS startup module 25 can report this application information to MCU 1 so that MCU 1 can set the target location of the navigation system to the destination at the time of the last parking. Preferably, steps (6) to (9) can be performed during the boot animation playback.

[0060] (10) After reporting the application status to the fully powered-on module 16 and completing the boot animation, the OS boot module 25 can start the SoC_OS 23 to boot the vehicle operating system (Android, QNX, etc.).

[0061] (11) As SoC_OS 23 and operating system applications are launched, the load current increases further, for example, to about 2A.

[0062] According to this embodiment, during the startup process of system 300, at least one of MCU 1 and SoC 2, for example, MCU 1, can be pre-powered to monitor the status of battery 5. After MCU 1 is fully powered on, vehicle data is detected first. Only when the vehicle data meets the conditions is the OS startup module 25 of SoC 2 activated to further power on SoC 2 and play the boot animation. Compared to Figure 1The power-on process 100 shown does not require time-consuming inter-domain communication to transmit vehicle data to SoC 2. Compared to the internal communication of MCU 1, the communication paths between different processor cores and peripherals within SoC 2 may be longer than those within MCU 1, leading to increased signal transmission latency. Furthermore, multiple processor cores and peripherals in SoC 2 share the same silicon chip, which may interfere with each other, such as with electromagnetic interference (EMI). This interference degrades signal transmission quality, increasing communication time. In SoC 2, different processor cores and peripherals may use different communication protocols, requiring protocol conversion, which also increases communication latency. Additionally, multiple processor cores and peripherals in SoC 2 may compete for the same bus or memory resources, further increasing communication latency. In contrast, the internal communication paths of MCU 1 are relatively short, have less interference, and do not require protocol conversion or resource contention, resulting in lower communication latency. This embodiment significantly shortens communication time by determining battery status parameters and vehicle data on the MCU 1 side. This allows the boot animation to start playing and the operating system to load immediately after the SoC 2 is powered on, without waiting for the vehicle data to meet the startup conditions on the SoC 2 side. Consequently, this reduces the power consumption of the SoC 2 caused by waiting for the vehicle data to reach the startup conditions. For users, the faster communication speed allows them to view the boot animation sooner.

[0063] Furthermore, the pre-power-on module 15 can arbitrarily set the pre-power-on timing as needed, such as pre-powering MCU 1 and SoC 2 simultaneously, asynchronously powering them on in any timing sequence (order or time interval), or pre-powering only MCU 1. When MCU 1 is already pre-powered on, the pre-power-on module 15 simply maintains this state. Example of power-off process

[0064] Figure 5 The figure illustrates a timing diagram of an example power-down process 500 of an example in-vehicle entertainment control system 300 according to the present disclosure. In this embodiment, as an example, it is shown that the SoC_OS 23 includes two operating systems: Android 231 and QNX 232.

[0065] Typically, Android 231 handles the application layer of in-vehicle infotainment systems, including media playback, navigation, Bluetooth calling, and voice recognition. Android 231 also provides a wealth of third-party applications for users. QNX 232 is responsible for vehicle safety and real-time control systems. QNX 232 is a real-time operating system with robust real-time performance and reliability, ensuring vehicle safety and reliability. QNX 232 is commonly used in in-vehicle electronic control units (ECUs) and automotive network communications, such as engine control units, braking systems, airbag systems, and body control.

[0066] In this embodiment, the Android 231 can be powered down first, followed by the QNX 232. This is because the Android 231 is responsible for the application layer of the in-vehicle infotainment system and requires a longer shutdown time to save data and close applications, while the QNX 232 is responsible for the vehicle safety and real-time control system, and its shutdown time is relatively short. Furthermore, the QNX 232 is a real-time operating system with strong real-time performance and reliability; during shutdown, it is necessary to ensure that all tasks and interrupts can respond promptly. If the QNX 232 is powered down first, it may affect the vehicle's real-time control and safety.

[0067] After the application and operating system have finished executing their commands, the hardware should be shut down—that is, the SoC 2 should be powered off. This is because the application and operating system save data to storage devices during the shutdown process to prevent data corruption. The hardware needs to wait until the application and operating system have shut down before being powered off to avoid data corruption and other problems.

[0068] Reference Figure 2 In the described power-down process 200, after the power management system 21 detects a sleep signal in the vehicle data that meets the power-down conditions, it notifies the animation module 22 and SoC_OS 23 to prepare for shutdown. The animation module 22 and SoC_OS 23 are only allowed to shut down after no more vehicle signals are received from MCU 1. As described above, after the animation module 22 and SoC_OS 23 shut down, SoC 2 is not powered down. MCU 1 needs to continuously receive no vehicle data indicating normal operation of the vehicle system within the timeout period (i.e., the countdown timer expires) before performing the power-down operation on SoC 2. Furthermore, the transmission of vehicle signals via inter-domain communication between MCU 1 and SoC 2 also suffers from communication time consumption issues.

[0069] In this embodiment, the power-down condition is determined on the MCU 1 side. Specifically, the full power-on module 16 of MCU 1 determines whether the vehicle data meets the predetermined power-down conditions. After the power-down conditions are met, the full power-on module 16 can notify the OS startup module 25 to shut down the operating system, for example, by sending a shutdown instruction.

[0070] Once the OS startup module 25 receives the shutdown instruction from the full power-on module 16, it can shut down the operating system, i.e., SoC_OS 23, and the animation module 22 without monitoring the vehicle data through inter-domain communication.

[0071] After SoC_OS 23 and animation module 22 are shut down, OS startup module 25 shuts down and no longer sends heartbeat signals to power-on module 16 periodically. Regarding the heartbeat signal, in the vehicle electronic system, SoC 2 and MCU 1 are two independent processors. To avoid communication failure, SoC 2 periodically sends heartbeat signals to MCU 1 during operation. The heartbeat signal tells MCU 1 that SoC 2 is working and sending data normally. If MCU 1 does not receive the heartbeat signal, it indicates that SoC 2 may have malfunctioned or communication has been interrupted. MCU 1 can then take appropriate measures, such as re-establishing the communication connection or taking other corrective actions. In this embodiment, if SoC 2 no longer receives heartbeat signals from OS startup module 25 after sending the shutdown instruction, it can be determined that the operating system on the SoC 2 side has been shut down. Therefore, at least one of SoC 2 and MCU 1 can be powered down according to a predetermined and changeable timing sequence, such as synchronous power-down or asynchronous power-down. The asynchronous power-down timing can be set as needed and is changeable.

[0072] Therefore, the example power-off process 500 of this embodiment may include the following steps:

[0073] (1) When the user performs power-off operations such as turning off the engine, the pre-power-on module 15 can sense a significant change in the status parameters, such as the loss of some or all of the status parameters.

[0074] (2) The pre-power-on module 15 notifies the full-power-on module 16 of a significant change in the sensed status parameters.

[0075] (3) The fully powered-on module 16 then determines whether the vehicle data meets the predefined power-off conditions. Power-off conditions may include, for example, the battery voltage dropping to a safe range, the vehicle speed being zero, and / or the engine being shut down.

[0076] (4) After the fully powered-on module 16 determines that it can be powered off based on the vehicle data, it sends a shutdown instruction to the OS startup module 25 on the SoC 2 side.

[0077] (5) After receiving the shutdown instruction, the OS startup module 25 notifies the SoC_OS 23 and the animation module 22 (illustration omitted) to shut down.

[0078] (6) After receiving the shutdown instruction from the OS startup module 25, SoC_OS 23 can first shut down Android 231 as described above and then notify the OS startup module 25 after Android 231 has been shut down.

[0079] (7) After Android 231 is shut down, OS startup module 25 instructs QNX 232 to shut down.

[0080] (8) After instructing QNX 232, the OS startup module 25 no longer sends a heartbeat signal to the fully powered-on module 16.

[0081] (9) After the fully powered-up module 16 determines that it no longer receives a heartbeat signal from the OS startup module, it can power down MCU 1 and SoC 2, for example, it can power down at least one of MCU 1 and SoC 2 based on a predetermined and changeable timing.

[0082] By employing the power-down process 500 of this embodiment, the full power-on module on the MCU 1 side determines whether the conditions for shutting down the operating system are met based on vehicle data, eliminating the need to transmit vehicle data to the SoC 2 side via relatively time-consuming inter-domain communication. Furthermore, the full power-on module 16 can power down MCU 1 and / or SoC 2 immediately after not receiving a heartbeat signal from the OS startup module 25, without waiting for a timeout period as before. This improves the speed of system shutdown and power-down while avoiding the risk of accidental power-down.

[0083] The power management system disclosed herein adopts a three-layer structure consisting of a pre-power-on module 15, a full power-on module 16, and an OS boot module 25. Besides effectively improving the speed and safety of system startup / shutdown, boot animation playback, and power-on / off of MCU 1 and SoC 2, it also facilitates later maintenance and troubleshooting. Previous power management systems, lacking this layered structure, required maintenance personnel to spend significantly more time sifting through extensive log file code to locate problems. However, according to the technology of this disclosure, maintenance personnel can easily pinpoint the location of the problem within the pre-power-on module 15, full power-on module 16, and OS boot module 25 by examining the log files. Variations

[0084] Figure 6 A block diagram of another example in-vehicle entertainment control system 600 according to the technology of this disclosure is shown. In this embodiment, MCU 1 further includes a data protection module 18 (second data protection module), and SoC 2 further includes a data protection module 25 (first data protection module). Additionally, a peripheral interface 24 of SoC 2 is also shown.

[0085] Peripheral interface 24 is used to enable connectivity and data processing between SoC 2 and various peripherals (such as sensors, actuators, etc.), as well as to facilitate interconnection between internal modules. This includes various interface standards and protocols, such as CAN, LIN, Ethernet, USB, etc., and various processor cores and memory controllers. An example of peripheral interface 24 is PITS (Peripherals and Interconnect Technology Suite). Configuration words can be written to SoC 2 through peripheral interface 24.

[0086] As an example implementation, a specific tool or software package can be used to generate the configuration word, such as a configuration program written in C. This program generates a binary file containing the configuration word data to be written to the SoC 2. The binary file is then transferred to the SoC 2 via USB or another interface. In the SoC 2, the PITS can be accessed using specific registers or memory-mapped addresses to write the configuration word data to specific registers or memory locations. A specific instruction or protocol triggers the PITS write operation, causing it to write the configuration word data to the corresponding register or memory location on the SoC 2. After the write operation is complete, verification is required to ensure that the configuration word data has been written correctly. This can be done by reading the value of the corresponding register or memory location and comparing it with the expected configuration word data to verify the correctness of the write operation.

[0087] After writing the configuration word, sometimes a restart of SoC 2 and / or MCU 1 is required for the changes to take effect, depending on the configuration word written. For example, if the configuration word relates to the hardware or software configuration of SoC 2 and / or MCU 1, such as clock, I / O, a restart of SoC 2 and / or MCU 1 may be necessary for the configuration word to take effect. Furthermore, if an abnormality is detected in SoC 2 and / or MCU 1 after writing the configuration word, a restart of SoC 2 and / or MCU 1 is also required to restore normal operation of SoC 2 and MCU 1.

[0088] In this embodiment, data protection modules 18 and 25 are used to protect the data of MCU1 and SoC2 before shutting down or restarting the operating system SoC_OS 23. Figure 7 A flowchart illustrating an example process 700 for data protection of MCU 1 and SoC 2 according to the technology of this disclosure is shown.

[0089] In box 702, the OS boot module 25 determines whether or not to shut down or restart SoC_OS 23. Shutting down or restarting SoC_OS 23 may be due to receiving a restart request from peripheral interface 24, for example, because a configuration word requiring a restart of the operating system has been written; it may also be because an abnormal state of SoC_OS 23 or its applications is detected, or it may be due to... Figure 5 The process 500 shown requires shutting down SoC_OS 23, or for other reasons. In this case, before shutting down or restarting SoC_OS 23, OS startup module 25 instructs data protection module 25 to perform data protection for SoC 2. For example, data protection module 25 can save and protect some data, such as runtime state and configuration data, to prevent this data from being cleared or destroyed due to restart or shutdown operations, leading to abnormal system conditions.

[0090] Next, in block 704, OS startup module 25 sends a data protection command to fully powered-on module 16 to instruct data protection to be performed on the MCU 1 side.

[0091] In block 706, after the fully powered-on module 16 receives the data protection command, it causes the data protection module 18 to perform data protection on the MCU 1 side.

[0092] According to the power management system of this embodiment, when the operating system SoC_OS 23 needs to be shut down or restarted due to reasons such as writing configuration words, system abnormality, or system shutdown, data protection can be performed on MCU 1 and SoC 2 respectively before shutting down SoC_OS 23, which can effectively prevent data loss or damage.

[0093] Previous power management systems lacked the capability to protect the data of MCU1 and SoC2 before the operating system shuts down. Therefore, if data corruption occurred during the next system startup, data recovery was required, shortening the lifespan of MCU1 and SoC2. This embodiment proactively protects the data of MCU1 and SoC2 before the operating system shuts down, reducing such data recovery operations and thus extending the lifespan of MCU1 and SoC2.

[0094] One or more aspects of at least one embodiment may be implemented by representational instructions stored on a machine-readable medium, representing various logic in a processor, which, when read by one or more processors, cause the one or more processors to implement logic for performing the techniques described herein. In some embodiments, these representational instructions may be loaded into the MCU 1 and SoC 2 described herein to implement the reference... Figures 4-5 The described process and its variations.

[0095] Such machine-readable storage media can include, but are not limited to, non-transitory tangible arrangements of articles made or formed by a machine or device, including storage media such as: hard disks; any other type of disk, including floppy disks, optical disks, read-only optical disk storage (CD-ROM), read-write optical disk storage (CD-RW), and magneto-optical disks; semiconductor devices such as read-only memory (ROM), random access memory (RAM) such as dynamic random access memory (DRAM) and static random access memory (SRAM), erasable programmable read-only memory (EPROM), flash memory, electrically erasable programmable read-only memory (EEPROM); phase-change memory (PCM); magnetic cards or optical cards; or any other type of medium suitable for storing electronic instructions.

[0096] The preferred embodiments of the present invention have been described in detail above. However, it should be understood that the present invention can be implemented and modified in various ways without departing from its broad spirit and scope. Those skilled in the art can make many modifications and variations based on the concept of the present invention without creative effort. Therefore, all technical solutions that can be obtained by those skilled in the art based on the concept of the present invention through logical analysis, reasoning, or limited experimentation on the basis of the prior art should fall within the protection scope defined by the claims of the present invention.

Claims

1. A power management system for a vehicle, comprising: A pre-power-on module and a fully powered-on module are configured in a controller, which is configured to monitor the vehicle's overall data. as well as An operating system (OS) boot module is configured in a system-level processor, which is configured to run the operating system of the vehicle. The pre-power-on module is activated in response to an ignition operation of the vehicle and is configured to: Pre-power on at least one of the controller and the system-level processor; Obtain the state parameters of the vehicle's battery; and In response to the determination that the status parameters are normal, the full power-on module is started. The fully powered-on module is configured to: Power on the controller fully; Obtain the vehicle data; and In response to the determination that the vehicle data meets the predefined startup conditions, the OS startup module is started. The OS boot module is configured to, in response to being started, cause the system-level processor to power on and play a boot animation.

2. The power management system of claim 1, wherein, The pre-power-on module is further configured to pre-power on at least one of the controller and the system-level processor based on a predetermined and variable first timing.

3. The power management system of claim 1, wherein, The pre-power-on module is further configured to power on the bus communication module of the controller, wherein the bus communication module is used to acquire the vehicle data.

4. The power management system of claim 1, wherein, The load current of the controller and the system-level processor after pre-power-on is less than the load current after full power-on.

5. The power management system of claim 1, wherein, The OS boot module is further configured to: During the boot animation playback The system requests status information from the fully powered-on module, wherein the status information is generated based on the vehicle data and indicates whether the conditions for starting the operating system are met. In response to the received status information indicating that the conditions for starting the operating system are met, the application status of the application in the operating system is calculated; The calculated application status is sent to the fully powered-on module; and In response to sending the application status and the completion of the boot animation, the operating system is launched.

6. The power management system of claim 1, wherein, The fully powered-on module is further configured to: In response to the vehicle data meeting predefined power-down conditions, a shutdown instruction is sent to the OS startup module; and In response to no longer receiving a heartbeat signal from the OS boot module, at least one of the controller and the system-level processor is powered down based on a predetermined and variable second timing. The OS boot module is further configured to: In response to receiving a shutdown instruction from the fully powered-on module, the operating system is shut down.

7. The power management system of claim 1, wherein, The system-level processor further includes a first data protection module, and the controller further includes a second data protection module. The OS boot module is further configured to: Before shutting down or restarting the operating system, the first data protection module is instructed to perform data protection for the system-level processor; and Send a data protection command to the fully powered-on module. The fully powered-on module is further configured to: In response to receiving the data protection instruction, the second data protection module is caused to perform data protection for the controller.

8. A power management method for a vehicle, comprising: In response to an ignition operation on the vehicle, a pre-power-on module in the controller is activated, the controller being configured to monitor the vehicle's overall data; The pre-power-on module pre-powers on at least one of the controller and the system-level processor, wherein the system-level processor is configured to run the operating system of the vehicle. The pre-power-on module obtains the status parameters of the vehicle's battery. In response to the determination that the status parameter is normal, the pre-power-on module activates the full power-on module in the controller to fully power on the controller; The vehicle data is acquired by the fully powered-on module; In response to the determination that the vehicle data meets predefined startup conditions, the fully powered-on module starts the OS startup module in the system-level processor; and The OS boot module causes the system-level processor to power on and play a boot animation.

9. The power management method of claim 8, wherein, The pre-power-on module pre-powers on at least one of the controller and the system-level processor based on a predetermined and variable first timing.

10. The power management method of claim 9, wherein, Also includes: The pre-power-on module powers on the bus communication module of the controller, wherein the bus communication module is used to acquire the vehicle data.

11. The power management method of claim 9, wherein, Also includes: During the boot animation playback The OS startup module requests status information from the fully powered-on module, wherein the status information is generated based on the vehicle data and indicates whether the conditions for starting the operating system are met; In response to the received status information indicating that the conditions for starting the operating system are met, the OS startup module calculates the application status of the applications in the operating system; The OS startup module sends the calculated application status to the power-on module; as well as In response to the sending of the application status and the completion of the boot animation, the operating system is launched by the OS startup module.

12. The power management method of claim 9, wherein, Also includes: In response to the vehicle data meeting the predefined power-down conditions, the fully powered-on module sends a shutdown instruction to the OS startup module; In response to no longer receiving a heartbeat signal from the OS boot module, the full power-up module powers down at least one of the controller and the system processor based on a predetermined and variable second timing. as well as In response to receiving a shutdown instruction from the fully powered-on module, the OS startup module shuts down the operating system.

13. The power management method of claim 9, wherein, Also includes: Before shutting down or restarting the operating system, the OS boot module instructs the first data protection module of the system-level processor to perform data protection for the system-level processor. The OS boot module sends a data protection command to the fully powered-on module; In response to receiving the data protection command, the full power-on module causes the second data protection module of the controller to perform data protection for the controller.

14. A non-transient computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform the method as described in any one of claims 9 to 13.

Images