A power management method and system, electronic equipment and storage medium

Abstract

Embodiments of the present application provide a power management method, system, electronic device and storage medium. The method comprises: determining a target operation to be executed according to vehicle state information; in the case where the target operation is hibernation, controlling a power core service module to hibernate an Android system layer, the power core service module being a module in a native layer; controlling a communication module to hibernate according to a hibernation result of the Android system layer; in the case where the target operation is wake-up, controlling the communication module to wake up; and controlling the power core service module to wake up the Android system layer according to a wake-up result of the communication module. The stability of power management is improved, and the occurrence of a black screen problem is effectively avoided.

Description

Technical Field

[0001] This invention relates to the field of power management technology, and more specifically to a power management method, system, electronic device, and storage medium. Background Technology

[0002] Currently, Android's native power management is controlled by the PowerManagerService (PMS) service, which determines the sleep and wake-up of the entire Android vehicle system based on whether the screen is on or off. In this native power management, the main control logic of the power management IPO process is handled by the IncallCoreService in the Android system layer. The long signal transmission link of the preconditions for sleep and wake-up makes the sleep and wake-up process prone to loss, errors and other anomalies, resulting in black screen problems. Summary of the Invention

[0003] This invention provides a power management method, system, electronic device, and storage medium. The aim is to improve the stability of power management and effectively prevent black screen issues.

[0004] The first aspect of this invention provides a power management method applied to an MCU, the method comprising:

[0005] Based on the vehicle status information, determine the target operation to be performed;

[0006] When the target operation is to sleep, the power core service module is controlled to perform sleep at the Android system layer. The power core service module is a module in the native layer.

[0007] Based on the hibernation result of the Android system layer, control the communication module to hibernate;

[0008] When the target operation is to wake up, the control communication module is woken up;

[0009] Based on the wake-up result of the communication module, the power core service module is controlled to wake up the Android system layer.

[0010] Optionally, when the target operation is hibernation, controlling the power core service module to hibernate at the Android system layer includes:

[0011] When the target operation is to hibernate, the control sends a hibernation request to the power core service module via the first port connected to the power core service module.

[0012] According to the hibernation request, the power core service module is controlled to send a first call request for the hibernation interface to the power management service module, and the first target feedback information is received from the power core service module. The power management service module is a module in the Android system layer.

[0013] Based on the first call request, the power core service module is controlled to call the hibernation interface through the power management service module;

[0014] Based on the invoked sleep interface, the Android system layer sleep process is executed;

[0015] When the Android system layer hibernation process is completed, the power management service module sends a second target feedback message to the port driver.

[0016] Based on the second target feedback information, the port driver receives the screen-off request sent by the port driver through the second port, where the second port is the port through which the port driver sends the screen-on / off request to the MCU;

[0017] Based on the screen-off request, the display screen is controlled to turn off, thereby completing the hibernation process at the Android system layer.

[0018] Optionally, based on the hibernation result of the Android system layer, the communication module is controlled to hibernate, including:

[0019] Based on the feedback information from the first target and the screen-off request, the hibernation result of the Android system layer is determined;

[0020] If the sleep result characterization receives the first target feedback information and the screen-off request, it is determined whether the vehicle network is in sleep mode;

[0021] When the vehicle network is in sleep mode, the control third port connected to the communication module sends a communication sleep request to the communication module.

[0022] The communication module goes into sleep mode upon receiving the communication sleep request.

[0023] Optionally, the step of the communication module going into sleep mode according to the communication sleep request includes:

[0024] According to the communication sleep request, the power management module in the communication module is controlled to execute the sleep process, and a serial port shutdown request is sent to the signal forwarding middleware, and a first communication sleep request is sent to the non-power management module in the communication module;

[0025] Based on the request to close the serial port, the signal forwarding middleware is controlled to close the serial port, and based on the first communication sleep request, the non-power management module is controlled to execute the sleep process.

[0026] After the serial port is closed and the non-power management module completes the hibernation process, the control communication module releases the wake-up lock so that the SOC kernel enters the suspend state.

[0027] Optionally, the method further includes:

[0028] When the SOC kernel enters the suspend state, the first feedback information fed back by the SOC kernel through the fourth port is received;

[0029] Based on the first feedback information, power is turned off to enter low-power mode.

[0030] Optionally, if the target operation is hibernation, before controlling the power core service module to hibernate at the Android system layer, the method further includes:

[0031] When the target operation is to hibernate, determine whether there is a critical task, wherein the critical task is a task to be executed with a higher priority than the hibernation operation;

[0032] In cases where critical tasks exist, execute those critical tasks.

[0033] In the absence of critical tasks, the following steps are performed: When the target operation is to hibernate, the power core service module is controlled to hibernate at the Android system layer.

[0034] Optionally, if the target operation is hibernation, before controlling the power core service module to hibernate at the Android system layer, the method further includes:

[0035] When the target operation is to sleep, the target state recorded by the state machine in the power core service module is determined.

[0036] If the target state is sleep, the following steps are performed: Based on the sleep result of the Android system layer, control the communication module to enter sleep mode;

[0037] If the target state is awake, the following steps are performed: If the target operation is hibernation, the power core service module is controlled to hibernate at the Android system layer.

[0038] Optionally, if the target operation is to wake up, the control communication module is woken up, including:

[0039] When the target operation is wake-up, the control sends a communication wake-up request to the communication module via the third port connected to the communication module.

[0040] According to the communication wake-up request, the power management module in the communication module is controlled to execute the wake-up process, determine the heartbeat between the communication module and the communication module, send an open serial port request to the signal forwarding middleware, and send a first communication wake-up request to the non-power management module in the communication module.

[0041] Based on the serial port opening request, the signal forwarding middleware is controlled to open the serial port, and based on the first communication wake-up request, the non-power management module is controlled to execute the wake-up process.

[0042] With the serial port enabled and the non-power management module completing the wake-up process, the control communication module holds the wake-up lock to enable the SOC kernel to enter the resume state.

[0043] Optionally, controlling the power core service module to wake up the Android system layer based on the wake-up result of the communication module includes:

[0044] If the wake-up result indicates that the heartbeat is normal, the control sends a wake-up request to the power core service module via the first port connected to the power core service module.

[0045] Based on the wake-up request, the power core service module is controlled to send a second call request for the wake-up interface to the power management service module;

[0046] According to the second call request, the power core service module is controlled to call the wake-up interface through the power management service module;

[0047] Based on the invoked wake-up interface, the Android system layer wake-up process is executed;

[0048] When the Android system layer wake-up process is completed, the power management service module sends a third feedback message to the port driver.

[0049] Based on the third feedback information, the port driver receives the screen-opening request sent through the second port.

[0050] Based on the screen-on request, the display screen is controlled to turn on in order to complete the wake-up of the Android system layer.

[0051] Optionally, the method further includes:

[0052] In the event of an abnormal heartbeat, the SOC is restarted and the process returns to the following steps: based on the communication wake-up request, the power management module in the communication module is controlled to execute the wake-up process, and the heartbeat between the communication module and the communication module is determined, and a serial port enable request is sent to the signal forwarding middleware, and a first communication wake-up request is sent to the non-power management module in the communication module.

[0053] Optionally, before controlling the power core service module to wake up the Android system layer based on the wake-up result of the communication module, the method further includes:

[0054] When the target operation is wake-up, the target state recorded in the state machine of the power core service module is determined;

[0055] When the target state is awake, waking up the Android system layer is prohibited;

[0056] When the target state is sleep, the following steps are performed: based on the wake-up result of the communication module, the power core service module is controlled to wake up the Android system layer.

[0057] Optionally, the method further includes:

[0058] When the target operation is independent wake-up of the communication module, control the communication module to execute the communication wake-up process and determine the heartbeat between the communication module;

[0059] In the event of the abnormal heartbeat, the SOC is restarted and the process returns to the following steps: if the target operation is the independent wake-up of the communication module, the communication module is controlled to execute the communication wake-up process and the heartbeat between the communication module and the communication module is determined.

[0060] Optionally, the method further includes:

[0061] When the Android system starts up, the power management in the SOC is initialized.

[0062] A second aspect of this invention provides a power management system, the system including an MCU, a power core service module, and a power management service module; the MCU includes a target operation determination module, a first sleep control module, a second sleep control module, a first wake-up module, and a second wake-up module.

[0063] The target operation determination module is used to determine the target operation to be executed based on the vehicle status information.

[0064] The first hibernation control module is used to control the power core service module to hibernate at the Android system layer when the target operation is hibernation, wherein the power core service module is a module in the native layer.

