A whole vehicle pre-hibernation and wake-up decoupling design method and related device

Abstract

The application relates to the technical field of vehicle controllers, in particular to a whole-vehicle pre-hibernation and wake-up decoupling design method and related device. The method comprises the following steps: when a whole vehicle is in a hibernation state, if a functional demand instruction of the whole vehicle is received, the whole vehicle enters a segmented wake-up state, and a plurality of target controllers needing to be woken up are determined in a plurality of controllers of the whole vehicle according to the functional demand instruction; for each target controller, a wake-up state of the target controller is determined, a network message management process of the target controller is determined according to the wake-up state of the target controller; and pre-hibernation and hibernation management is performed on each target controller according to the network message management process of each target controller. The application can wake up the required controllers according to the scene demand, avoid the controllers irrelevant to the scene demand from being woken up synchronously, and relieve the problem of power waste.

Description

Technical Field

[0001] This application relates to the field of vehicle controller technology, and in particular to a decoupling design method and related device for vehicle pre-sleep and wake-up. Background Technology

[0002] Currently, with the increasing functional demands after a vehicle is powered off, network management technology is needed to implement vehicle sleep / wake-up functionality. Taking a gateway-centralized architecture as an example, the vehicle's network segments might be divided into powertrain, chassis, information, and intelligent driving segments. Each network segment is connected to a gateway, and message exchanges between the controllers corresponding to each segment are routed and forwarded through the gateway. In existing technologies, the vehicle's controllers typically sleep and wake up simultaneously. After power-off, if any controller has a wake-up request, it sends a network management message, causing all the vehicle's controllers to wake up synchronously. This results in a large current draw after power-off, potentially leading to a risk of battery drain. Summary of the Invention

[0003] To address the aforementioned issues, this application provides a decoupling design method and related apparatus for vehicle pre-sleep and wake-up, which can wake up the required controllers according to scenario requirements, avoiding the synchronous wake-up of controllers unrelated to scenario requirements, and alleviating the problem of energy waste.

[0004] According to one aspect of the embodiments of this application, a decoupling design method for vehicle pre-sleep and wake-up is proposed, the method comprising: When the vehicle is in a dormant state, if a functional requirement instruction for the vehicle is received, the vehicle enters a segmented wake-up state and determines multiple target controllers that need to be woken up from among the multiple controllers of the vehicle according to the functional requirement instruction. For each target controller, the wake-up state of the target controller is determined, and the network packet management process of the target controller is determined according to the wake-up state of the target controller. The wake-up state is used to characterize whether the target controller is actively woken up or passively woken up. According to the network packet management process of each target controller, pre-sleep and sleep management are performed on each target controller. The process of determining the network packet management of the target controller based on its wake-up state includes: If the wake-up state of the target controller is active wake-up, then the first timer used to characterize whether the network management operation has timed out is started, and network management messages are sent to the gateway at a preset message sending period. If the functional requirements corresponding to the functional requirements instruction of the whole vehicle are met, then the sending of network management messages is stopped, the first timer is reset, and the target controller enters the pre-sleep state. The pre-sleep state is used to characterize that the target controller has stopped sending network management messages. If the wake-up state of the target controller is passive wake-up, then a second timer for characterizing the duration of network management message transmission is started, and network management messages are sent to the gateway at the preset message transmission period. If the second timer expires, then the target controller enters the pre-sleep state. Once all the target controllers have entered the pre-sleep state, they exit the segmented wake-up state of the whole vehicle and enter the sleep state of the whole vehicle.

[0005] In the above scheme, determining the multiple target controllers that need to be woken up among the multiple controllers of the vehicle according to the functional requirement instruction includes: If the functional requirement instruction is a power replenishment requirement instruction, then the multiple target controllers that need to be woken up are determined to be energy-related controllers, power-related controllers, chassis-related controllers, comfort-related controllers, and connectivity-related controllers. If the functional requirement instruction is a power battery thermal runaway early warning requirement instruction, then the multiple target controllers that need to be woken up are determined to be energy-related controllers, information-related controllers, chassis-related controllers, comfort-related controllers, and connectivity-related controllers. If the functional requirement instruction is a door opening warning requirement instruction, then the multiple target controllers that need to be woken up are determined to be controllers related to assisted driving, controllers related to comfort, controllers related to connectivity, controllers related to chassis, and controllers related to information. If the functional requirement instruction is a digital key unlocking requirement instruction, then the multiple target controllers that need to be woken up are determined to be controllers related to digital keys, controllers related to comfort, controllers related to chassis, controllers related to connectivity, and controllers related to information.

