Power supply collaborative management method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention relates to the technical field of power supplies, and discloses a power supply collaborative management method and device, electronic equipment and a storage medium. According to the embodiment of the invention, on one hand, a high-computing-power task can be independently operated in a Shutdown Prepart stage and is isolated from a real-time task in an IG ON state, so that jamming is avoided, vehicle resources can be optimized, and system fluency is improved; for example, OTA upgrading can be executed in the background of the stage, and the final operation before the user quits the vehicle-mounted terminal is not affected. And on the other hand, part of unnecessary peripherals (such as backlight, WIFI and the like) can be closed in the Shutdown Prepart stage, only core computing resources are reserved, the power consumption is reduced by about 30% compared with the IG ON state, meanwhile, high-computing-power tasks can be efficiently completed, and the power consumption and task efficiency of the vehicle machine are balanced.

Description

Technical Field

[0001] This invention relates to the field of power supply technology, and in particular to a power supply collaborative management method, device, electronic device, and storage medium. Background Technology

[0002] In traditional automotive power management architectures, the power modes of in-vehicle infotainment systems are mainly divided into IG ON (working state), STR (memory hibernation), and DeepSleep (deep hibernation). In IG ON mode, the infotainment system needs to respond to user interactions in real time (such as navigation and audio / video control). At this time, running computationally intensive applications (such as OTA upgrades or AI-generated video scans) will cause system lag and interaction delays due to the excessive consumption of CPU, memory, and bus resources. In STR / DeepSleep mode, the system enters a low-power mode, peripherals are powered off or the clock frequency is reduced, preventing computationally intensive tasks from running.

[0003] In view of this, the existing technology has at least the following problems:

[0004] 1. Resource contention causes system lag.

[0005] High-performance computing applications (such as OTA firmware upgrades which require reading and writing to storage, and AI processing which requires high-performance computing chip load) are prone to resource contention when running in parallel with real-time interactive tasks in IG ON state, leading to lag in the vehicle interface, delayed function response, or even system crashes.

[0006] 2. Conflict between power consumption control and task execution

[0007] If a high-performance computing task is forcibly run after IG OFF (such as a silent background upgrade), it may cause abnormal power consumption of the whole vehicle due to the continuous wake-up of system peripherals (such as storage controllers and CPUs), increasing the risk of battery drain. Summary of the Invention

[0008] The purpose of this invention is to provide a power collaborative management method, device, electronic device and storage medium, which can at least optimize vehicle system resources, improve system smoothness and balance vehicle system power consumption and task efficiency.

[0009] To address the aforementioned technical problems, in a first aspect, the present invention provides a power coordination management method, which is at least applicable to multi-system power coordination management scenarios in vehicle cockpit controllers;

[0010] The power collaborative management method includes at least the following:

[0011] In response to the MCU's intention to enter the ON phase, the MCU detects whether the vehicle network meets the preset sleep conditions.

[0012] When the vehicle network does not meet the preset sleep conditions, a keyon signal is sent out through the MCU.

[0013] In response to QNX receiving the keyon signal, QNX switches its own state to the ON stage and sends a startup success notification to the MCU. At the same time, QNX detects the Android virtual machine state and, based on the Android virtual machine state, at least starts or wakes up the Android virtual machine. Additionally, QNX forwards the keyon signal to the Android CPMS.

[0014] In response to Android receiving the keyon signal, Android switches its own state to the ON stage and sends a startup success notification to the MCU at least once. At the same time, the CPMS status is sent to QNX.

[0015] After QNX switches its state to the ON stage for a preset period of time, the CPMS state is detected by QNX. If the CPMS state is not in the ON stage, the Android virtual machine is restarted by QNX.

[0016] Specifically, the MCU intending to enter the ON phase is at least the MCU intending to enter the ON phase from the ShutdownPrepare phase; during the ShutdownPrepare phase, the vehicle cabin shuts down at least one peripheral device but retains core computing resources to at least meet the independent operation of preset computing tasks during the ShutdownPrepare phase.

[0017] Optionally, it may also include at least:

[0018] In response to the MCU intending to enter the ShutdownPrepare stage, the MCU detects whether the vehicle network meets the preset sleep conditions.

[0019] When the vehicle network meets the preset sleep conditions, it sends a ShutdownPrepare signal through the MCU and starts the Android power-down request timer.

[0020] In response to QNX receiving the ShutdownPrepare signal, the ShutdownPrepare signal is forwarded to Android CPMS via QNX;

[0021] In response to Android receiving the ShutdownPrepare signal, Android sends a ShutdownPrepare notification to at least the registered listening applications and system services, and at the same time sends an Android power-off request to the MCU.

[0022] If the MCU does not receive the Android power-out request within the time period of the Android power-out request timing, the MCU releases the network and stops sending NM messages.

[0023] When the MCU receives the Android power-out request during the Android power-out request time period, the MCU replies with an ack signal to the Android and starts the forced release timer.

[0024] In response to Android receiving the ack signal, Android stops sending the Android power-off request, and on the Android side, the application's business processing is preset to complete, and Android sends a release request notification to the MCU.

[0025] When the MCU receives the release request notification or the forced release timer expires, the MCU stops sending NM messages.

[0026] Optionally, it may also include at least:

[0027] In response to the MCU's intention to enter the STR phase, the MCU pulls the strio pin high and sends the keystr signal externally;

[0028] The strio pin is identified by QNX. When the strio pin is high, an off signal is sent to AndroidCPMS via QNX, and the shutdown timeout timer is started.

[0029] In response to Android receiving the off signal, the system broadcasts the off signal to all applications via Android, shuts down the device after the registered party replies with the off signal, and starts an off timeout timer to force a shutdown after the off timeout timer expires.

[0030] In response to Android successfully shutting down within the shutdown timeout period or the shutdown timeout period ending, Android is restarted via QNX, and then a restart success notification is sent to the MCU and QNX after Android restarts.

[0031] In response to QNX receiving the restart success notification, QNX forwards the keystr signal to AndroidCPMS and starts the QNXstr timeout.

[0032] In response to Android receiving the keystr signal, Android broadcasts str to all applications, shuts down the device after the registrant replies with str, and starts a str timeout countdown to force a shutdown after the str timeout countdown ends;