[0065] The second sleep control module is used to control the communication module to enter sleep mode based on the sleep result of the Android system layer;

[0066] The first wake-up module is used to control the communication module to wake up when the target operation is wake-up;

[0067] The second wake-up module is used to control the power core service module to wake up the Android system layer based on the wake-up result of the communication module.

[0068] A third aspect of the present invention provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of a power management method as described in the first aspect of the present invention.

[0069] A fourth aspect of the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of a power management method as described in the first aspect of the present invention.

[0070] The power management method provided in this invention first determines the target operation to be executed based on vehicle status information. If the target operation is sleep, the power core service module is controlled to enter sleep mode at the Android system layer. The power core service module is a module in the native layer. Based on the sleep result at the Android system layer, the communication module is controlled to enter sleep mode. If the target operation is wake-up, the communication module is controlled to wake up. Based on the wake-up result of the communication module, the power core service module is controlled to wake up at the Android system layer. Therefore, this invention pushes the main control logic of power management down to the MCU (Microcontroller Unit, i.e., the microcontroller configured in the vehicle), and simultaneously pushes the core service control system of power management (i.e., the power core service module) down to the native layer of the Android framework (i.e., the system runtime library layer). This decouples the high dependency between the overall power management system and the Android system layer, shortens the signal transmission link of the sleep precondition, effectively improves the stability of power management, and thus effectively avoids the occurrence of black screen problems. In addition, by sinking the main control logic of power management to the MCU (Microcontroller Unit, i.e., the microcontroller configured in the vehicle) and the core service control system of power management to the native layer of the Android framework, this invention enables the communication module to perform independent sleep operations through the MCU. This allows the Android system layer and the communication module to be put into sleep mode separately when the vehicle system is put into sleep mode. This reduces the signal transmission link and the complexity of logic processing, thereby effectively improving the stability of power management and thus effectively avoiding the occurrence of black screen problems. Attached Figure Description

[0071] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0072] Figure 1 A flowchart illustrating a power management method according to an embodiment of the present invention;

[0073] Figure 2 This is a control flowchart illustrating a power management method according to an embodiment of the present invention;

[0074] Figure 3 This is an initialization flowchart illustrating a power management method according to an embodiment of the present invention;

[0075] Figure 4 This is another flowchart illustrating a power management method according to an embodiment of the present invention;

[0076] Figure 5 This is a flowchart illustrating a power management method for sleep mode according to an embodiment of the present invention;

[0077] Figure 6 This is a wake-up flowchart illustrating a power management method according to an embodiment of the present invention;

[0078] Figure 7 A structural diagram of a power management system is shown in one embodiment of the present invention. Detailed Implementation

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

[0080] Before describing this invention, let's first explain the conventional implementation methods of power management. The main control logic of the power management IPO process is handled by the IncallCoreService at the Android system layer. The transmission link for sleep / wake-up preconditions (such as engine status, car lock status, and driver's door status) is long, making the sleep / wake-up process prone to loss, errors, and other anomalies, leading to black screen issues. Simultaneously, in the entire system architecture, 4G and the Android system are vertical links, and the built-in 4G module cannot independently perform wake-up and sleep operations within the control logic. Furthermore, the main control logic program runs on the Android system, making it susceptible to interference from application modules and Android system layer factors, resulting in anomalies (e.g., Android system memory leaks leading to insufficient memory, application blocking the IncallCoreService power management process, late APK application startup, and untimely signal reception). These situations can easily cause sleep / wake-up anomalies, leading to stuttering, black screens, and other problems. Therefore, this invention proposes a power management method.

[0081] refer to Figure 1 , Figure 1 This is a structural block diagram illustrating a power management method according to an embodiment of the present invention. Figure 1 As shown, the power management method of this embodiment includes:

[0082] Step S1: Determine the target operation to be performed based on the vehicle status information.

[0083] In this embodiment, the vehicle's MCU receives status information from various vehicle components and performs main control logic judgments on this information to determine the target operation to be executed corresponding to the current status information of each component. The status information of each component includes, but is not limited to, engine ACC (Adaptive Cruise Control) status information, driver's door status information, vehicle lock status information, and remote signal information sent by a mobile terminal. The types of the target operation include, but are not limited to, vehicle-wide sleep mode operation and vehicle-wide wake-up operation.

[0084] Step S2: When the target operation is hibernation, control the power core service module to hibernate at the Android system layer. The power core service module is a module in the native layer.

[0085] In this embodiment, the present invention constructs a power core service module (NativeCorePower) in the system runtime library layer (native layer) of the SOC (System-on-a-Chip) where the Android architecture resides. This module receives control requests sent by the vehicle's MCU to control the vehicle to perform sleep or wake-up operations. Specifically: when the vehicle's MCU receives the status information of various vehicle components and performs main control logic judgment on the received status information, and determines that the target operation corresponding to the current status information of each component is to put the entire vehicle into sleep mode, the vehicle's MCU sends a request to the system runtime library layer (i.e., the native core power service module). Figure 2 The power core service module in the Android_native layer sends a hibernation request. After receiving the hibernation request, the power core service module controls the Android system layer to hibernate.

[0086] In this embodiment, the vehicle's MCU performs main control logic judgments on the status information of various vehicle components. If, during the main control logic judgment process, the engine ACC status information is determined to be off (ACC OFF), and the driver's door status information is determined to be open, the target operation to be executed is determined to be putting the entire vehicle into sleep mode. If, during the main control logic judgment process, the engine ACC status information is determined to be off (ACC OFF), and the vehicle lock status information is determined to be locked, the target operation to be executed is determined to be putting the entire vehicle into sleep mode. If, during the main control logic judgment process, the engine ACC status information is determined to be off (ACC OFF), and the preset countdown timer has been completed, the target operation to be executed is determined to be putting the entire vehicle into sleep mode. It should be understood that the above are only examples of several optional component status information scenarios in which the target operation to be executed can be determined as a sleep operation. Depending on the actual application scenario, the target operation to be executed can also be determined as putting the entire vehicle into sleep mode even when the status information of various vehicle components is in other states; no specific limitation is made here.

[0087] Step S3: Based on the hibernation result of the Android system layer, control the communication module to hibernate.

[0088] In this embodiment, after the Android system layer completes its hibernation, the vehicle's MCU will receive corresponding feedback information. Based on this feedback information, it determines that the Android system layer hibernation is complete. At this time, the vehicle's MCU will send a corresponding hibernation request to the communication module. Upon receiving this hibernation request, the communication module will execute the hibernation operation. The communication module includes, but is not limited to, 3G, 4G, and 5G modules.

[0089] Step S4: If the target operation is to wake up, control the communication module to wake up.

[0090] In this embodiment, when the vehicle's MCU receives the status information of each component of the vehicle and performs main control logic judgment on the received status information of each component of the vehicle, and determines that the target operation corresponding to the current status information of each component is to wake up the entire vehicle, the vehicle's MCU sends a communication wake-up request to the communication module. After the communication module receives the communication wake-up request, the communication module executes the wake-up operation.

[0091] In this embodiment, if the main control logic determines that the vehicle is unlocked and the driver's door is open during the main control logic's judgment process, the target operation to be executed is determined to be a system-wide wake-up operation for the vehicle; if the main control logic determines that the engine is started (ACC ON) during the main control logic's judgment process, the target operation to be executed is determined to be a system-wide wake-up operation for the vehicle; if the main control logic determines that a remote wake-up command sent by a mobile terminal has been received during the main control logic's judgment process, the target operation to be executed is determined to be a system-wide wake-up operation for the vehicle. It should be understood that the above only lists several optional state information scenarios for various components that can be used to determine the target operation to be executed as a wake-up operation. Depending on the actual application scenario, the target operation to be executed can also be determined to be a system-wide wake-up operation for the vehicle even when the state information of various components of the vehicle is in other states; no specific limitation is made here.

[0092] Step S5: Based on the wake-up result of the communication module, control the power core service module to wake up the Android system layer.

[0093] In this embodiment, after the vehicle's MCU determines that the communication module is in the wake-up process, the vehicle's MCU continues to send a wake-up request to the power core service module. After the power core service module receives the wake-up request, it controls the Android system layer to wake up.