[0006] In the above scheme, the step of performing pre-sleep and sleep management on each target controller according to the network packet management process of each target controller includes: For each target controller, the pre-sleep condition of the target controller is determined according to the network packet management process of the target controller. After the target controller meets the pre-sleep condition, the target controller is controlled to enter the pre-sleep state. Once all target controllers have entered the pre-sleep state, control each target controller to enter the sleep state.

[0007] In the above scheme, the pre-sleep conditions of the target controller are determined through the following steps: If the functional requirement instruction is a power replenishment requirement instruction, then the pre-sleep condition is determined to be either the completion of power replenishment for the whole vehicle or the power battery management system of the whole vehicle stopping the network management message for continuing power replenishment. If the functional requirement instruction is a power battery thermal runaway early warning requirement instruction, then the pre-dormancy condition is determined to be a network management message for power battery power generation to stop and continue thermal runaway early warning. If the functional requirement instruction is a door opening warning requirement instruction, then the pre-sleep condition is determined to be that the vehicle domain controller stops sending network management messages to continue performing door opening warnings; If the functional requirement instruction is a digital key unlocking requirement instruction, then the pre-sleep condition is determined to be that the entire vehicle has been unlocked or the controller related to the digital key has stopped sending network management messages.

[0008] In the above scheme, the functional requirements corresponding to the functional requirements instruction of the whole vehicle are satisfied specifically by the target controller reaching the pre-sleep condition.

[0009] In the above scheme, when the vehicle is in sleep mode, all controllers of the vehicle stop sending network management messages.

[0010] In the above scheme, during the segmented wake-up state, the target controller sends or receives network management messages, while all other controllers stop sending network management messages.

[0011] According to one aspect of the embodiments of this application, a decoupling design device for vehicle pre-sleep and wake-up is proposed, the device comprising: The first determining unit is used to enter the segmented wake-up state of the vehicle when the vehicle is in a dormant state and receives a functional requirement instruction from the vehicle, and to determine multiple target controllers that need to be woken up from multiple controllers of the vehicle according to the functional requirement instruction. The second determining unit is used to determine the wake-up state of each target controller, and to determine the network packet management process of the target controller based on the wake-up state of the target controller, wherein the wake-up state is used to characterize whether the target controller is actively woken up or passively woken up; The management unit is used to perform pre-sleep and sleep management on each of the target controllers according to the network packet management process of each target controller; The process of determining the network packet management of the target controller based on its wake-up state includes: If the wake-up state of the target controller is active wake-up, then the first timer used to characterize whether the network management operation has timed out is started, and network management messages are sent to the gateway at a preset message sending period. If the functional requirements corresponding to the functional requirements instruction of the whole vehicle are met, then the sending of network management messages is stopped, the first timer is reset, and the target controller enters the pre-sleep state. The pre-sleep state is used to characterize that the target controller has stopped sending network management messages. If the wake-up state of the target controller is passive wake-up, then a second timer for characterizing the duration of network management message transmission is started, and network management messages are sent to the gateway at the preset message transmission period. If the second timer expires, then the target controller enters the pre-sleep state. Once all the target controllers have entered the pre-sleep state, they exit the segmented wake-up state of the whole vehicle and enter the sleep state of the whole vehicle. According to one aspect of the embodiments of this application, a computer program product is provided, the computer program product including a computer program, the computer program being read and executed by a processor of an electronic device, causing the electronic device to perform the decoupled design method for vehicle pre-sleep and wake-up as described above.

[0012] The beneficial effects of this application are as follows: This application proposes a segmented wake-up state for the entire vehicle, that is, dividing the system by controllers corresponding to different network segments. Based on functional requirement commands, multiple target controllers that need to be woken up are determined. By identifying whether a target controller is actively or passively woken up, the corresponding network packet management process is initiated. After the functional requirement command is met, the system enters a pre-sleep state. After all target controllers have entered the pre-sleep state, the segmented wake-up state of the entire vehicle is exited, and the entire vehicle enters a sleep state. This application avoids the energy consumption problem caused by the entire vehicle simultaneously waking up and sleeping. Furthermore, when a target controller is passively woken up, the second timer expires, indicating that the target controller has experienced a state abnormality, forcing the target controller to enter a pre-sleep state, further reducing energy consumption. Attached Figure Description