[0033] In response to Android successfully shutting down within the time period of the str timeout, or the str timeout ending, or the QNXstr timeout ending, a self-memory hibernation operation is performed through QNX, and the pmicio pin is pulled high after the hibernation is successful.

[0034] The MCU detects whether the pmicio pin is high. If it is high, the MCU memory sleep operation is executed; if it is low, a power-on / power-off operation is performed on QNX and Android until the pmicio pin is high and the MCU memory sleep operation is executed.

[0035] Optionally, the step of detecting the Android virtual machine state via QNX and, based on the Android virtual machine state, at least starting or waking up the Android virtual machine specifically includes:

[0036] The Android virtual machine status is detected using QNX;

[0037] When the Android virtual machine is in an off state, a virtual machine start-up operation is performed on the Android virtual machine via QNX;

[0038] When the Android virtual machine is in the str state, a virtual machine wake-up operation is performed on the Android virtual machine via QNX.

[0039] Based on the same concept, in a second aspect, the present invention also provides a power coordination management device for performing the power coordination management method described in any one of the first aspects;

[0040] The power coordination management device includes at least an ON phase module;

[0041] The ON phase module is at least used to respond to the MCU's intention to enter the ON phase by detecting whether the vehicle network meets preset sleep conditions through the MCU; when the vehicle network does not meet the preset sleep conditions, the MCU sends a keyon signal; in response to the QNX receiving the keyon signal, the QNX switches its own state to the ON phase and sends at least a startup success notification to the MCU, while simultaneously detecting the Android virtual machine state through the QNX and, based on the Android virtual machine state, at least starting or waking up the Android virtual machine, and forwarding the keyon signal to the Android CPMS; in response to the Android receiving the keyon signal, the Android switches its own state to the ON phase and sends at least a startup success notification to the MCU, while simultaneously sending the CPMS state to the QNX; after a preset period of time after the QNX switches its own state to the ON phase, the QNX detects the CPMS state, and if the CPMS state is not in the ON phase, the QNX restarts the Android virtual machine.

[0042] Optionally, it may also include at least a ShutdownPrepare phase module;

[0043] The ShutdownPrepare phase module is at least used to respond to the MCU's intention to enter the ShutdownPrepare phase by detecting whether the vehicle network meets the preset sleep conditions via the MCU; when the vehicle network meets the preset sleep conditions, the MCU sends a ShutdownPrepare signal and starts the Android power-down request timer; in response to QNX receiving the ShutdownPrepare signal, QNX forwards the ShutdownPrepare signal to AndroidCPMS; in response to Android receiving the ShutdownPrepare signal, Android sends a Shutdown request to at least the registered listening applications and system services. The system sends an wnPrepare notification and simultaneously sends an Android power-off request to the MCU. If the MCU does not receive the Android power-off request within the time period of the Android power-off request, the MCU releases the network and stops sending NM messages. If the MCU receives the Android power-off request within the time period of the Android power-off request, the MCU replies with an ack signal to Android and starts a forced release timer. In response to Android receiving the ack signal, Android stops sending the Android power-off request and, on the Android side, presets the application's service processing to complete and sends a release request notification to the MCU. When the MCU receives the release request notification or the forced release timer ends, the MCU stops sending NM messages.

[0044] Optionally, it may also include at least the STR stage module;

[0045] The STR phase module is at least used to respond to the MCU's intention to enter the STR phase by pulling the strio pin high and sending a keystr signal; identifying the strio pin via QNX, and when the strio pin is high, sending an off signal to the Android CPMS via QNX and starting a shutdown timeout; responding to Android receiving the off signal by broadcasting the off signal to all applications and shutting down after the registrant replies with an off message, and starting an off timeout to force a shutdown after the off timeout period ends; responding to Android successfully shutting down within the shutdown timeout period or the shutdown timeout period ending by restarting Android via QNX, and then sending a restart success notification to the MCU and QNX after Android restarts; and responding to QNX receiving the restart success notification by forwarding the keystr signal to Android via QNX. CPMS is activated, and QNXstr timeout is enabled. In response to Android receiving the keystr signal, Android broadcasts str to all applications and shuts down after the registrant replies with str. A str timeout is also enabled to force shutdown after the str timeout expires. In response to Android successfully shutting down within the str timeout period, or the str timeout ending, or the QNXstr timeout ending, QNX performs a self-memory hibernation operation and pulls the pmicio pin high after successful hibernation. The MCU detects whether the pmicio pin is high; if high, an MCU memory hibernation operation is performed; if low, a power-on / off operation is performed on QNX and Android until the pmicio pin is high and the MCU memory hibernation operation is executed.

[0046] Optionally, the ON phase module is specifically used to detect the Android virtual machine state through QNX; when the Android virtual machine state is off, it performs a virtual machine start-up operation on the Android virtual machine through QNX; when the Android virtual machine state is str, it performs a virtual machine wake-up operation on the Android virtual machine through QNX.

[0047] Based on the same concept, in a third aspect, the present invention also provides an electronic device including a memory and a processor, the memory storing a computer program executable on the processor, the processor executing the program to implement the steps of the power coordination management method of any one of the first aspects.

[0048] Based on the same concept, in a fourth aspect, the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the power cooperative management method described in any one of the first aspects.

[0049] The technical solution provided by this invention includes the following steps: First, in response to the MCU intending to enter the ON phase, the MCU detects whether the vehicle network meets preset sleep conditions. Further, when the vehicle network does not meet the preset sleep conditions, the MCU sends a keyon signal. Further, in response to the QNX receiving the keyon signal, the QNX switches its own state to the ON phase and sends at least a startup success notification to the MCU. Simultaneously, the QNX detects the Android virtual machine state and, based on the Android virtual machine state, at least starts or wakes up the Android virtual machine, and forwards the keyon signal to the Android CPMS. Further, in response to the Android receiving the keyon signal, the Android switches its own state to the ON phase and sends at least a startup success notification to the MCU. Simultaneously, the CPMS state is sent to the QNX. Finally, after a preset period of time after the QNX switches its own state to the ON phase, the QNX detects the CPMS state. If the CPMS state is not in the ON phase, the QNX restarts the Android virtual machine. In addition, the MCU intends to enter the ON phase, which means that the MCU intends to enter the ON phase from the ShutdownPrepare phase. During the ShutdownPrepare phase, the vehicle cabin shuts down at least one peripheral device but retains core computing resources to at least meet the independent operation of the preset computing power tasks during the ShutdownPrepare phase.