[0094] The power management method provided in this invention first determines the target operation to be executed based on vehicle status information. If the target operation is sleep, the power core service module is controlled to enter sleep mode at the Android system layer. The power core service module is a module in the native layer. Based on the sleep result at the Android system layer, the communication module is controlled to enter sleep mode. If the target operation is wake-up, the communication module is controlled to wake up. Based on the wake-up result of the communication module, the power core service module is controlled to wake up at the Android system layer. Therefore, this invention pushes the main control logic of power management down to the MCU (Microcontroller Unit, i.e., the microcontroller configured in the vehicle), and simultaneously pushes the core service control system of power management (i.e., the power core service module) down to the native layer of the Android framework (i.e., the system runtime library layer). This decouples the high dependency between the overall power management system and the Android system layer, shortens the signal transmission link of the sleep precondition, effectively improves the stability of power management, and thus effectively avoids the occurrence of black screen problems. In addition, by sinking the main control logic of power management to the MCU (Microcontroller Unit, i.e., the microcontroller configured in the vehicle) and the core service control system of power management to the native layer of the Android framework, this invention enables the communication module to perform independent sleep operations through the MCU. This allows the Android system layer and the communication module to be put into sleep mode separately when the vehicle system is put into sleep mode. This reduces the signal transmission link and the complexity of logic processing, thereby effectively improving the stability of power management and thus effectively avoiding the occurrence of black screen problems.

[0095] In conjunction with the above embodiments, in one implementation, the present invention also provides a power management method. In this power management method, step S2 includes steps S21 to S27:

[0096] Step S21: When the target operation is hibernation, the control sends a hibernation request to the power core service module via the first port connected to the power core service module.