[0013] Figure 1 This is a system architecture diagram of the decoupling design method for vehicle pre-sleep and wake-up provided in the embodiments of this application; Figure 2 A flowchart illustrating the decoupling design method for vehicle pre-sleep and wake-up provided in this application embodiment; Figure 3 This is an architecture diagram of the controllers corresponding to each network segment provided in the embodiments of this application; Figure 4 This is a schematic diagram of the network packet management process provided in the embodiments of this application; Figure 5 This is an example diagram of the sleep / wake-up conditions provided in the embodiments of this application; Figure 6 A block diagram of a decoupling design device for vehicle pre-sleep and wake-up provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of a terminal provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of a server provided in an embodiment of this application. Detailed Implementation

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

[0015] It should be noted that while some processes described in the specification, claims, and accompanying drawings include multiple steps appearing in a specific order, it should be clearly understood that these steps may not be performed in the order they appear herein, or may be performed in parallel. The step numbers are merely used to distinguish different steps and do not themselves represent any execution order. Furthermore, descriptions such as "first," "second," or "objective" in this document are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. "Multiple" in this document refers to at least two.

[0016] It is worth noting that in the specific embodiments of this application, data related to messages sent by the controller is involved. When the above embodiments of this application are applied to specific products or technologies, permission or consent from the target object is required, and the collection, use, and processing of related data must comply with relevant laws, regulations, and standards. For example, when an embodiment of this application needs to obtain data related to messages sent by the controller, separate permission or consent from the target object can be obtained through pop-up windows or redirection to a confirmation page. After obtaining the separate permission or consent from the target object, the data related to messages sent by the controller that enable the embodiments of this application to operate normally can then be obtained.

[0017] Please see Figure 1 , Figure 1 This is a system architecture diagram of the decoupled design method for vehicle pre-sleep and wake-up provided in this application embodiment. It includes a terminal 140, an Internet connection 130, a gateway 120, a server 110, etc.

[0018] Terminal 140 can take various forms, including desktop computers, laptops, PDAs (personal digital assistants), mobile phones, vehicle terminals, and dedicated terminals. Furthermore, it can be a single device or a collection of multiple devices. For example, multiple desktop computers can be interconnected via a local area network, sharing a single monitor to work collaboratively, forming a single terminal 140. Terminal 140 can communicate with the Internet 130 via wired or wireless means to exchange data.

[0019] Server 110 refers to a computer system capable of providing certain services to terminal 140. Compared to ordinary terminal 140, server 110 has higher requirements in terms of stability, security, and performance. Server 110 can be a single high-performance computer in a network platform, a cluster of multiple high-performance computers, a portion of a single high-performance computer (e.g., a virtual machine), or a combination of portions of multiple high-performance computers (e.g., virtual machines). Server 110 can also communicate with the Internet 130 via wired or wireless means to exchange data.

[0020] Gateway 120, also known as an internetwork connector or protocol converter, is a computer system or device that acts as a translator, enabling network interconnection at the transport layer. It bridges the gap between two systems using different communication protocols, data formats, languages, or even completely different architectures. Gateways can also provide filtering and security functions. Messages sent from terminal 140 to server 110 are forwarded to the corresponding server 110 via gateway 120. Messages sent from server 110 to terminal 140 are also forwarded to the corresponding terminal 140 via gateway 120.

[0021] The following provides a detailed description of the specific implementation methods of the embodiments of this application: Please see Figure 2 , Figure 2 This is a flowchart illustrating the decoupling design method for vehicle pre-sleep and wake-up provided in this application embodiment. The decoupling design method for vehicle pre-sleep and wake-up can be implemented by server 110 and / or terminal 140. Figure 2 The decoupling design method for vehicle pre-sleep and wake-up shown includes: Step 210: When the vehicle is in a dormant state, if a functional requirement instruction for the vehicle is received, the vehicle enters a segmented wake-up state and determines multiple target controllers that need to be woken up from among the multiple controllers of the vehicle according to the functional requirement instruction. Step 220: For each target controller, determine the wake-up state of the target controller, and determine the network packet management process of the target controller based on the wake-up state of the target controller. The wake-up state is used to characterize whether the target controller is actively woken up or passively woken up. Step 230: Perform pre-sleep and sleep management on each target controller according to the network packet management process of each target controller; The process of determining the network packet management of the target controller based on its wake-up state includes: If the wake-up state of the target controller is active wake-up, then the first timer used to characterize whether the network management operation has timed out is started, and network management messages are sent to the gateway at a preset message sending period. If the functional requirements corresponding to the functional requirements instruction of the whole vehicle are met, then the sending of network management messages is stopped, the first timer is reset, and the target controller enters the pre-sleep state. The pre-sleep state is used to characterize that the target controller has stopped sending network management messages. If the wake-up state of the target controller is passive wake-up, then a second timer for characterizing the duration of network management message transmission is started, and network management messages are sent to the gateway at the preset message transmission period. If the second timer expires, then the target controller enters the pre-sleep state. Once all the target controllers have entered the pre-sleep state, they exit the segmented wake-up state of the whole vehicle and enter the sleep state of the whole vehicle.