[0050] Therefore, this invention enables high-performance computing tasks to run independently during the ShutdownPrepare phase, isolated from real-time tasks in the IG ON state. This avoids lag while optimizing vehicle system resources and improving system smoothness. For example, OTA upgrades can be performed in the background during this phase, without affecting the user's last operation before exiting the vehicle system. Furthermore, this invention allows the shutdown of some unnecessary peripherals (such as backlight and Wi-Fi) during the ShutdownPrepare phase, retaining only core computing resources. This reduces power consumption by approximately 30% compared to the IG ON state, while still supporting the efficient completion of high-performance computing tasks, thus balancing vehicle system power consumption and task efficiency. Attached Figure Description

[0051] Figure 1 This is a flowchart of a power collaborative management method provided in an embodiment of the present invention;

[0052] Figure 2 This is a flowchart of another power collaborative management method provided in an embodiment of the present invention;

[0053] Figure 3 This is a flowchart of another power collaborative management method provided in an embodiment of the present invention;

[0054] Figure 4 This is a schematic diagram of the structure of a power cooperative management device provided in an embodiment of the present invention;

[0055] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0056] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0057] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the application. The singular forms “a,” “said,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms, and “multiple” generally includes at least two unless the context clearly indicates otherwise.

[0058] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0059] It should be understood that although the terms first, second, third, etc., may be used in the embodiments of this application, these descriptions should not be limited to these terms. These terms are only used to distinguish the descriptions. For example, first may also be referred to as second without departing from the scope of the embodiments of this application, and similarly, second may also be referred to as first.

[0060] Depending on the context, the words “if” or “suppose” as used here can be interpreted as “when” or “in response to determination” or “in response to detection.” Similarly, depending on the context, the phrases “if determination” or “if detection (of the stated condition or event)” can be interpreted as “when determination” or “in response to determination” or “when detection (of the stated condition or event)” or “in response to detection (of the stated condition or event).”

[0061] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that an article or device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such an article or device. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the article or device that includes said element.

[0062] It should be noted that any symbols and / or numbers present in the specification that are not marked in the accompanying drawings are not reference numerals.

[0063] Figure 1 This is a flowchart of a power coordination management method provided by an embodiment of the present invention. This embodiment is applicable to at least any multi-system power coordination management scenario of an on-board cockpit controller in a vehicle. This power coordination management method can be, but is not limited to, executed by the power coordination management device in this embodiment as the execution subject, which can be implemented in software and / or hardware. Figure 1 As shown, the power cooperative management method includes at least the following steps:

[0064] S1. In response to the MCU's intention to enter the ON phase, the MCU detects whether the vehicle network meets the preset sleep conditions.

[0065] S2. When the vehicle network does not meet the preset sleep conditions, a keyon signal is sent out through the MCU.

[0066] The keyon signal can be a "Sleep_mode=on" signal. It's understandable that the keyon signal sent by the MCU can be periodic, specifically triggered by a 1-second periodic change (i.e., it's sent immediately if there's a change, and periodically if there's no change).

[0067] S3. In response to QNX receiving the keyon signal, QNX switches its own state to the ON stage and sends a startup success notification to the MCU. At the same time, QNX detects the Android virtual machine status and, based on the Android virtual machine status, at least starts or wakes up the Android virtual machine, and forwards the keyon signal to the Android CPMS.

[0068] QNX can send a startup success notification to the MCU ten times in 1-second cycles. Additionally, QNX can periodically forward the keyon signal to the Android CPMS, specifically triggered by a 1-second change (i.e., it sends immediately if there's a change, and periodically if there's no change).

[0069] In one specific implementation, optionally, the Android virtual machine state is detected via QNX, and the Android virtual machine is at least started or woken up based on the Android virtual machine state, specifically including:

[0070] (3-1) Detect the Android virtual machine status using QNX;

[0071] (3-2) When the Android virtual machine is in the off state (i.e., off2on), perform a virtual machine start-up operation on the Android virtual machine through QNX;

[0072] (3-3) When the Android virtual machine is in the str state (i.e. str2on), the virtual machine wake-up operation is performed on the Android virtual machine through QNX.

[0073] S4. In response to Android receiving the keyon signal, switch its own state to the ON stage through Android and send a startup success notification to the MCU at least once. At the same time, send the CPMS status to QNX.

[0074] Specifically, Android can send a startup success notification to the MCU at 1-second intervals, up to ten times. Additionally, Android can periodically send the CPMS status to QNX, triggered by a 10-second change; the sending path can be VHAL → MCU_Service → pm.

[0075] S5. After QNX switches its state to the ON stage within a preset time period, QNX detects the CPMS state. If the CPMS state is not in the ON stage, QNX restarts the Android virtual machine.

[0076] Specifically, the MCU intending to enter the ON phase means at least that the MCU intends to enter the ON phase from the ShutdownPrepare phase. During the ShutdownPrepare phase, the vehicle cabin shuts down at least one peripheral device but retains core computing resources to at least satisfy the independent operation of preset computing tasks during the ShutdownPrepare phase. For example, the preset time period can be 1 minute.

[0077] The following is a scenario example for the ON phase:

[0078] 1. MCU

[0079] (1) The default is shutdownprepare, and it checks whether the network sleep conditions are met and whether the state needs to be migrated to shutdownprepare;

[0080] (2) If not satisfied, Sleep_mode = on outside the cycle, and the cycle is 1S+ to trigger (if there is a change, it will be sent immediately; if there is no change, it will be sent periodically).

[0081] 2.QNX

[0082] (1) Upon receiving "on", the state immediately switches to "on" and sends a startup success notification to the MCU. The notification is sent every 1 second and is sent ten times.

[0083] (2) off2on: Detects the Android virtual machine status. If the Android virtual machine is off, it will start the virtual machine.

[0084] (3) str2on: Checks if the Android virtual machine has been str; if str is str, the virtual machine is woken up.

[0085] (4) Switch any state to on, check if CPMS is on after 1 minute, otherwise restart the virtual machine;

[0086] (5) Periodically forward key-on to Android CPMS; periodic 1S+ change trigger;

[0087] (6) Perform state transition based on the Sleep_mode value.

[0088] 3. Android