[0097] In this embodiment, as Figure 2 As shown, when the vehicle's MCU receives the status information of various vehicle components and performs main control logic judgment on the received status information, and determines that the target operation corresponding to the current status information of each component is to put the entire vehicle into sleep mode, the vehicle's MCU drives the port driver (i.e., Figure 2 The GPIO_DRIVE control in the module connects to the first port of the power core service module (NativeCorePower). Figure 2The MCU sends a sleep request to the power core service module via GPIO1. Specifically, the vehicle's MCU sends a sleep request to the power core service module by pulling the level of the first port low. When the power core service module receives the change in the level of the first port to low, it can determine that the vehicle's MCU wants to perform a sleep operation.

[0098] Step S22: Based on the hibernation request, control the power core service module to send a first call request for the hibernation interface to the power management service module, and receive the first target feedback information from the power core service module. The power management service module is a module in the Android system layer.

[0099] In this embodiment, when the power core service module receives a low level change at the first port, it indicates that the power core service module has received a corresponding sleep request. At this time, the power core service module sends a call request for the startIpo interface to the power management service module in the Android system layer. This startIpo interface is the sleep interface, and this call request is the first call request. Simultaneously with the power core service module sending the startIpo interface call request to the power management service module in the Android system layer, the power core service module also sends back first target feedback information via the communication module through the signal forwarding middleware. This first target feedback information informs the MCU that the system has started executing the Android system layer sleep process. In other words, when the MCU receives this first target feedback information, it can determine that the current system has started executing the Android system layer sleep process.

[0100] Step S23: Based on the first call request, control the power core service module to call the hibernation interface through the power management service module.

[0101] In this embodiment, based on the first call request sent by the power core service module to the power management service module, the power management service module will call the corresponding startIpo interface based on the first call request.

[0102] Step S24: Based on the invoked hibernation interface, execute the Android system-level hibernation process.

[0103] In this embodiment, the Android system layer hibernation process is executed based on the startIpo interface called by the power management service module, so as to control the Android system layer to hibernate.

[0104] Step S25: After the Android system layer hibernation process is completed, the power management service module sends the second target feedback information to the port driver.

[0105] In this embodiment, when the power management service module completes the sleep mode of the Android system layer, the display screen corresponding to the Android system layer has not yet entered sleep mode. It is still necessary to control the display screen corresponding to the Android system layer to enter sleep mode. In this invention, the control of the display screen corresponding to the Android system layer entering sleep mode is controlled by the vehicle's MCU. Therefore, in this invention, after the Android system layer sleep process is completed, the power management service module first controls the screen backlight drive (i.e., ...) Figure 2 The LCM_DRIVER in the power management service module sends a control signal to the port driver indicating the completion of the Android system-level sleep process. This control signal is the second target feedback information sent by the power management service module to the port driver. This second target feedback information informs the port driver that the Android system-level sleep process has been completed. In other words, upon receiving this second target feedback information, the port driver can determine that the current Android system-level sleep process has been completed. The power management service module and LCM_DRIVER notify the port driver via file I / O, and the port driver then uses GPIO pins to notify the MCU to turn the screen on or off based on the file node's status.

[0106] Step S26: Based on the second target feedback information, receive the screen-off request sent by the port driver through the second port, whereby the second port is the port through which the port driver sends the screen-on / off request to the MCU.

[0107] In this embodiment, after receiving the second target feedback information in step S25, the port driver determines that the current Android system layer hibernation process has been completed. At this time, the port driver sends a screen-off request to the display screen through the second port. When the vehicle's MCU receives this screen-off request, it determines that the Android system layer has completed the hibernation process and then controls the display screen corresponding to the Android system layer to perform screen-off hibernation. Specifically: the port driver pulls the second port low (that is... Figure 2 The system sends a screen-off request to the vehicle's MCU by using the level of GPIO4 in the second port. When the vehicle's MCU receives the level change of the second port to low, it can determine that the Android system layer sleep process has been completed and the corresponding display screen of the Android system layer needs to be turned off and put into sleep mode. The vehicle's MCU will then control the corresponding display screen of the Android system layer to turn off and put into sleep mode.

[0108] Step S27: Based on the screen-off request, control the display screen to turn off to complete the hibernation of the Android system layer.

[0109] In this embodiment, after the vehicle's MCU receives a screen-off request, it controls the Android system's display to turn off, thereby putting the entire Android system layer of the vehicle into a sleep state.

[0110] In conjunction with the above embodiments, in one implementation, the present invention also provides a power management method. In this power management method, step S3 includes steps S31 to S34:

[0111] Step S31: Determine the hibernation result of the Android system layer based on the first target feedback information and the screen off request.

[0112] In this embodiment, the vehicle's MCU is used to receive the first target feedback information and the screen-off request. Based on whether the vehicle's MCU receives the first target feedback information and the screen-off request, the vehicle's MCU can determine the hibernation result at the Android system layer. When the vehicle's MCU receives the first target feedback information and the screen-off request, it determines that the hibernation result at the Android system layer is complete. If it does not receive one or both of the first target feedback information and the screen-off request, it determines that the hibernation result at the Android system layer is not yet complete. In this case, it is necessary to continue waiting for the Android system layer to complete its hibernation. Only after the Android system layer completes its hibernation can subsequent hibernation operations proceed.

[0113] Step S32: If the hibernation result characterization receives the first target feedback information and the screen-off request, determine whether the vehicle network is in hibernation mode.

[0114] In this embodiment, when the vehicle's MCU receives the first target feedback information and the screen-off request, it determines that the Android system layer's hibernation result is complete. At this point, it further determines whether the vehicle network is in hibernation. Specifically, it determines whether the vehicle network is in hibernation by whether new CAN messages are received on the CAN bus. If no new CAN messages are received on the CAN bus, it is determined that the vehicle network is in hibernation.

[0115] Step S33: When the vehicle network is in sleep mode, control the third port connected to the communication module to send a communication sleep request to the communication module.

[0116] In this embodiment, since the vehicle network communication uses a communication module, the communication module will only enter sleep mode when the vehicle's MCU determines that the vehicle network is in sleep mode. At this time, when the vehicle's MCU determines that the vehicle network is in sleep mode, the vehicle's MCU drives the communication module via a port (i.e.,...). Figure 2 The GPIO_DRIVE control connects to the third port of the communication module (i.e., ...). Figure 2 The vehicle's MCU sends a communication sleep request to the communication module via GPIO3. Specifically, the MCU sends the communication sleep request to the communication module by pulling the level of the third port low.

[0117] Step S34: The communication module goes into sleep mode according to the communication sleep request.

[0118] In this embodiment, when the communication module receives a low level change from the third port, it can be determined that the vehicle's MCU needs to control the communication module to go into sleep mode. At this time, the communication module will execute the sleep operation based on the received level change of the third port.

[0119] In conjunction with the above embodiments, in one implementation, the present invention also provides a power management method. In this power management method, step S34 includes steps S341 to S343:

[0120] Step S341: Based on the communication sleep request, control the power management module in the communication module to execute the sleep process, send a serial port shutdown request to the signal forwarding middleware, and send a first communication sleep request to the non-power management module in the communication module.

[0121] In this embodiment, when the communication module receives a low level change from the third port, it can be determined that the vehicle's MCU needs to control the communication module to enter sleep mode. At this time, the communication module will control the power management module (i.e., ...) within the communication module based on the received level change from the third port. Figure 5 In Capower, the power management module executes its own sleep process to control the power management module to enter sleep mode, while simultaneously sending a signal forwarding middleware (i.e., Capower) to the signal forwarding middleware. Figure 2 The system sends a request to the Vehicle (MCU) to close the serial port between the communication module and the signal forwarding middleware, and sends a first communication sleep request to the non-power management modules in the communication module to control the other non-power management modules in the communication module to enter sleep mode. The signal forwarding middleware obtains the vehicle's status information from the MCU via the serial port with the communication module, and then transmits the vehicle's status information to the power core service module (NativeCorePower) via the HIDL (HAL interface definition language) interface. The power core service module then displays the vehicle's status information to the user via a pop-up window in the APP layer of the Android system layer. Other notification methods are also possible and are not specifically limited here. The vehicle's status information includes, but is not limited to, battery level, engine status, and the status signals of the driver's door and locks.

[0122] Step S342: Based on the request to close the serial port, control the signal forwarding middleware to close the serial port, and based on the first communication sleep request, control the non-power management module to execute the sleep process.

[0123] In this embodiment, the signal forwarding middleware closes the serial port between itself and the communication module upon receiving a request to close the serial port. The non-power management module within the communication module then executes its corresponding sleep procedure to enter sleep mode upon receiving a first communication sleep request.

[0124] Step S343: After the serial port is shut down and the non-power management module completes the hibernation process, control the communication module to release the wake-up lock so that the SOC kernel enters the suspend state.

[0125] In this embodiment, when the communication module detects that the serial port has been shut down and the non-power management module has also completed its sleep process, the communication module releases the wake-up lock. At this time, the SOC kernel (i.e., Figure 2 The kernel will enter a suspend state, which is a hibernation state.

[0126] In conjunction with the above embodiments, in one implementation, the present invention also provides a power management method. This power management method further includes:

[0127] Step S344: When the SOC kernel enters the suspend state, receive the first feedback information fed back by the SOC kernel through the fourth port.

[0128] In this embodiment, when the SOC kernel enters the suspend state, the SOC kernel controls the fourth port (i.e., ...) through the port driver. Figure 2 GPIO2 in the SoC sends the first feedback information to the MCU indicating that the SOC core has entered suspend state. Specifically, the SOC core sends a control signal to the port driver, and the port driver, based on this control signal, pulls the fourth port (i.e., ...) low. Figure 2 The GPIO2 level signal is used to inform the vehicle's MCU that the SOC core has entered suspend state.

[0129] Step S345: Power off according to the first feedback information to enter low power mode.

[0130] In this embodiment, when the vehicle's MCU receives the first feedback information, that is, when it receives the change in the level of the fourth port going low, it determines that the SOC core has entered the suspend state, that is, the SOC (System-on-a-Chip) where the Android architecture is located has entered the sleep state. At this time, the vehicle's MCU powers down based on the first feedback information, thereby entering the low-power mode.

[0131] In conjunction with the above embodiments, in one implementation, the present invention also provides a power management method. In this power management method, before step S2, the method further includes steps S201 to S203:

[0132] Step S201: If the target operation is to hibernate, determine whether there is a critical task, wherein the critical task is a task to be executed with a higher priority than the hibernation operation.

[0133] In this embodiment, when the vehicle's infotainment system is performing important tasks, and hibernation would terminate these tasks, to ensure their proper completion, the present invention, after the vehicle's MCU determines through its main control logic that a hibernation operation is required, further determines whether there are any critical tasks to be executed. These critical tasks are those with higher priority than the hibernation operation and are considered more important than the hibernation operation itself; hibernation will terminate the currently executing critical task.

[0134] Step S202: If a critical task exists, execute the critical task.

[0135] In this embodiment, when the vehicle's MCU determines that there are critical tasks to be executed, the execution of the sleep operation is delayed, waiting for the critical tasks to complete. The sleep operation is then executed only after all the critical tasks have been completed.

[0136] Step S203: In the absence of a critical task, perform the following step: When the target operation is hibernation, control the power core service module to hibernate at the Android system layer.

[0137] In this embodiment, when the vehicle's MCU determines that there are no critical tasks to be executed, normal sleep operation can be performed, and therefore step S2 is executed.

[0138] In conjunction with the above embodiments, in one implementation, the present invention also provides a power management method. In this power management method, before step S2, the method further includes steps S204 to S206:

[0139] Step S204: When the target operation is hibernation, determine the target state recorded by the state machine in the power core service module.

[0140] In this embodiment, when the vehicle's MCU determines that the target operation to be executed is to put the entire vehicle into a sleep state, to avoid execution errors caused by continuing the Android system layer sleep process when the vehicle's current Android system layer is already in a sleep state, this invention constructs a corresponding state machine in the power core service module. This state machine is used to record the current target state of the vehicle, where the target state can be either the recorded Android system layer being in a sleep state or the recorded Android system layer being in a wake-up state. After determining the target operation to be executed, the target operation is compared with the target state recorded in the state machine. If the target operation is related to the target state in the state machine, the target operation is not executed. Specifically: when the vehicle's MCU determines that the target operation to be executed is to put the entire vehicle into a sleep state, the target state recorded in the state machine of the power core service module is determined.

[0141] Step S205: If the target state is hibernation, perform the following step: control the communication module to hibernate according to the hibernation result of the Android system layer.

[0142] In this embodiment, when the target state currently recorded by the state machine in the power core service module is that the Android system layer is in a sleep state, it indicates that the vehicle's Android system layer is currently in a sleep state. At this time, there is no need to execute the Android system sleep process. Instead, the signal forwarding middleware directly feeds back to the MCU via the communication module that the Android system layer is in a sleep state. Based on this feedback information, the vehicle's MCU directly controls the communication module to go into sleep mode, instead of controlling the Android system layer to go into sleep mode. That is, step S2 is skipped and not executed. Instead, execution starts directly from step S3.

[0143] Step S206: If the target state is awake, perform the following step: If the target operation is hibernation, control the power core service module to hibernate at the Android system layer.

[0144] In this embodiment, when the target state currently recorded by the state machine in the power core service module is that the Android system layer is in a woke-up state, it is necessary to control the Android system layer to execute the sleep process. At this time, the execution will start from step S2 in sequence.

[0145] In this embodiment, steps S201 to S203 determine whether there are any critical tasks to be executed before the Android system-level sleep process is executed. Steps S204 to S206 determine whether the current vehicle system sleep / wake state is related to the state to be achieved by the target operation to be executed before the Android system-level sleep process is executed. These two determinations can be performed simultaneously before step S2, or individually before step S2. For example, only steps S201 to S203 can be executed before step S2, or only steps S204 to S206 can be executed before step S2, or steps S201 to S206 can be executed simultaneously before step S2.

[0146] In conjunction with the above embodiments, in one implementation, the present invention also provides a power management method. In this power management method, step S4 includes steps S41 to S44:

[0147] Step S41: When the target operation is wake-up, the control sends a communication wake-up request to the communication module via the third port connected to the communication module.

[0148] In this embodiment, when the vehicle's MCU determines that the target operation is a system wake-up operation, the vehicle's MCU drives the port (i.e., Figure 2 The GPIO_DRIVE control connects to the third port of the communication module (i.e., ...). Figure 2 The vehicle's MCU sends a communication wake-up request to the communication module via GPIO3. Specifically, the MCU sends the communication wake-up request to the communication module by pulling the level of the third port high.

[0149] Step S42: Based on the communication wake-up request, control the power management module in the communication module to execute the wake-up process, determine the heartbeat between the communication module and the communication module, send an open serial port request to the signal forwarding middleware, and send a first communication wake-up request to the non-power management module in the communication module.

[0150] In this embodiment, when the communication module receives a high-level signal from the third port, it can determine that the vehicle's MCU needs to control the communication module to wake up. At this time, the communication module will, based on the received high-level signal from the third port, control the power management module (Capower) within the communication module to execute its own wake-up process, thereby waking up the power management module. Simultaneously, it will send a signal forwarding message to the signal forwarding middleware (i.e.,...). Figure 2The vehicle sends a request to open the serial port between the communication module and the signal forwarding middleware, and sends a first communication wake-up request to the non-power management modules in the communication module to control the wake-up of other non-power management modules. Simultaneously, during the wake-up process in the communication module, the vehicle's MCU monitors its own heartbeat with the communication module in real time.

[0151] Step S43: Based on the serial port opening request, control the signal forwarding middleware to open the serial port, and based on the first communication wake-up request, control the non-power management module to execute the wake-up process.

[0152] In this embodiment, the signal forwarding middleware opens the serial port between itself and the communication module based on the received serial port open request. The non-power management module in the communication module then executes its corresponding wake-up process to wake up the device based on the received first communication wake-up request.

[0153] Step S44: After the serial port is opened and the non-power management module completes the wake-up process, control the communication module to hold the wake-up lock so that the SOC kernel enters the resume state.

[0154] In this embodiment, when the communication module detects that the serial port has been opened and the non-power management module has also completed the wake-up process, the communication module holds the wake-up lock. At this time, the SOC kernel (i.e., Figure 2 The Kernel in the process will enter the resume state, which is the wake-up state.

[0155] In conjunction with the above embodiments, in one implementation, the present invention also provides a power management method. In this power management method, step S5 includes steps S51 to S57:

[0156] Step S51: If the wake-up result indicates that the heartbeat is normal, control the first port connected to the power core service module to send a wake-up request to the power core service module.

[0157] In this embodiment, when the vehicle's MCU determines that the wake-up result of the communication module indicates that the heartbeat between the vehicle's MCU and the communication module is normal, it determines that the communication module is in the wake-up process. At this time, it immediately starts controlling the Android system layer to wake up. At this time, the vehicle's MCU drives the communication module through the port driver (i.e., ... Figure 2 The GPIO_DRIVE control in the module connects to the first port of the power core service module (NativeCorePower). Figure 2The MCU sends a wake-up request to the power core service module via GPIO1. Specifically, the vehicle's MCU sends a wake-up request to the power core service module by pulling the level of the first port high. When the power core service module receives the change in the level of the first port to high, it can determine that the vehicle's MCU wants to perform a wake-up operation.

[0158] Step S52: Based on the wake-up request, control the power core service module to send a second call request for the wake-up interface to the power management service module.

[0159] In this embodiment, when the power core service module receives a high level change at the first port, it indicates that the power core service module has received a corresponding wake-up request. At this time, the power core service module will send a call request for the stopIpo interface to the power management service module in the Android system layer. The stopIpo interface is the wake-up interface, and the call request is the second call request.

[0160] Step S53: According to the second call request, control the power core service module to call the wake-up interface through the power management service module.

[0161] In this embodiment, based on the second call request sent by the power core service module to the power management service module, the power management service module will call the corresponding stopIpo interface based on the second call request.

[0162] Step S54: Based on the invoked wake-up interface, execute the Android system layer wake-up process.

[0163] In this embodiment, the Android system layer wake-up process is executed based on the stopIpo interface called by the power management service module to control the Android system layer to wake up. This enables parallel wake-up of the communication module and the Android system layer. That is, when the heartbeat between the MCU and the communication module is detected to be normal, the Android system layer wake-up process begins immediately, while the communication module is also in the wake-up process at the same time, thus achieving parallel wake-up of the communication module and the Android system layer.

[0164] Step S55: After the Android system layer wake-up process is completed, the power management service module sends third feedback information to the port driver.

[0165] In this embodiment, when the power management service module completes the wake-up of the Android system layer, the display screen corresponding to the Android system layer has not yet been woken up. It is still necessary to control the wake-up of the display screen corresponding to the Android system layer. In this invention, the wake-up of the display screen corresponding to the Android system layer is controlled by the vehicle's MCU. Therefore, after the Android system layer wake-up process is completed, the power management service module activates the screen backlight driver (i.e.,...) Figure 2 The LCM_DRIVER in the port driver sends a control signal indicating that the Android system layer wake-up process has been completed. This control signal is the third feedback information, which indicates that the Android system layer wake-up process has been completed. In other words, when the port driver receives this third feedback information, it can determine that the Android system layer wake-up process has been completed.

[0166] Step S56: Based on the third feedback information, receive the screen-on request sent by the port driver through the second port.

[0167] In this embodiment, after receiving the third feedback information in step S55, the port driver determines that the Android system layer wake-up process has been completed. At this time, the port driver sends a screen-on request to the display screen through the second port. When the vehicle's MCU receives this screen-on request, it determines that the Android system layer wake-up process has been completed, and then controls the display screen corresponding to the Android system layer to enter sleep mode. Specifically: the port driver pulls the second port high (that is... Figure 2 The system sends a screen-on request to the vehicle's MCU by using the GPIO4 level. When the vehicle's MCU receives the change in the level of the second port to high, it can determine that the Android system layer wake-up process has been completed and the corresponding display screen of the Android system layer needs to be turned on and woken up. The vehicle's MCU will then control the corresponding display screen of the Android system layer to turn on and wake up.

[0168] Step S57: Based on the screen-on request, control the display screen to turn on to complete the wake-up of the Android system layer.

[0169] In this embodiment, after the vehicle's MCU receives the screen-on request, it controls the Android system's display screen to display, thereby waking up the entire Android system layer of the vehicle.

[0170] The power management method provided in this invention first determines the target operation to be executed based on vehicle status information. If the target operation is wake-up, the communication module is controlled to execute a communication wake-up process, and a heartbeat is established with the communication module. If the heartbeat is normal, the power core service module is controlled to execute an Android system-level wake-up process through the power management service module. Once the Android system-level wake-up process is complete, a screen-on request is received. Based on the screen-on request, the screen is controlled to turn on. Thus, this invention pushes the main control logic of power management down to the MCU (Microcontroller Unit, i.e., the microcontroller configured in the vehicle), and simultaneously pushes the core service control system of power management down to the native layer of the Android framework (i.e., the system runtime library layer). This decouples the high dependency between the overall power management system and the Android system layer, shortening the signal transmission link of the wake-up preconditions, thereby effectively improving the stability of power management and effectively avoiding the occurrence of black screen problems. In addition, by sinking the main control logic of power management to the MCU (Microcontroller Unit, i.e., the microcontroller configured in the vehicle) and the core service control system of power management to the native layer of the Android framework, this invention separates the wake-up of the Android system layer and the wake-up of the communication module. At the same time, the two can be woken up in parallel. While ensuring wake-up efficiency, by waking up the two separately, compared with the previous method of mixing the wake-up of the two together, the wake-up process and interaction process are simplified, thereby reducing the complexity of logic processing. This can also effectively improve the stability of power management and thus effectively avoid the occurrence of black screen problems.

[0171] In conjunction with the above embodiments, in one implementation, the present invention also provides a power management method. This power management method further includes step S501: in the event of a heartbeat abnormality, restarting the SOC and returning to step: according to the communication wake-up request, controlling the power management module in the communication module to execute a wake-up process, determining the heartbeat between the module and the communication module, sending an open serial port request to the signal forwarding middleware, and sending a first communication wake-up request to the non-power management module in the communication module.

[0172] In this embodiment, when step S42 determines that the heartbeat between the vehicle's MCU and the communication module is abnormal, step S501 is executed to restart the SOC (System-on-a-Chip) where the Android architecture is located, and then return to step S42 to continue controlling the communication module to execute the communication wake-up process and determine the heartbeat between itself and the communication module.

[0173] In conjunction with the above embodiments, in one implementation, the present invention also provides a power management method. In this power management method, before step S5, the method further includes:

[0174] Step S051: If the target operation is wake-up, determine the target state recorded in the state machine of the power core service module.

[0175] In this embodiment, when the vehicle's MCU determines that the target operation to be executed is a system wake-up operation, to avoid execution errors caused by continuing to execute the wake-up operation when the vehicle's Android system layer is already in a wake-up state, this invention constructs a corresponding state machine in the power core service module. This state machine is used to record the current target state of the vehicle, where the target state can be either the Android system layer being in a sleep state or the Android system layer being in a wake-up state. After determining the target operation to be executed, the target operation is compared with the target state recorded in the state machine. If the target operation is related to the target state in the state machine, the target operation is not executed. Specifically: when the vehicle's MCU determines that the target operation to be executed is a system wake-up operation, the target state recorded in the state machine of the power core service module is determined.

[0176] Step S052: When the target state is awake, disable the wake-up of the Android system layer.

[0177] In this embodiment, when the target state currently recorded by the state machine in the power core service module is that the Android system layer is in a wake-up state, there is no need to perform a wake-up operation on the Android system layer. Only the communication module is controlled to perform a wake-up operation, and the Android system layer is no longer controlled to perform a wake-up operation, that is, step S5 is no longer executed.

[0178] Step S053: When the target state is in hibernation, execute the following step: based on the wake-up result of the communication module, control the power core service module to wake up the Android system layer.

[0179] In this embodiment, if the target state currently recorded by the state machine in the power core service module is that the Android system layer is in a sleep state, it indicates that the vehicle is currently in a sleep state, so it can be woken up normally, and step S5 is executed normally.

[0180] In conjunction with the above embodiments, in one implementation, the present invention also provides a power management method. This power management method further includes steps S102 to S103:

[0181] Step S102: When the target operation is independent wake-up of the communication module, control the communication module to execute the communication wake-up process and determine the heartbeat between the communication module and the communication module.

[0182] In this embodiment, the present invention sinks the main control logic of power management to the MCU (Microcontroller Unit, i.e., the microcontroller configured in the vehicle), and simultaneously sinks the core service control system of power management to the native layer of the Android framework (i.e., the system runtime library layer). The vehicle's MCU executes the main control logic of power management, and based on the determination result of the main control logic, it can directly perform sleep or wake-up operations on the Android system layer and the communication module. When the vehicle's MCU receives the status information of various components of the vehicle and performs main control logic judgment on the received status information of various components, if it determines that the target operation corresponding to the current status information of each component is the independent wake-up of the communication module, the vehicle's MCU sends a communication wake-up request to the communication module. After the communication module receives the communication wake-up request, it executes the communication wake-up process. At the same time, the vehicle's MCU monitors the heartbeat between the MCU and the communication module to determine whether the heartbeat between the vehicle's MCU and the communication module is normal. Alternatively, when the vehicle's MCU receives a remote control signal to independently wake up the communication module, the MCU sends a communication wake-up request to the communication module. Upon receiving this request, the communication module executes the communication wake-up process. Simultaneously, the MCU monitors the heartbeat between itself and the communication module to determine if the heartbeat is normal. This invention provides a power management method that enables independent sleep and wake-up of the communication module. This allows for targeted wake-up and sleep of the communication module only when the vehicle's infotainment system itself or when the vehicle's infotainment system needs to use the communication service with a remote device, effectively reducing energy consumption. The remote device includes, but is not limited to, communication with a mobile terminal and the cloud. The implementation of controlling the communication module to execute the communication wake-up process and determining the heartbeat between it and the communication module is similar to the implementation of steps S41 to S44 above, except that the target operation is independent wake-up of the communication module, and when the heartbeat between the vehicle's MCU and the communication module is normal, no Android system-level wake-up is performed.

[0183] Step S103: In the event of the abnormal heartbeat, restart the SOC and return to step: In the case of the target operation being the independent wake-up of the communication module, control the communication module to execute the communication wake-up process and determine the heartbeat between the communication module and the communication module.

[0184] In this embodiment, when step S102 determines that the heartbeat between the vehicle's MCU and the communication module is abnormal, step S103 is executed to restart the SOC (System-on-a-Chip) containing the Android architecture, and then the process returns to step S102 to continue controlling the communication module to execute the communication wake-up process and determine its own heartbeat with the communication module. If the MCU determines that its heartbeat with the communication module is normal, it determines that the communication module is in the wake-up process and waits for the wake-up to complete.

[0185] In conjunction with the above embodiments, in one implementation, the present invention also provides a power management method. This power management method further includes step S01: initializing the power management in the SOC when the Android system starts.

[0186] In this embodiment, when the Android system is restarted after a power outage, the power management in the SOC (System-on-a-Chip) containing the Android architecture is first initialized so that the vehicle's MCU and SOC can implement the steps in the power management method provided by this invention. Specifically: as Figure 3As shown, when the Android system restarts after a power outage, the power core service module is created through the init process. This module holds the kernel wake-up lock and initializes its state machine. The state machine is the internal logic of the power core service module (NativeCorePower), not a module within the power management system architecture. The pin-to-pin listener (GPIO listener) between the SOC and MCU is registered in the PowerPin program of the HAL layer. This PowerPin program, which has registered the GPIO listener, notifies the SOC's power core service module of GPIO1 status changes by obtaining the driver node status of the GPIO1 pin in real time. Simultaneously, the Android vehicle process service is obtained, and a vehicle listener is registered to monitor vehicle status information. This involves obtaining the vehicle's attribute acquisition interface through the HIDL reflection mechanism and sending the monitored vehicle status information to the power core service module. The core service module then uses this interface to display the vehicle status information to the user through the APP layer in the Android system layer, such as pop-ups. The vehicle status information includes, but is not limited to, battery level, engine status, and driver's side door and lock status signals. The monitored vehicle status information is obtained by the MCU and transmitted via a serial port middleware (i.e.,...) between the MCU and the communication module. Figure 2 The UART in the signal is sent to the signal forwarding middleware (i.e., Figure 2 The vehicle in the middleware is from the SOC kernel (i.e., the serial port middleware). Figure 2 A UART program (located in the kernel) communicates with the communication module via a serial port. The communication module and the signal forwarding middleware communicate via message queues (i.e.,...). Figure 2 (Message_queue in the code). The signal forwarding middleware and the power core service module communicate via HIDL, the power core service module and the power management service module communicate via AIDL binder, the power core service module and the APP communicate via AIDL binder, the communication module and the power core service module communicate with the port driver via file nodes, and the port driver and the MCU communicate via I / O.

[0187] In one embodiment of the present invention, such as Figure 4 As shown, Figure 4The diagram shows the overall flowchart of a power management method provided by this invention. First, the state changes of each GPIO pin are monitored. Based on the monitored states of each GPIO pin, it is determined whether the task to be executed is a sleep task or a wake-up task.

[0188] After detecting the GPIO pins corresponding to the Android system layer (such as...) Figure 2 When GPIO1 is pulled low, the task to be executed is determined to be a sleep task. At this time, the state of the Android system layer recorded in the state machine of the power core service module is checked. If the Android system layer is already in sleep mode, there is no need to perform sleep control at the Android system layer. At this time, the relevant services are shut down directly through the vehicle's MCU control communication module to put the system into sleep mode and release the wake-up lock so that the SOC core can put the system into sleep mode. After the SOC core goes into sleep mode, the vehicle's MCU is powered down to enter low-power mode.

[0189] When the vehicle's MCU control communication module is independently woken up, the vehicle's MCU only uses port drivers to connect the GPIO pins corresponding to the communication module (such as...). Figure 2 When GPIO3 in the SOC is pulled high, the communication module, upon detecting the state change of this GPIO pin, will hold a wake-up lock to control the SOC kernel to wake up and then initiate relevant services to wake up the communication module. At this time, the Android system layer is not woken up.

[0190] When the vehicle's MCU simultaneously controls the wake-up of the communication module and the Android system layer, the vehicle's MCU uses port drivers to control the GPIO pins corresponding to the communication module (such as...). Figure 2 The GPIO3 pin in the Android system layer is pulled high, and the corresponding GPIO pin (such as...) is also activated. Figure 2 By pulling the GPIO1 level high, the Android system layer is woken up simultaneously with the control communication module. At the same time, the vehicle's MCU can determine whether to wake up the display screen corresponding to the Android system layer based on its own main control logic, thereby achieving whole-device wake-up without the screen being lit.

[0191] In one embodiment of the present invention, such as Figure 5 As shown, Figure 5This diagram illustrates a sleep process flowchart of a power management method provided by the present invention. First, the MCU performs a main control logic check to determine if sleep conditions are met. If sleep conditions are met, it determines if there are any pending critical tasks. If there are, the critical tasks are executed. If no critical tasks are pending, a request is made to the power core service module to initiate Android system-level sleep. Upon receiving this sleep request, feedback information indicating the start of the Android system-level sleep process is returned to the MCU, and a first call request is sent to the PMS to invoke the sleep interface to execute the PMS sleep process, which is the execution of the Android system-level sleep process. After execution, a status information indicating the completion of Android system-level sleep is returned to the power core service module. Simultaneously, the SOC kernel requests the MCU to control the corresponding display screen of the Android system layer to enter sleep mode. Upon receiving this request, the MCU controls the corresponding display screen of the Android system layer to enter sleep mode. Based on the received screen-off request and the received feedback information indicating the start of the Android system-level sleep process, it is determined that Android system-level sleep is complete. At this point, it is further determined whether the vehicle's overall network is in sleep mode. When the vehicle network completes its sleep state, it requests sleep mode from the communication module. The power management module of the communication module executes its own sleep process based on the received communication sleep request. Simultaneously, it sends a request to the signal forwarding middleware to close the serial port and a first communication sleep request to the non-power management module within the communication module. This controls the signal forwarding middleware to close the serial port and the non-power management module to execute its own sleep process. Feedback information indicating the start of the sleep process is also sent to the MCU. After the serial port is closed and the non-power management module completes its sleep state, the wake-up lock is released, causing the SOC kernel to enter suspend mode, i.e., enter sleep mode. The SOC kernel then sends feedback information to the MCU indicating that it has entered sleep mode. Based on the received feedback information indicating the start of the sleep process and the SOC kernel entering sleep mode, the communication module's sleep state is determined to be complete. At this point, the MCU powers down and enters low-power mode.

[0192] In one embodiment of the present invention, such as Figure 6 As shown, Figure 6This diagram illustrates the wake-up flowchart of a power management method provided by the present invention. First, the MCU performs a main control logic check to determine if the wake-up conditions are met. If the conditions are met, a communication wake-up request is sent to the communication module. The power management module of the communication module executes its own wake-up process based on the received communication wake-up request, and simultaneously sends a request to the signal forwarding middleware to open the serial port and a first communication wake-up request to the non-power management module in the communication module. This controls the signal forwarding middleware to open the serial port and controls the non-power management module to execute its own wake-up process and open the public network. After the serial port is opened and the non-power management module is woken up, a wake-up lock is held to allow the SOC kernel to enter resume mode, i.e., to enter the wake-up state. Simultaneously, after sending the communication wake-up request, the MCU begins monitoring the heartbeat between itself and the communication module to determine if the heartbeat is normal. If the heartbeat is abnormal, the SOC is restarted. If the heartbeat is normal, a request for Android system-level wake-up is sent to the power core service module. Upon receiving the wake-up request, the system sends feedback information to the MCU indicating the start of the Android system-level wake-up process and sends a second call request to the PMS to invoke the wake-up interface and execute the PMS wake-up process, which is the Android system-level wake-up process. After execution, it returns Android system-level wake-up completion status information to the power core service module and simultaneously requests the MCU via the SOC kernel to control the corresponding Android system-level display to wake up. Upon receiving this request, the MCU controls the corresponding Android system-level display to wake up. When the MCU receives the feedback information indicating the start of the Android system-level wake-up process, it determines that the wake-up is complete.

[0193] Based on the same inventive concept, such as Figure 7 As shown, an embodiment of the present invention provides a power management system, the system 700 including: an MCU 701 and a power core service module 702; the MCU 701 includes a target operation determination module 7011, a first sleep control module 7012, a second sleep control module 7013, a first wake-up module 7014, and a second wake-up module 7015.

[0194] The target operation determination module 7011 is used to determine the target operation to be executed based on the vehicle status information.

[0195] The first hibernation control module 7012 is used to control the power core service module to hibernate at the Android system layer when the target operation is hibernation, wherein the power core service module is a module in the native layer.

[0196] The second sleep control module 7013 is used to control the communication module to enter sleep mode based on the sleep result of the Android system layer;

[0197] The first wake-up module 7014 is used to control the communication module to wake up when the target operation is wake-up;

[0198] The second wake-up module 7015 is used to control the power core service module to wake up the Android system layer based on the wake-up result of the communication module.

[0199] Optionally, the first hibernation control module 7012 includes:

[0200] A sleep request sending module is configured to control a first port connected to the power core service module to send a sleep request to the power core service module when the target operation is sleep.

[0201] The first call request sending module is used to control the power core service module to send a first call request for the sleep interface to the power management service module according to the sleep request, and to receive the first target feedback information fed back by the power core service module. The power management service module is a module in the Android system layer.

[0202] The hibernation interface calling module is used to control the power core service module to call the hibernation interface through the power management service module according to the first calling request;

[0203] The hibernation control submodule is used to execute the Android system-level hibernation process based on the hibernation interface being called;

[0204] The first information feedback module is used to send the second target feedback information to the port driver when the Android system layer hibernation process is completed.

[0205] The screen off request receiving module is used to receive the screen off request sent by the port driver through the second port according to the feedback information of the second target. The second port is the port through which the port driver sends the screen on / off request to the MCU.

[0206] The hibernation completion determination module is used to control the display screen to turn off the screen according to the screen-off request, so as to complete the hibernation of the Android system layer.

[0207] Optionally, the second hibernation control module 7013 includes:

[0208] The hibernation result determination module is used to determine the hibernation result of the Android system layer based on the first target feedback information and the screen-off request;

[0209] The vehicle network sleep determination module is used to determine whether the vehicle network is in sleep mode when the sleep result characterization receives the first target feedback information and the screen off request;

[0210] A communication sleep request sending module is used to control a third port connected to the communication module to send a communication sleep request to the communication module when the vehicle network is in sleep mode.

[0211] A communication sleep control submodule is used to put the communication module into sleep mode according to the communication sleep request.

[0212] Optionally, the communication sleep control submodule includes:

[0213] The first sleep process execution module is used to control the power management module in the communication module to execute the sleep process according to the communication sleep request, and send a serial port shutdown request to the signal forwarding middleware, and send the first communication sleep request to the non-power management module in the communication module.

[0214] The second sleep process execution module is used to control the signal forwarding middleware to close the serial port according to the serial port closure request, and to control the non-power management module to execute the sleep process according to the first communication sleep request.

[0215] The wake-up lock release module is used to control the communication module to release the wake-up lock when the serial port is shut down and the non-power management module completes the hibernation process, so that the SOC kernel enters the suspend state.

[0216] Optionally, the method further includes:

[0217] The feedback information receiving module is used to receive the first feedback information fed back by the SOC kernel through the fourth port when the SOC kernel enters the suspend state.

[0218] The power-down control module is used to power down the device based on the first feedback information to enter a low-power mode.

[0219] Optionally, the system 700 further includes:

[0220] The critical task determination module is used to determine whether there is a critical task when the target operation is to hibernate, wherein the critical task is a task to be executed with a higher priority than the hibernation operation.

[0221] The critical task execution module is used to execute critical tasks when they exist.

[0222] The first hibernation control module is used to control the first hibernation control module 7012 to execute when there is no critical task.

[0223] Optionally, the system 700 further includes:

[0224] The first target state determination module is used to determine the target state recorded in the state machine of the power core service module when the target operation is hibernation.

[0225] The hibernation process control module is used to control the second hibernation control module 7013 to execute when the target state is hibernation;

[0226] The second sleep control module is used to control the execution of the first sleep control module 7012 when the target state is awake.

[0227] Optionally, the first wake-up module 7014 includes:

[0228] A communication wake-up request sending module is used to control a third port connected to the communication module to send a communication wake-up request to the communication module when the target operation is wake-up;

[0229] The first communication wake-up module is used to control the power management module in the communication module to execute the wake-up process according to the communication wake-up request, determine the heartbeat between the communication module and the communication module, send a serial port opening request to the signal forwarding middleware, and send the first communication wake-up request to the non-power management module in the communication module.

[0230] The second communication wake-up module is used to control the signal forwarding middleware to enable the serial port according to the serial port enable request, and to control the non-power management module to execute the wake-up process according to the first communication wake-up request.

[0231] The wake-up lock holding module is used to control the communication module to hold the wake-up lock when the serial port is opened and the non-power management module completes the wake-up process, so that the SOC kernel enters the resume state.

[0232] Optionally, the second wake-up module 7015 includes:

[0233] A wake-up request sending module is used to control a first port connected to the power core service module to send a wake-up request to the power core service module when the wake-up result indicates that the heartbeat is normal.

[0234] The second call request sending module is used to control the power core service module to send a second call request for the wake-up interface to the power management service module according to the wake-up request;

[0235] The wake-up interface calling module is used to control the power core service module to call the wake-up interface through the power management service module according to the second calling request;

[0236] The Android system-level wake-up submodule is used to execute the Android system-level wake-up process based on the invoked wake-up interface;

[0237] The second information feedback module is used to send third feedback information to the port driver when the Android system layer wake-up process is completed.

[0238] The screen-on request receiving submodule is used to receive the screen-on request sent by the port driver through the second port based on the third feedback information.

[0239] The screen-on control module is used to control the display screen to turn on according to the screen-on request, so as to complete the wake-up of the Android system layer.

[0240] Optionally, the system 700 further includes:

[0241] The restart module is used to restart the SOC in the event of an abnormal heartbeat and to control the execution of the first communication wake-up module.

[0242] Optionally, the system 700 further includes:

[0243] The second target state determination module is used to determine the target state recorded in the state machine of the power core service module when the target operation is wake-up.

[0244] The wake-up process control module is used to prevent the Android system layer from being woken up when the target state is woken up.

[0245] The second communication wake-up module is used to control the execution of the first communication wake-up module when the target state is in sleep mode.

[0246] Optionally, the system 700 further includes:

[0247] An independent wake-up control module is used to control the communication module to execute the communication wake-up process and determine the heartbeat between the communication module and the target operation of the communication module when the target operation is the independent wake-up of the communication module.

[0248] The first restart module is used to restart the SOC in the event of the heartbeat abnormality and return to the following steps: when the target operation is the independent wake-up of the communication module, control the communication module to perform the communication wake-up process and determine the heartbeat between the communication module and the communication module.

[0249] Optionally, the system 700 further includes:

[0250] The initialization module is used to initialize the power management in the SOC when the Android system starts up.

[0251] Based on the same inventive concept, one embodiment of the present invention provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the steps of a power management method as described in the first aspect of the present invention.

[0252] Based on the same inventive concept, one embodiment of the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of a power management method as described in the first aspect of the present invention.

[0253] As the system implementation is basically similar to the method implementation, it is described in a relatively simple way. For relevant details, please refer to the description of the system implementation.

[0254] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0255] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0256] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, embodiments of the present invention can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0257] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0258] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0259] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0260] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.