[0022] First, the controllers corresponding to each network segment in this application are as follows: Figure 3 As shown, it includes controllers related to energy, power, comfort, information, connectivity, chassis, driver assistance (amplitude driving), and digital key.

[0023] A specific flowchart can be shown as follows: Figure 4 As shown, NMstart: Network management startup state. In this state, timers TNMTimeout and TActiveMin are started. Timer TNMTimeout monitors whether network management-related operations time out. After successfully receiving or sending an NM (Network Management) message, timer TNMTimeout will be reset. Timer TActiveMin ensures the shortest time for sending network management messages after each controller wakes up. After TActiveMin times out, the controller will enter the NMNormal state. If the controller is woken up by other controllers and has no communication needs, it will send network management messages at a TNMCycle cycle. When TActiveMin times out, it will directly enter the NMNormalPresleep state.

[0024] NMNormal (Normal Wake-up State): This state is where each controller wakes up when communication is required. In this state, network management messages are sent at a cycle of TNMCycle. The timer TNMTimeout is reset after a controller successfully receives or sends an NM message. Each controller will enter the NMNormalPresleep state after meeting the pre-sleep conditions.

[0025] NMNormalPresleep: In this state, the controller meets the pre-sleep conditions and stops sending network management messages. When the ECU successfully receives a network management message, it resets the TNMTimeout timer. If the controller receives a wake-up message from another controller or an NM message while in this state, it will maintain this state. Once all network segments in the vehicle meet the pre-sleep conditions, they will synchronously transition to the NMWaitBusSleep state.

[0026] NMwaitBusSleep state: In this state, the controller stops all network-related activities and application packets are not sent. When the timer TWBS expires, the controller enters the NMBusSleep state.

[0027] NMBusSleep: This state controller will switch to sleep mode, in which the controller will eventually reduce power consumption to a certain level.

[0028] For example Figure 5 As shown, Figure 5 Based on the scenario, the gateway's modification strategy is as follows, specifying the pre-sleep and wake-up conditions for each controller. Figure 5 As shown, each network segment is woken up according to the functional scenario and put into sleep after meeting the pre-sleep conditions, which solves the drawbacks of sleeping and waking up at the same time and decouples the sleep and wake-up of the whole vehicle. Figure 5 EV stands for Energy CAN, PT for Power CAN, CHS for Chassis CAN, DK for Digital Key CAN, Connect for Connectivity CAN, Info for Information CAN, Comfort for Comfort CAN, and ADAS for Driver Assistance CAN.

[0029] the following Figure 5 Taking the EEM (Electronic Power Registry) power replenishment requirement as an example. Trigger: After power-down, the gateway detects a power replenishment requirement. Network segment wake-up: The gateway only initiates NM message transmission for EV_CAN, Comfort_CAN, CHS_CAN, PT_CAN, and Connect_CAN; other network segments (such as ADAS_CAN) maintain NM inactivity (sleep). Sleep trigger: After determining there is no power replenishment request, the gateway waits for all controllers to stop transmitting NM messages. Subsequently, the gateway stops transmitting NM messages, and the entire vehicle enters sleep mode according to the network specification state machine. EEM refers to the power module within the gateway.

[0030] For example, even if the HAD controller fails to hibernate after power-down due to its own reasons, it will not cause other network segments to remain awake, because the door opening warning function is only effective for T3 minutes. During the T3 minutes after power-down, the network segments related to the door opening warning will remain normally awake. After T3 minutes, even if the HAD controller malfunctions and fails to hibernate, other network segments will still meet the pre-hibernation conditions and enter hibernation mode.