[0089] (1) Upon receiving Sleep_mode=on, the state switches to on, and a startup success notification is sent to the MCU. The notification is sent every 1 second and is sent ten times.

[0090] (2) Periodically send CPMS status to QNX, VHAL->MCU_Service->pm, period 10s, period + change trigger;

[0091] (3) Perform state transition based on the key value.

[0092] The technical solution provided in this embodiment firstly, in response to the MCU intending to enter the ON phase, the MCU detects whether the vehicle network meets the preset sleep conditions; further, when the vehicle network does not meet the preset sleep conditions, the MCU sends a keyon signal; further, in response to the QNX receiving the keyon signal, the QNX switches its own state to the ON phase and sends at least a startup success notification to the MCU, while simultaneously detecting the Android virtual machine state and, based on the Android virtual machine state, at least starting or waking up the Android virtual machine, and forwarding the keyon signal to the Android CPMS; further, in response to the Android receiving the keyon signal, the Android switches its own state to the ON phase and sends at least a startup success notification to the MCU, while simultaneously sending the CPMS state to the QNX; finally, after a preset period of time after the QNX switches its own state to the ON phase, the QNX detects the CPMS state, and if the CPMS state is not in the ON phase, the QNX restarts the Android virtual machine. In addition, the MCU intends to enter the ON phase, which means that the MCU intends to enter the ON phase from the ShutdownPrepare phase. During the ShutdownPrepare phase, the vehicle cabin shuts down at least one peripheral device but retains core computing resources to at least meet the independent operation of the preset computing power tasks during the ShutdownPrepare phase.

[0093] Therefore, this embodiment demonstrates two advantages. First, it allows high-performance computing tasks to run independently during the ShutdownPrepare phase, isolated from real-time tasks in the IG ON state. This avoids lag while optimizing vehicle system resources and improving system smoothness. For example, OTA upgrades can be performed in the background during this phase, without affecting the user's last operation before exiting the vehicle system. Second, this embodiment can disable some unnecessary peripherals (such as backlight and Wi-Fi) during the ShutdownPrepare phase, retaining only core computing resources. This reduces power consumption by approximately 30% compared to the IG ON state, while still supporting the efficient completion of high-performance computing tasks, thus balancing vehicle system power consumption and task efficiency.

[0094] Based on the above embodiments or implementation methods Figure 2 This is a flowchart of another power cooperative management method provided in an embodiment of the present invention, such as... Figure 2 As shown, the power cooperative management method includes at least the following steps:

[0095] S6. In response to the MCU's intention to enter the ShutdownPrepare stage, the MCU detects whether the vehicle network meets the preset sleep conditions.

[0096] S7. When the vehicle network meets the preset sleep conditions, the MCU sends a ShutdownPrepare signal and starts the Android power-down request timer.

[0097] S8, in response to receiving the ShutdownPrepare signal from QNX, forwards the ShutdownPrepare signal to Android CPMS via QNX.

[0098] S9. In response to Android receiving the ShutdownPrepare signal, Android sends a ShutdownPrepare notification to at least the registered listening applications and system services, and at the same time sends an Android power-off request to the MCU.

[0099] S10. When the MCU does not receive the Android power-up request within the time period of the Android power-up request timing, the MCU releases the network and stops sending NM messages.

[0100] S11. When the MCU receives the Android power-up request during the Android power-up request time period, it replies with an ack signal to Android through the MCU and starts the forced release timer.

[0101] S12. In response to Android receiving the ack signal, Android stops sending Android power-off requests, and on the Android side, the application's business processing is completed. Then, Android sends a release request notification to the MCU.

[0102] S13. When the MCU receives a release request notification or the forced release timer ends, the MCU stops sending NM messages.

[0103] The following is a scenario example for the ShutdownPrepare stage:

[0104] 1. MCU

[0105] (1) Periodically send Sleep_mode=Shutdownprepare;

[0106] (2) After entering this state, enable a 1-minute timeout and wait for Android to pull the power request;

[0107] (3) If no power pull request is received after a 1-minute timeout, release the network and actively stop sending NM messages;

[0108] (4) If an Android power-pull request is received within 1 minute, reply with ack, wait for Android release request or force timeout in 5 minutes, and actively stop sending NM messages;

[0109] (5) Follow network management specifications and enter CAN bus network sleep mode;

[0110] (6) The wake-up source interruption logic references the MCU state machine and can be directly interrupted.

[0111] 2.QNX

[0112] (1) Pm forwards power_key: Shutdown_prepare to the Android side;

[0113] (2) The wake-up source interrupts the logic reference state machine, which can be interrupted directly.

[0114] 3. Android:

[0115] (1) Android CPMS receives the key: shutdown_prepare, and sends shutdownprepare notifications to the registered listening applications and system services; at the same time, Vhal→MCU requests to pull the power.

[0116] Power-up request property: MCU_ANDROID_POWER_REQUEST, interactive, if no ACK is received, retry interval 1 second, retry count 60 times. Stop sending power-up requests upon receiving an MCU ACK;

[0117] (2) Android applications listen to shutdown_prepare and release the occupied resources according to business needs. However, some special applications, such as Qiying, are launched at this time and start scanning the pictures stored in the USB flash drive. They immediately register setListenerWithCompletion and do not reply to Complete; and request wakelock Android power status. When CPMS recognizes that any application requests to maintain power, it immediately sends a power maintenance request to MCU.

[0118] (3) All applications and services that consume system resources must register the setListenerWithCompletion interface. After CPMS sends shutdownprepare to all registered parties, it must wait at least 60 seconds before allowing the switch to ShutdownPrepare. If there are clients in the registration list that have not responded with complete, the waiting time must be extended, with a maximum waiting time of 5 minutes. If the waiting time overflows, CPMS will force the switch to Shutdownprepare, and at the same time, Vhal→MCU will request to release power. For registered parties that have not returned Complete, the log will be recorded and printed.

[0119] (4) For Android special applications, after processing the business, the power pull request is released and the CPMS sends a release request notification to the MCU side;

[0120] (5) The wake-up source interrupts the logic reference state machine, which can be interrupted directly.

[0121] Therefore, this embodiment can solve at least the following problems:

[0122] 1. Resource isolation requirements for high-performance computing applications: to prevent high-performance computing tasks and real-time interactive tasks from competing for resources in the IG ON state.