[0261] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0262] The power management method, system, electronic device, and storage medium provided by the present invention have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A power management method, characterized in that, Applied to an MCU, the method includes: Based on the vehicle status information, determine the target operation to be performed; When the target operation is to sleep, the power core service module is controlled to perform sleep at the Android system layer. The power core service module is a module in the native layer. Based on the hibernation result of the Android system layer, control the communication module to hibernate; When the target operation is to wake up, the control communication module is woken up; Based on the wake-up result of the communication module, the power core service module is controlled to wake up the Android system layer.

2. The power management method according to claim 1, characterized in that, When the target operation is hibernation, controlling the power core service module to hibernate at the Android system layer includes: When the target operation is to hibernate, the control sends a hibernation request to the power core service module via the first port connected to the power core service module. According to the hibernation request, the power core service module is controlled to send a first call request for the hibernation interface to the power management service module, and the first target feedback information is received from the power core service module. The power management service module is a module in the Android system layer. Based on the first call request, the power core service module is controlled to call the hibernation interface through the power management service module; Based on the invoked sleep interface, the Android system layer sleep process is executed; When the Android system layer hibernation process is completed, the power management service module sends a second target feedback message to the port driver. Based on the second target feedback information, the port driver receives the screen-off request sent by the port driver through the second port, where the second port is the port through which the port driver sends the screen-on / off request to the MCU; Based on the screen-off request, the display screen is controlled to turn off, thereby completing the hibernation process at the Android system layer.