[0031] In some embodiments, determining the multiple target controllers that need to be woken up among multiple controllers in the vehicle according to the functional requirement instructions includes: If the functional requirement instruction is a power replenishment requirement instruction, then the multiple target controllers that need to be woken up are determined to be energy-related controllers, power-related controllers, chassis-related controllers, comfort-related controllers, and connectivity-related controllers. If the functional requirement instruction is a power battery thermal runaway early warning requirement instruction, then the multiple target controllers that need to be woken up are determined to be energy-related controllers, information-related controllers, chassis-related controllers, comfort-related controllers, and connectivity-related controllers. If the functional requirement instruction is a door opening warning requirement instruction, then the multiple target controllers that need to be woken up are determined to be controllers related to assisted driving, controllers related to comfort, controllers related to connectivity, controllers related to chassis, and controllers related to information. If the functional requirement instruction is a digital key unlocking requirement instruction, then the multiple target controllers that need to be woken up are determined to be controllers related to digital keys, controllers related to comfort, controllers related to chassis, controllers related to connectivity, and controllers related to information.

[0032] The specific functional scenarios can be roughly divided into the following categories: 1. EEM power replenishment requirement - In this scenario, the gateway needs to determine and then wake up the following network segments (corresponding to the power replenishment requirement command). 1. The energy CAN (the network segment where the energy-related controllers are located) is woken up by the gateway: The HCU (vehicle control unit energy CAN) requests the BMS (battery management system) to supply high voltage; 2. The power CAN (the network segment where the power-related controller is located) is awakened by the gateway: the HCU requests high voltage to determine the TCU (transmission) gear position information; 3. The chassis CAN (the network segment where the chassis-related controllers are located) is awakened by the gateway: The HCU requests high voltage and needs to determine the braking status of the IBC (brake controller); 4. The Comfort CAN (the network segment where the comfort-related controllers are located) is awakened by the gateway: The HCU needs to determine the power-on status of the BCM (Body Control Controller) to request high voltage. 5. The interconnected CAN (the network segment where the interconnected controller is located) is awakened - data upload is performed.

[0033] 2. BMS thermal runaway - In this scenario, the BMS (Battery Management System) will only make a judgment when it is woken up (corresponding to the power battery thermal runaway warning instruction). It will not wake up on its own. If there is no thermal runaway request within T2 minutes after power-off, the relevant network segment is considered as one of the conditions for pre-sleep.

[0034] 1. The EV-CAN remains awake for 2 minutes after power-down; 2. Comfort-CAN remains awake for T2 minutes after power-down: DCU thermal runaway gating unlock; 3. Info-CAN remains awake for T2 minutes after power-down: CSC thermal runaway alarm; 4. After power-off, the device remains awake for 2 minutes (accumulated data). 5. CHS-CAN remains awake for T2 minutes after power-down: Vehicle wake-up requires obtaining the IBC signal to illuminate the brake lights, and the brake pedal status needs to be obtained before the vehicle starts.

[0035] 3. HAD Door Opening Warning Function - This function only takes effect within 3 minutes after power-down and will not be woken up except upon power-up. After 3 minutes, other network segments will be considered as meeting one of the pre-sleep conditions (corresponding to the door opening warning requirement command).

[0036] 1. ADAS-CAN remains awake for 3 minutes after power-down; 2. Comfort CAN remains awake for 3 minutes after power failure: HAD needs to determine the status of the gated DCU; 3. After the CAN bus is powered off, it remains awake for three minutes (T3): the CSC provides animation and voice prompts; 4. The interconnected CAN maintains wake-up within T3 minutes after power-down - embedded point; 5. After the chassis CAN is powered off, it remains awake for T3 minutes: The vehicle needs to obtain the IBC signal to illuminate the brake lights to wake up, and the brake pedal status needs to be obtained before the vehicle starts. 4. Digital Key NFC Unlock - DK actively wakes up the gateway, and the gateway synchronously wakes up other network segments (corresponding to the key unlocking command). 1. DK-CAN active wake-up; 2. Comfort-CAN is awakened: BCM unlocked; 3. CHS-CAN is awakened: The vehicle needs to obtain the IBC signal to illuminate the brake lights to wake up. The brake pedal status needs to be obtained before the vehicle starts. 4. Connect is awakened - instrumentation; 5. Info-CAN remains awake after power-off: CSC provides animation and voice prompts.

[0037] 5. TBOX Remote Control Function - Connect actively wakes up the gateway, and the gateway synchronously wakes up other network segments; 1. Interconnection - CAN active wake-up; 2. Comfort - CAN is awakened: BCM performs unlocking and other related actions; 3. Chassis-CAN wake-up: Vehicle wake-up requires obtaining IBC signal to illuminate brake lights. Before starting the vehicle, the brake pedal status needs to be obtained. 4. Internet access is activated - data tracking; 5. Chassis-CAN is awakened: The vehicle needs to obtain the IBC signal to illuminate the brake lights before it can be awakened. The brake pedal status needs to be obtained before the vehicle starts.