[0123] 2. Task execution efficiency in low-power scenarios: By utilizing the transition phase of power mode switching (ShutdownPrepare), high-load tasks can be completed while ensuring low system power consumption.

[0124] 3. Task reliability and system stability: By defining a clear timeout mechanism and exception handling process, ensure that high-computing-power tasks are completed or safely interrupted before power state switching.

[0125] Correspondingly, this embodiment can achieve at least the following beneficial effects:

[0126] 1. Resource optimization and improved system smoothness

[0127] High-performance computing tasks run independently during the ShutdownPrepare phase, isolated from real-time tasks in the IG ON state to avoid lag. For example, OTA upgrades can be performed in the background during this phase, without affecting the user's last operation before exiting the vehicle's infotainment system.

[0128] 2. Balancing power consumption and task efficiency

[0129] The ShutdownPrepare phase disables some non-essential peripherals (such as backlight and WIFI) and retains only core computing resources, reducing power consumption by about 30% compared to the IG ON state, while supporting the efficient completion of high-computing tasks.

[0130] 3. Enhanced mission reliability

[0131] By using a timeout forced switching mechanism (such as Android CPMS waiting for the application to respond for a maximum of 5 minutes, after which it will force a switch to hibernation and record logs), the system avoids tasks blocking power mode migration for a long time and ensures that the system enters a low-power state on time.

[0132] 4. Platform compatibility and scalability

[0133] This mechanism is applicable to multi-operating system architectures (such as QNX+Android dual system), supports customized power strategies for different vehicle models, and integrates and reports power signals from each vehicle model by the MCU.

[0134] Based on the above embodiments or implementation methods Figure 3This is a flowchart of another power cooperative management method provided in an embodiment of the present invention, such as... Figure 3 As shown, the power cooperative management method includes at least the following steps:

[0135] S14. In response to the MCU's intention to enter the STR stage, the MCU pulls the strio pin high and sends the keystr signal externally.

[0136] S15. Identify the strio pin through QNX. When the strio pin is high, send an off signal to AndroidCPMS through QNX and start the shutdown timeout timer.

[0137] S16. In response to Android receiving an off signal, broadcast off to all applications via Android, shut down the device after the registered party replies with off, and start an off timeout countdown to force shutdown after the off timeout countdown ends.

[0138] S17. In response to Android successfully shutting down within the shutdown timeout period or the shutdown timeout period ending, restart Android via QNX, and then send a restart success notification to MCU and QNX after Android restarts.

[0139] S18. In response to the QNX receiving a successful restart notification, the keystr signal is forwarded to AndroidCPMS via QNX, and the QNXstr timeout is started.

[0140] S19. In response to Android receiving the keystr signal, broadcast str to all applications via Android, shut down the device after the registrant replies with str, and start a str timeout countdown to force shutdown after the str timeout countdown ends.

[0141] S20: In response to Android successfully shutting down within the str timeout period, or the str timeout period ending, or the QNX str timeout period ending, perform a self-memory hibernation operation via QNX, and pull up the pmicio pin after successfully hibernating.

[0142] S21. Detect whether the pmicio pin is high through the MCU. If it is high, perform MCU memory sleep operation; if it is low, perform a power-off operation on QNX and Android until the pmicio pin is high and the MCU memory sleep operation is performed.

[0143] The following is a scenario example of the STR stage:

[0144] 1. MCU

[0145] (1) Pull str_io high and periodically send Sleep_mode=str;

[0146] (2) Start SOC STR timeout t3, timeout time 60s;

[0147] (3) Check if pmic_io is high. If it is high, the MCU switches to STR_POST, with a maximum timeout of t3.

[0148] If low, perform a power-off and power-on cycle, wait 60 seconds, and continue checking PMIC_IO; if high, the MCU switches to STR_POST; if low, it switches to OFF_POST.

[0149] (4) Wake-up interruption logic: The MCU sends an ON to the SoC. If the SoC replies with stop_powerdown within the timeout period, the MCU waits for QNX and Android to start successfully. The timeout period is 30 seconds. After the timeout, the MCU performs a power-off and power-on once. If the SoC does not reply within the t3 timeout period, the MCU checks whether the wake-up source still exists after the timeout period t3 expires. If it does, the SoC is woken up.

[0150] (5) If the STR is not in a STR state or if the STR is exited by receiving stop_powerdown, str_io will be pulled low.

[0151] 2.QNX

[0152] (1) Identify whether str_io is high and send off to Android CPMS;

[0153] (2) After entering the str state in the first stage, timeout T2 is enabled, and reset is executed after the Android virtual machine is successfully shut down; otherwise, reset is executed when the timeout expires.

[0154] (3) After resetting, identify str_io, send str to CPMS, wait for Android to start successfully (bootready_flag), and enable timeout T6 (shutdownprepare 60s + android_str 5s~10s), or continuously monitor the Android virtual machine str to execute qnx str after it is successful, otherwise force execution of qnx str when the timeout expires;

[0155] (4) Wake-up interruption logic: If the MCU sends an ON signal, as long as the QNX is in a non-startup process and a non-sleep process, replying can interrupt stop_powerdown;

[0156] (5) After successful hibernation, raise pmic_io.

[0157] 3. Android:

[0158] (1) Receive OFF, execute OFF in the first stage. Set timeout T1, broadcast OFF to all applications, shut down after the registrant replies "complete", or force shutdown when t1 times out;

[0159] (2) After executing reset, send a startup success notification to MCU QNX, with a cycle of 1s + 10 times;

[0160] (3) Receive str, execute str in the second stage. When entering shutdownprepare, timeout t5 is enabled, broadcast str to all applications, and shut down after the registered party replies "complete", or force str when the timeout expires in t5; the second stage shutdownprepare does not need to wait 1 minute.

[0161] Therefore, this embodiment can solve at least the following problems:

[0162] 1. Resource isolation requirements for high-performance computing applications: to prevent high-performance computing tasks and real-time interactive tasks from competing for resources in the IG ON state.

[0163] 2. Task execution efficiency in low-power scenarios: By utilizing the transition phase of power mode switching (ShutdownPrepare), high-load tasks can be completed while ensuring low system power consumption.

[0164] 3. Task reliability and system stability: By defining a clear timeout mechanism and exception handling process, ensure that high-computing-power tasks are completed or safely interrupted before power state switching.