3. The power management method according to claim 2, characterized in that, Based on the hibernation result of the Android system layer, control the communication module to hibernate, including: Based on the feedback information from the first target and the screen-off request, the hibernation result of the Android system layer is determined; If the sleep result characterization receives the first target feedback information and the screen-off request, it is determined whether the vehicle network is in sleep mode; When the vehicle network is in sleep mode, the control third port connected to the communication module sends a communication sleep request to the communication module. The communication module goes into sleep mode upon receiving the communication sleep request.

4. The power management method according to claim 3, characterized in that, The step of the communication module going into sleep mode according to the communication sleep request includes: According to the communication sleep request, the power management module in the communication module is controlled to execute the sleep process, and a serial port shutdown request is sent to the signal forwarding middleware, and a first communication sleep request is sent to the non-power management module in the communication module; Based on the request to close the serial port, the signal forwarding middleware is controlled to close the serial port, and based on the first communication sleep request, the non-power management module is controlled to execute the sleep process. After the serial port is closed and the non-power management module completes the hibernation process, the control communication module releases the wake-up lock so that the SOC kernel enters the suspend state.

5. A power management method according to claim 4, characterized in that, The method further includes: When the SOC kernel enters the suspend state, the first feedback information fed back by the SOC kernel through the fourth port is received; Based on the first feedback information, power is turned off to enter low-power mode.