[0038] Six: When the four doors and two hoods are open, the position lights are on, the high beams are on, and the seat memory function is activated, the BCM-related functions include Comfort active wake-up and gateway synchronous wake-up of other network segments; 1. Comfort - CAN Active Wake-up; 2. Chassis-CAN is awakened: The vehicle needs to obtain the IBC signal to illuminate the brake lights to wake up. The brake pedal status needs to be obtained before the vehicle starts. 3. Digital Key - CAN Wake-up: Unlock the vehicle via NFC inside the car. The entire vehicle needs to be woken up by any means, such as swiping a card to start it. 4. Information - CAN is awakened: Main unit displays information on all four doors and two covers; 5. Interconnection - CAN is awakened - embedded point.

[0039] 7. Hazard alarm switch scenario: Special case, if the double flashing lights remain on 4 minutes after power-off, only the following two wake-up channels are retained, while the other channels meet the pre-sleep conditions; 1. Comfort - CAN wake-up; 2. Information is activated: displayed; 3. Chassis-CAN is awakened: The vehicle needs to obtain the IBC signal to illuminate the brake lights before it can be awakened. The brake pedal status needs to be obtained before the vehicle starts.

[0040] In summary, to address the issue of vehicle-wide sleep / wake-up issues in gateway-integrated network architectures, this application implements a decoupled design for vehicle sleep / wake-up. It modifies the gateway's strategy, allowing the gateway to rationally divide wake-up network segments based on specific functional scenarios to prevent a single controller from experiencing sleep / wake-up problems, thus preventing all vehicle network segments from remaining awake for extended periods and causing vehicle battery depletion.

[0041] Please see Figure 6 , Figure 6This is a schematic diagram of the decoupling design device for vehicle pre-sleep and wake-up provided in an embodiment of this application. The decoupling design device is applied to computer equipment and may include: The first determining unit 401 is used to enter the segmented wake-up state of the vehicle when the vehicle is in a dormant state and receives a functional requirement instruction from the vehicle, and to determine multiple target controllers that need to be woken up from multiple controllers of the vehicle according to the functional requirement instruction. The second determining unit 402 is used to determine the wake-up state of each target controller, and determine the network packet management process of the target controller based on the wake-up state of the target controller, wherein the wake-up state is used to characterize whether the target controller is actively woken up or passively woken up. Management unit 403 is used to perform pre-sleep and sleep management on each of the target controllers according to the network packet management process of each target controller; The process of determining the network packet management of the target controller based on its wake-up state includes: If the wake-up state of the target controller is active wake-up, then the first timer used to characterize whether the network management operation has timed out is started, and network management messages are sent to the gateway at a preset message sending period. If the functional requirements corresponding to the functional requirements instruction of the whole vehicle are met, then the sending of network management messages is stopped, the first timer is reset, and the target controller enters the pre-sleep state. The pre-sleep state is used to characterize that the target controller has stopped sending network management messages. If the wake-up state of the target controller is passive wake-up, then a second timer for characterizing the duration of network management message transmission is started, and network management messages are sent to the gateway at the preset message transmission period. If the second timer expires, then the target controller enters the pre-sleep state. Once all the target controllers have entered the pre-sleep state, they exit the segmented wake-up state of the whole vehicle and enter the sleep state of the whole vehicle.

[0042] Reference Figure 7 , Figure 7 To implement the structural block diagram of a portion of the terminal 140 in this application embodiment, the terminal 140 includes: a radio frequency (RF) circuit 710, a memory 715, an input unit 730, a display unit 740, a sensor 750, an audio circuit 760, a wireless fidelity (WiFi) module 770, a processor 780, and a power supply 790, among other components. Those skilled in the art will understand that... Figure 7The terminal 140 structure shown does not constitute a limitation on a mobile phone or computer, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0043] The RF circuit 710 can be used to receive and transmit signals during information transmission or calls. In particular, it receives downlink information from the base station and processes it with the processor 780; in addition, it transmits uplink data to the base station.

[0044] The memory 715 can be used to store software programs and modules. The processor 780 executes various functional applications of the terminal and the decoupled design processing of the vehicle's pre-sleep and wake-up by running the software programs and modules stored in the memory 715.