[0165] Correspondingly, this embodiment can achieve at least the following beneficial effects:

[0166] 1. Resource optimization and improved system smoothness

[0167] High-performance computing tasks run independently during the ShutdownPrepare phase, isolated from real-time tasks in the IG ON state to avoid lag. For example, OTA upgrades can be performed in the background during this phase, without affecting the user's last operation before exiting the vehicle's infotainment system.

[0168] 2. Balancing power consumption and task efficiency

[0169] The ShutdownPrepare phase disables some non-essential peripherals (such as backlight and WIFI) and retains only core computing resources, reducing power consumption by about 30% compared to the IG ON state, while supporting the efficient completion of high-computing tasks.

[0170] 3. Enhanced mission reliability

[0171] By using a timeout forced switching mechanism (such as Android CPMS waiting for the application to respond for a maximum of 5 minutes, after which it will force a switch to hibernation and record logs), the system avoids tasks blocking power mode migration for a long time and ensures that the system enters a low-power state on time.

[0172] 4. Platform compatibility and scalability

[0173] This mechanism is applicable to multi-operating system architectures (such as QNX+Android dual system), supports customized power strategies for different vehicle models, and integrates and reports power signals from each vehicle model by the MCU.

[0174] Figure 4 This is a schematic diagram of a power coordination management device provided in an embodiment of the present invention. This embodiment is applicable to at least any vehicle's onboard cockpit controller multi-system power coordination management scenario. The power coordination management device can be implemented in software and / or hardware. Figure 4 As shown, the power coordination management device is used to execute the power coordination management method of any of the foregoing embodiments or implementations.

[0175] The power coordination management device includes at least an ON phase module 110;

[0176] The ON phase module 110 is at least used to respond to the MCU's intention to enter the ON phase by detecting whether the vehicle network meets preset sleep conditions through the MCU; when the vehicle network does not meet the preset sleep conditions, the MCU sends a keyon signal; in response to the QNX receiving the keyon signal, the QNX switches its own state to the ON phase and sends at least a startup success notification to the MCU, while simultaneously detecting the Android virtual machine state through the QNX and at least starting or waking up the Android virtual machine based on the Android virtual machine state, and forwarding the keyon signal to the Android CPMS; in response to the Android receiving the keyon signal, the Android switches its own state to the ON phase and sends at least a startup success notification to the MCU, while simultaneously sending the CPMS state to the QNX; after a preset period of time when the QNX switches its own state to the ON phase, the QNX detects the CPMS state, and if the CPMS state is not in the ON phase, the QNX restarts the Android virtual machine.

[0177] Optionally, it may also include at least the ShutdownPrepare stage module 120;

[0178] The ShutdownPrepare phase module 120 is at least used to respond to the MCU's intention to enter the ShutdownPrepare phase by detecting whether the vehicle network meets the preset sleep conditions through the MCU; when the vehicle network meets the preset sleep conditions, the MCU sends a ShutdownPrepare signal and starts the Android power-down request timer; in response to the QNX receiving the ShutdownPrepare signal, the QNX forwards the ShutdownPrepare signal to the Android. CPMS: In response to Android receiving the ShutdownPrepare signal, Android sends a ShutdownPrepare notification to at least the registered listening applications and system services, and simultaneously sends an Android power-down request to the MCU. If the MCU does not receive the Android power-down request within the time period of the Android power-down request, the MCU releases the network and stops sending NM messages. If the MCU receives the Android power-down request within the time period of the Android power-down request, the MCU replies with an ack signal to Android and starts a forced release timer. In response to Android receiving the ack signal, Android stops sending Android power-down requests, and on the Android side, after the application's business processing is completed, Android sends a release request notification to the MCU. When the MCU receives the release request notification or the forced release timer ends, the MCU stops sending NM messages.

[0179] Optionally, it may also include at least the STR stage module 130;

[0180] The STR phase module 130 is at least used to respond to the MCU's intention to enter the STR phase by pulling the strio pin high and sending the keystr signal; identifying the strio pin via QNX, and when the strio pin is high, sending an off signal to the AndroidCPMS via QNX and starting a shutdown timeout; responding to Android receiving the off signal by broadcasting the off signal to all applications and shutting down after receiving a reply from the registered party, and starting an off timeout to force shutdown after the off timeout expires; responding to Android successfully shutting down within the shutdown timeout period or the shutdown timeout expires by restarting Android via QNX, and then sending a restart success notification to the MCU and QNX after restarting; and responding to QNX receiving the restart success notification by forwarding the keystr signal to Android via QNX. CPMS is activated, and QNXstr timeout is enabled. In response to Android receiving the keystr signal, str is broadcast to all applications via Android, and the device shuts down upon receiving a reply from the registered party after str completion. A str timeout is also enabled to force shutdown after the str timeout expires. In response to Android successfully shutting down within the str timeout period, or the str timeout expires, or the QNXstr timeout expires, a self-memory hibernation operation is performed via QNX, and the pmicio pin is pulled high after successful hibernation. The MCU detects whether the pmicio pin is high. If it is high, the MCU memory hibernation operation is performed. If it is low, a power-on / off operation is performed on QNX and Android until the pmicio pin is high and the MCU memory hibernation operation is performed.

[0181] Optionally, the ON phase module 110 is specifically used to detect the Android virtual machine state through QNX; when the Android virtual machine state is off, it performs a virtual machine start-up operation on the Android virtual machine through QNX; when the Android virtual machine state is str, it performs a virtual machine wake-up operation on the Android virtual machine through QNX.

[0182] The technical solution provided in this embodiment firstly, in response to the MCU intending to enter the ON phase, the ON phase module detects whether the vehicle network meets the preset sleep conditions through the MCU; further, when the vehicle network does not meet the preset sleep conditions, the ON phase module sends a keyon signal through the MCU; further, in response to the QNX receiving the keyon signal, the ON phase module switches its own state to the ON phase through the QNX and sends at least a startup success notification to the MCU. Simultaneously, the ON phase module detects the Android virtual machine state through the QNX and, based on the Android virtual machine state, at least starts or wakes up the Android virtual machine, and forwards the keyon signal to the Android CPMS; further, in response to the Android receiving the keyon signal, the ON phase module switches its own state to the ON phase through the Android and sends at least a startup success notification to the MCU. Simultaneously, the CPMS state is sent to the QNX; finally, after a preset period of time after the QNX switches its own state to the ON phase, the ON phase module detects the CPMS state through the QNX. If the CPMS state is not in the ON phase, the ON phase module restarts the Android virtual machine through the QNX. In addition, the MCU intends to enter the ON phase, which means that the MCU intends to enter the ON phase from the ShutdownPrepare phase. During the ShutdownPrepare phase, the vehicle cabin shuts down at least one peripheral device but retains core computing resources to at least meet the independent operation of the preset computing power tasks during the ShutdownPrepare phase.