6. The power management method according to claim 1, characterized in that, When the target operation is hibernation, before the power core service module performs hibernation at the Android system layer, the method further includes: When the target operation is to hibernate, determine whether there is a critical task, wherein the critical task is a task to be executed with a higher priority than the hibernation operation; In cases where critical tasks exist, execute those critical tasks. In the absence of critical tasks, the following steps are performed: When the target operation is to hibernate, the power core service module is controlled to hibernate at the Android system layer.

7. The power management method according to claim 1, characterized in that, When the target operation is hibernation, before the power core service module performs hibernation at the Android system layer, the method further includes: When the target operation is to sleep, the target state recorded by the state machine in the power core service module is determined. If the target state is sleep, the following steps are performed: Based on the sleep result of the Android system layer, control the communication module to enter sleep mode; If the target state is awake, the following steps are performed: If the target operation is hibernation, the power core service module is controlled to hibernate at the Android system layer.

8. The power management method according to claim 1, characterized in that, When the target operation is wake-up, the control communication module is woken up, including: When the target operation is wake-up, the control sends a communication wake-up request to the communication module via the third port connected to the communication module. According to the communication wake-up request, the power management module in the communication module is controlled to execute the wake-up process, determine the heartbeat between the communication module and the communication module, send an open serial port request to the signal forwarding middleware, and send a first communication wake-up request to the non-power management module in the communication module. Based on the serial port opening request, the signal forwarding middleware is controlled to open the serial port, and based on the first communication wake-up request, the non-power management module is controlled to execute the wake-up process. With the serial port enabled and the non-power management module completing the wake-up process, the control communication module holds the wake-up lock to enable the SOC kernel to enter the resume state.