[0045] The input unit 730 can be used to receive input numeric or character information, and to generate key signal inputs related to the terminal's settings and function control. Specifically, the input unit 730 may include a touch panel 731 and other input devices 732.

[0046] The display unit 740 can be used to display input or provided information, as well as various menus of the terminal. The display unit 740 may include a display panel 741.

[0047] Audio circuitry 760, speaker 761, and microphone 762 provide an audio interface.

[0048] In this embodiment, the processor 780 included in the terminal 140 can execute the decoupled design method for vehicle pre-sleep and wake-up in the previous embodiment.

[0049] The terminal 140 in this application embodiment includes, but is not limited to, mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, and aircraft. This application embodiment can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, and assisted driving.

[0050] Figure 8This is a partial structural block diagram of a server 110 implementing an embodiment of this application. The server 110 can vary significantly due to different configurations or performance characteristics, and may include one or more central processing units (CPUs) 822 (e.g., one or more processors) and memory 832, and one or more storage media 830 (e.g., one or more mass storage devices) for storing application programs 842 or data 844. The memory 832 and storage media 830 can be temporary or persistent storage. The program stored in the storage media 830 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the server 110. Furthermore, the CPU 822 may be configured to communicate with the storage media 830 and execute the series of instruction operations in the storage media 830 on the server 110.

[0051] Server 110 may also include one or more power supplies 826, one or more wired or wireless network interfaces 850, one or more input / output interfaces 858, and / or one or more operating systems 841, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0052] The central processing unit 822 in server 110 can be used to execute the decoupled design method for vehicle pre-sleep and wake-up according to the embodiments of this application.

[0053] This application also provides a computer-readable storage medium for storing program code, which is used to execute the decoupling design method for vehicle pre-sleep and wake-up in the foregoing embodiments.

[0054] This application also provides a computer program product, which includes a computer program. The processor of a computer device reads and executes the computer program, causing the computer device to perform the aforementioned decoupled design method for vehicle pre-sleep and wake-up.

[0055] Furthermore, the terms “comprising” and “including”, and any variations thereof, are intended to cover non-exclusive inclusion, such that a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product, or apparatus.

[0056] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0057] It should be understood that in the description of the embodiments of this application, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

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

[0059] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments of this application, depending on actual needs.

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

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

[0062] It should also be understood that the various implementation methods provided in this application can be combined arbitrarily to achieve different technical effects.

[0063] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0064] The above is a detailed description of the embodiments of this application. However, this application is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this application. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A decoupled design method for vehicle pre-sleep and wake-up, characterized in that, The method includes: When the vehicle is in a dormant state, if a functional requirement instruction for the vehicle is received, the vehicle enters a segmented wake-up state and determines multiple target controllers that need to be woken up from among the multiple controllers of the vehicle according to the functional requirement instruction. For each target controller, the wake-up state of the target controller is determined, and the network packet management process of the target controller is determined according to the wake-up state of the target controller. The wake-up state is used to characterize whether the target controller is actively woken up or passively woken up. According to the network packet management process of each target controller, pre-sleep and sleep management are performed on each target controller. The process of determining the network packet management of the target controller based on its wake-up state includes: If the wake-up state of the target controller is active wake-up, then the first timer used to characterize whether the network management operation has timed out is started, and network management messages are sent to the gateway at a preset message sending period. If the functional requirements corresponding to the functional requirements instruction of the whole vehicle are met, then the sending of network management messages is stopped, the first timer is reset, and the target controller enters the pre-sleep state. The pre-sleep state is used to characterize that the target controller has stopped sending network management messages. If the wake-up state of the target controller is passive wake-up, then a second timer for characterizing the duration of network management message transmission is started, and network management messages are sent to the gateway at the preset message transmission period. If the second timer expires, then the target controller enters the pre-sleep state. Once all the target controllers have entered the pre-sleep state, they exit the segmented wake-up state of the whole vehicle and enter the sleep state of the whole vehicle.