[0183] Therefore, this embodiment demonstrates two advantages. First, it allows high-performance computing tasks to run independently during the ShutdownPrepare phase, isolated from real-time tasks in the IG ON state. This avoids lag while optimizing vehicle system resources and improving system smoothness. For example, OTA upgrades can be performed in the background during this phase, without affecting the user's last operation before exiting the vehicle system. Second, this embodiment can disable some unnecessary peripherals (such as backlight and Wi-Fi) during the ShutdownPrepare phase, retaining only core computing resources. This reduces power consumption by approximately 30% compared to the IG ON state, while still supporting the efficient completion of high-performance computing tasks, thus balancing vehicle system power consumption and task efficiency.

[0184] This embodiment provides an electronic device. Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. See also: Figure 5The electronic device 1000 includes a processor 1001 and a memory 1002. The memory 1002 stores computer-readable instructions. When the computer-readable instructions are executed by the processor 1001, the steps in any of the above power coordination management methods are performed. Through the above technical solution, the processor 1001 and the memory 1002 are interconnected and communicate with each other via a communication bus and / or other forms of connection mechanisms (not shown). The memory 1002 stores a computer program executable by the processor. When the electronic device 1000 is running, the processor 1001 executes the computer program to perform the power coordination management method in any optional implementation of the above embodiments, to at least achieve the following functions: in response to the MCU intending to enter the ON phase, the MCU detects whether the vehicle network meets the preset sleep conditions; when the vehicle network does not meet the preset sleep conditions, the MCU sends a keyon signal; in response to the QNX receiving the keyon signal, the QNX switches its own state to the ON phase and at least sends a startup success notification to the MCU; simultaneously, the QNX detects the Android virtual machine state and, based on the Android virtual machine state, at least starts or wakes up the Android virtual machine; and forwards the keyon signal to the Android... CPMS: In response to Android receiving the keyon signal, it switches its own state to the ON stage through Android and sends a startup success notification to the MCU at least once. At the same time, it sends the CPMS status to QNX. After a preset period of time when QNX switches its own state to the ON stage, it checks the CPMS status through QNX. If the CPMS status is not in the ON stage, it restarts the Android virtual machine through QNX.

[0185] This embodiment provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the power coordination management method provided in all embodiments of this application: In response to the MCU intending to enter the ON phase, the MCU detects whether the vehicle network meets preset sleep conditions; when the vehicle network does not meet the preset sleep conditions, the MCU sends a keyon signal; in response to the QNX receiving the keyon signal, the QNX switches its own state to the ON phase and sends at least a startup success notification to the MCU, while simultaneously detecting the Android virtual machine state through the QNX and, based on the Android virtual machine state, at least starts or wakes up the Android virtual machine, and forwards the keyon signal to the Android CPMS; in response to the Android receiving the keyon signal, the Android switches its own state to the ON phase and sends at least a startup success notification to the MCU, while simultaneously sending the CPMS state to the QNX; after a preset period of time after the QNX switches its own state to the ON phase, the QNX detects the CPMS state, and if the CPMS state is not in the ON phase, the QNX restarts the Android virtual machine.

[0186] Any combination of one or more computer-readable media may be used. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device.

[0187] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including—but not limited to—electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of transmitting, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0188] The program code contained on a computer-readable medium may be transmitted using any suitable medium, including—but not limited to—wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0189] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages—such as Java, Smalltalk, and C++—as well as conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0190] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A power supply collaborative management method, characterized in that, It is applicable at least to multi-system power coordination management scenarios for vehicle cockpit controllers; The power collaborative management method includes at least the following: In response to the MCU's intention to enter the ON phase, the MCU detects whether the vehicle network meets the preset sleep conditions. When the vehicle network does not meet the preset sleep conditions, a keyon signal is sent out through the MCU. In response to QNX receiving the keyon signal, QNX switches its own state to the ON stage and sends a startup success notification to the MCU. At the same time, QNX detects the Android virtual machine state and, based on the Android virtual machine state, at least starts or wakes up the Android virtual machine. Additionally, QNX forwards the keyon signal to the Android CPMS. In response to Android receiving the keyon signal, Android switches its own state to the ON stage and sends a startup success notification to the MCU at least once. At the same time, the CPMS status is sent to QNX. After QNX switches its state to the ON stage for a preset period of time, the CPMS state is detected by QNX. If the CPMS state is not in the ON stage, the Android virtual machine is restarted by QNX. Specifically, the MCU intending to enter the ON phase is at least the MCU intending to enter the ON phase from the ShutdownPrepare phase; during the ShutdownPrepare phase, the vehicle cabin shuts down at least one peripheral device but retains core computing resources to at least meet the independent operation of preset computing tasks during the ShutdownPrepare phase.

2. The power collaborative management method according to claim 1, characterized in that, It also includes at least: In response to the MCU intending to enter the ShutdownPrepare stage, the MCU detects whether the vehicle network meets the preset sleep conditions. When the vehicle network meets the preset sleep conditions, it sends a ShutdownPrepare signal through the MCU and starts the Android power-down request timer. In response to QNX receiving the ShutdownPrepare signal, the ShutdownPrepare signal is forwarded to Android CPMS via QNX; In response to Android receiving the ShutdownPrepare signal, Android sends a ShutdownPrepare notification to at least the registered listening applications and system services, and at the same time sends an Android power-off request to the MCU. If the MCU does not receive the Android power-out request within the time period of the Android power-out request timing, the MCU releases the network and stops sending NM messages. When the MCU receives the Android power-out request during the Android power-out request time period, the MCU replies with an ack signal to the Android and starts the forced release timer. In response to Android receiving the ack signal, Android stops sending the Android power-off request, and on the Android side, the application's business processing is preset to complete, and Android sends a release request notification to the MCU. When the MCU receives the release request notification or the forced release timer expires, the MCU stops sending NM messages.