9. A power management method according to claim 8, characterized in that, The step of controlling the power core service module to wake up the Android system layer based on the wake-up result of the communication module includes: If the wake-up result indicates that the heartbeat is normal, the control sends a wake-up request to the power core service module via the first port connected to the power core service module. Based on the wake-up request, the power core service module is controlled to send a second call request for the wake-up interface to the power management service module; According to the second call request, the power core service module is controlled to call the wake-up interface through the power management service module; Based on the invoked wake-up interface, the Android system layer wake-up process is executed; When the Android system layer wake-up process is completed, the power management service module sends a third feedback message to the port driver. Based on the third feedback information, the port driver receives the screen-opening request sent through the second port. Based on the screen-on request, the display screen is controlled to turn on in order to complete the wake-up of the Android system layer.

10. A power management method according to claim 8, characterized in that, The method further includes: In the event of an abnormal heartbeat, the SOC is restarted and the process returns to the following steps: based on the communication wake-up request, the power management module in the communication module is controlled to execute the wake-up process, and the heartbeat between the communication module and the communication module is determined, and a serial port enable request is sent to the signal forwarding middleware, and a first communication wake-up request is sent to the non-power management module in the communication module.

11. A power management method according to claim 8, characterized in that, Based on the wake-up result of the communication module, before the power core service module performs the Android system layer wake-up, the method further includes: When the target operation is wake-up, the target state recorded in the state machine of the power core service module is determined; When the target state is awake, waking up the Android system layer is prohibited; When the target state is sleep, the following steps are performed: based on the wake-up result of the communication module, the power core service module is controlled to wake up the Android system layer.

12. The power management method according to claim 1, characterized in that, The method further includes: When the target operation is independent wake-up of the communication module, control the communication module to execute the communication wake-up process and determine the heartbeat between the communication module; In the event of the abnormal heartbeat, the SOC is restarted and the process returns to the following steps: if the target operation is the independent wake-up of the communication module, the communication module is controlled to execute the communication wake-up process and the heartbeat between the communication module and the communication module is determined.

13. The power management method according to claim 1, characterized in that, The method further includes: When the Android system starts up, the power management in the SOC is initialized.

14. A power management system, characterized in that, The system includes an MCU, a power core service module, and a power management service module; the MCU includes a target operation determination module, a first sleep control module, a second sleep control module, a first wake-up module, and a second wake-up module. The target operation determination module is used to determine the target operation to be executed based on the vehicle status information. The first hibernation control module is used to control the power core service module to hibernate at the Android system layer when the target operation is hibernation, wherein the power core service module is a module in the native layer. The second sleep control module is used to control the communication module to enter sleep mode based on the sleep result of the Android system layer; The first wake-up module is used to control the communication module to wake up when the target operation is wake-up; The second wake-up module is used to control the power core service module to wake up the Android system layer based on the wake-up result of the communication module.

15. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of a power management method as described in any one of claims 1 to 13.

16. A computer-readable storage medium storing a computer program thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of a power management method as described in any one of claims 1 to 13.

Images