2. The decoupling design method for vehicle pre-sleep and wake-up according to claim 1, characterized in that, The step of determining the multiple target controllers that need to be woken up from among the multiple controllers of the vehicle according to the functional requirement instructions includes: If the functional requirement instruction is a power replenishment requirement instruction, then the multiple target controllers that need to be woken up are determined to be energy-related controllers, power-related controllers, chassis-related controllers, comfort-related controllers, and connectivity-related controllers. If the functional requirement instruction is a power battery thermal runaway early warning requirement instruction, then the multiple target controllers that need to be woken up are determined to be energy-related controllers, information-related controllers, chassis-related controllers, comfort-related controllers, and interconnection-related controllers. If the functional requirement instruction is a door opening warning requirement instruction, then the multiple target controllers that need to be woken up are determined to be controllers related to assisted driving, controllers related to comfort, controllers related to connectivity, controllers related to chassis, and controllers related to information. If the functional requirement instruction is a digital key unlocking requirement instruction, then the multiple target controllers that need to be woken up are determined to be controllers related to digital keys, controllers related to comfort, controllers related to chassis, controllers related to connectivity, and controllers related to information.

3. The decoupling design method for vehicle pre-sleep and wake-up according to claim 2, characterized in that, The step of performing pre-sleep and sleep management on each target controller according to the network packet management process of each target controller includes: For each target controller, the pre-sleep condition of the target controller is determined according to the network packet management process of the target controller. After the target controller meets the pre-sleep condition, the target controller is controlled to enter the pre-sleep state. Once all target controllers have entered the pre-sleep state, control each target controller to enter the sleep state.

4. The decoupling design method for vehicle pre-sleep and wake-up according to claim 3, characterized in that, The pre-sleep conditions of the target controller are determined through the following steps: If the functional requirement instruction is a power replenishment requirement instruction, then the pre-sleep condition is determined to be either the completion of power replenishment for the whole vehicle or the power battery management system of the whole vehicle stopping the network management message for continuing power replenishment. If the functional requirement instruction is a power battery thermal runaway early warning requirement instruction, then the pre-dormancy condition is determined to be a network management message for power battery power generation to stop and continue thermal runaway early warning. If the functional requirement instruction is a door opening warning requirement instruction, then the pre-sleep condition is determined to be that the vehicle domain controller stops sending network management messages to continue performing door opening warnings; If the functional requirement instruction is a digital key unlocking requirement instruction, then the pre-sleep condition is determined to be that the entire vehicle has been unlocked or the controller related to the digital key has stopped sending network management messages.

5. The decoupling design method for vehicle pre-sleep and wake-up according to claim 4, characterized in that, Specifically, the functional requirements corresponding to the functional requirements instructions of the whole vehicle are satisfied when the target controller reaches the pre-sleep condition.

6. The decoupling design method for vehicle pre-sleep and wake-up according to claim 4, characterized in that, When the vehicle is in sleep mode, all controllers of the vehicle stop sending network management messages.

7. The decoupling design method for vehicle pre-sleep and wake-up according to claim 1, characterized in that, In the segmented wake-up state, the target controller sends or receives network management messages, while all other controllers stop sending network management messages.

8. A decoupling design device for vehicle pre-sleep and wake-up, characterized in that, The device includes: The first determining unit is used to enter the segmented wake-up state of the vehicle when the vehicle is in a dormant state and receives a functional requirement instruction from the vehicle, and to determine multiple target controllers that need to be woken up from multiple controllers of the vehicle according to the functional requirement instruction. The second determining unit is used to determine the wake-up state of each target controller, and to determine the network packet management process of the target controller based on the wake-up state of the target controller, wherein the wake-up state is used to characterize whether the target controller is actively woken up or passively woken up; The management unit is used to perform pre-sleep and sleep management on each of the target controllers according to the network packet management process of each target controller; The process of determining the network packet management of the target controller based on its wake-up state includes: If the wake-up state of the target controller is active wake-up, then the first timer used to characterize whether the network management operation has timed out is started, and network management messages are sent to the gateway at a preset message sending period. If the functional requirements corresponding to the functional requirements instruction of the whole vehicle are met, then the sending of network management messages is stopped, the first timer is reset, and the target controller enters the pre-sleep state. The pre-sleep state is used to characterize that the target controller has stopped sending network management messages. If the wake-up state of the target controller is passive wake-up, then a second timer for characterizing the duration of network management message transmission is started, and network management messages are sent to the gateway at the preset message transmission period. If the second timer expires, then the target controller enters the pre-sleep state. Once all the target controllers have entered the pre-sleep state, they exit the segmented wake-up state of the whole vehicle and enter the sleep state of the whole vehicle.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the decoupling design method for vehicle pre-sleep and wake-up as described in any one of claims 1 to 7.

10. A computer program product, the computer program product comprising a computer program, characterized in that, The computer program is read and executed by the processor of the electronic device, causing the electronic device to perform the decoupled design method for vehicle pre-sleep and wake-up as described in any one of claims 1 to 7.

Images