3. The power collaborative management method according to claim 1, characterized in that, It also includes at least: In response to the MCU's intention to enter the STR phase, the MCU pulls the strio pin high and sends the keystr signal externally; The strio pin is identified by QNX. When the strio pin is high, an off signal is sent to AndroidCPMS via QNX, and the shutdown timeout timer is started. In response to Android receiving the off signal, the system broadcasts the off signal to all applications via Android, shuts down the device after the registered party replies with the off signal, and starts an off timeout timer to force a shutdown after the off timeout timer expires. In response to Android successfully shutting down within the shutdown timeout period or the shutdown timeout period ending, Android is restarted via QNX, and then a restart success notification is sent to the MCU and QNX after Android restarts. In response to QNX receiving the restart success notification, QNX forwards the keystr signal to AndroidCPMS and starts the QNXstr timeout. In response to Android receiving the keystr signal, Android broadcasts str to all applications, shuts down the device after the registrant replies with str, and starts a str timeout countdown to force a shutdown after the str timeout countdown ends; In response to Android successfully shutting down within the time period of the str timeout, or the str timeout ending, or the QNXstr timeout ending, a self-memory hibernation operation is performed through QNX, and the pmicio pin is pulled high after the hibernation is successful. The MCU detects whether the pmicio pin is high. If it is high, the MCU memory sleep operation is executed; if it is low, a power-on / power-off operation is performed on QNX and Android until the pmicio pin is high and the MCU memory sleep operation is executed.

4. The power collaborative management method according to claim 1, characterized in that, The step of detecting the Android virtual machine status via QNX and, based on the Android virtual machine status, at least starting or waking up the Android virtual machine specifically includes: The Android virtual machine status is detected using QNX; When the Android virtual machine is in an off state, a virtual machine start-up operation is performed on the Android virtual machine via QNX; When the Android virtual machine is in the str state, a virtual machine wake-up operation is performed on the Android virtual machine via QNX.

5. A power supply collaborative management device, characterized in that, Used to perform the power cooperative management method according to any one of claims 1-4; The power coordination management device includes at least an ON phase module; The ON phase module is at least used to respond to the MCU's intention to enter the ON phase by detecting whether the vehicle network meets the preset sleep conditions through the MCU; when the vehicle network does not meet the preset sleep conditions, the MCU sends a keyon signal. In response to QNX receiving the keyon signal, QNX switches its own state to the ON stage and sends at least a startup success notification to the MCU. Simultaneously, QNX detects the Android virtual machine status and, based on the Android virtual machine status, at least starts or wakes up the Android virtual machine, and forwards the keyon signal to the Android CPMS. In response to Android receiving the keyon signal, Android switches its own state to the ON stage and sends at least a startup success notification to the MCU. Simultaneously, Android sends the CPMS status to QNX. After a preset period of time after QNX switches its own state to the ON stage, QNX detects the CPMS status. If the CPMS status is not in the ON stage, QNX restarts the Android virtual machine.

6. The power coordination management device according to claim 5, characterized in that, It should also include at least the ShutdownPrepare phase module; The ShutdownPrepare phase module is at least used to respond to the MCU's intention to enter the ShutdownPrepare phase by detecting whether the vehicle network meets the preset sleep conditions through the MCU; when the vehicle network meets the preset sleep conditions, the MCU sends a ShutdownPrepare signal and starts the Android power pull request timer; in response to QNX receiving the ShutdownPrepare signal, QNX forwards the ShutdownPrepare signal to the Android CPMS; in response to Android receiving the ShutdownPrepare signal, Android sends a ShutdownPrepare notification to at least the registered listening applications and system services, and simultaneously sends an Android power pull request to the MCU; when the MCU does not receive the Android power pull request within the Android power pull request timer period, the MCU releases the network and stops sending NM messages; when the MCU receives the Android power pull request within the Android power pull request timer period, the MCU replies with an ack signal to Android and starts a forced release timer. In response to Android receiving the ack signal, Android stops sending the Android power-off request, and on the Android side, the application's business processing is preset to complete, and Android sends a release request notification to the MCU; when the MCU receives the release request notification or the forced release timer ends, the MCU stops sending NM messages.

7. The power coordination management device according to claim 5, characterized in that, It should also include at least the STR phase module; The STR phase module is at least used to respond to the MCU's intention to enter the STR phase by pulling the strio pin high and sending the keystr signal; identifying the strio pin through QNX, and when the strio pin is high, sending an off signal to the Android CPMS through QNX and starting a shutdown timeout; responding to Android receiving the off signal, broadcasting off to all applications through Android, shutting down after the registrant replies with off, and starting an off timeout to force shutdown after the off timeout expires; In response to Android successfully shutting down within the shutdown timeout period or the shutdown timeout period ending, Android is restarted via QNX, and after Android restarts, a restart success notification is sent to the MCU and QNX; in response to QNX receiving the restart success notification, QNX forwards the keystr signal to the Android CPMS and starts the QNXstr timeout. In response to Android receiving the keystr signal, Android broadcasts str to all applications, shuts down the device after the registrant replies with str, and starts a str timeout countdown to force a shutdown after the str timeout countdown ends; In response to the Android successfully shutting down within the timeout period of the str timeout, or the str timeout ending, or the QNX str timeout ending, a self-memory hibernation operation is performed through QNX, and the pmicio pin is pulled high after the self-hibernation is successful; the MCU detects whether the pmicio pin is high. If it is high, the MCU memory hibernation operation is performed; if it is low, a power-on / power-off operation is performed on QNX and Android until the pmicio pin is high and the MCU memory hibernation operation is performed.

8. The power coordination management device according to claim 5, characterized in that, The ON phase module is specifically used to detect the Android virtual machine state through QNX; when the Android virtual machine state is off, it performs a virtual machine start-up operation on the Android virtual machine through QNX; when the Android virtual machine state is str, it performs a virtual machine wake-up operation on the Android virtual machine through QNX.

9. An electronic device comprising a memory and a processor, the memory storing a computer program executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the power cooperative management method according to any one of claims 1 to 4.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the power cooperative management method according to any one of claims 1 to 4.

Images