A control method and system for a vehicle in a rest mode

Abstract

The application provides a control method and system in a vehicle nap mode, the method comprising: assigning a unique node identification and a message receiving port to each subscription node; collecting original state messages, uniformly encapsulating the original state messages into a nap scene state frame in a standard format; inputting the nap scene state frame into an internal logic unit of a finite state machine to complete current nap scene state jump determination; based on a target scene state output by the finite state machine, matching the node identification of each subscription node to generate a node-specific subscription collaborative control message; distributing the collaborative control message to the subscription node with the corresponding node identification through a nap-specific interaction bus, and each subscription node executes corresponding hardware adjustment operation after analyzing the message; and receiving hardware execution feedback messages returned by each subscription node in real time, re-encapsulating the feedback messages to update the nap scene state frame and backfilling the nap scene state frame to the finite state machine to realize scene state cyclic iteration determination. The application can greatly improve control efficiency.

Description

Technical Field

[0001] This invention relates to the field of automotive technology, and in particular to a control method and system for a vehicle in a rest mode. Background Technology

[0002] With the development of automotive intelligence, the vehicle rest mode has become a standard feature in new energy vehicles, providing users with a resting environment through seat posture adjustment and cabin environment control. However, the safety protection mechanisms of the existing rest mode are significantly lagging behind: current seat anti-pinch solutions generally rely on post-event triggering logic based on abnormal motor current and speed, only stopping after the seat has pressed against an obstacle. This is unsuitable for low-resistance scenarios such as children and lightweight objects. Specifically, in some cases of children being injured by zero-gravity seats, lightweight occupants did not reach the motor's anti-pinch threshold, causing the protection mechanism to completely fail. At the same time, existing solutions lack a pre-detection step before folding down, and lack dual verification of rear occupant visual recognition and seat pressure sensing, failing to fundamentally avoid the risk of compression during seat folding down.

[0003] At the energy management level, existing rest modes generally employ rigid control logic based on fixed thresholds: they only execute power-off or energy-saving strategies based on the power battery's SOC threshold and preset rest duration, without considering the user's actual rest state. This logic is prone to two extreme problems: first, when the user is in deep sleep, the vehicle may be forcibly powered off due to reaching a fixed duration or battery charge threshold, causing the air conditioning to shut down and the environment to change abruptly, severely impacting the rest experience; second, to ensure continuous full-power operation for comfort, the power battery may be over-discharged, damaging battery life and even affecting subsequent vehicle starting. Existing solutions do not establish a dynamic correlation between the user's sleep state and energy allocation, failing to balance rest experience and battery safety.

[0004] Furthermore, the existing nap mode's interaction logic and various control modules are independent of each other, failing to form a scenario-based collaborative mechanism: the activation process uses a uniform 1-second countdown or no confirmation design, without setting up differentiated mandatory secondary confirmation mechanisms for high-risk scenarios such as the presence of elderly people or children in the back seats, which easily leads to the risk of misoperation; at the same time, the three major modules of safety protection, energy management, and interactive control operate independently, without achieving the sharing and linkage of detection data. Specifically, when a passenger is detected in the back seat, it is impossible to simultaneously adjust the seat reclining angle, optimize energy distribution, and enhance interactive warnings, resulting in the optimization effects of each module being fragmented and failing to form an overall improvement in safety and experience. Summary of the Invention

[0005] Based on this, the purpose of the present invention is to provide a control method and system for vehicle rest mode, so as to solve the problem that the interaction logic of the rest mode in the prior art is independent of each control module and does not form a scenario-based collaborative mechanism, which leads to a reduction in user experience.

[0006] The first aspect of the present invention proposes: A control method for a vehicle in a rest mode, wherein the method includes: Establish a dedicated interactive bus channel for in-vehicle naps, register each hardware control unit in the cabin that participates in nap control as a bus subscription node, and assign a unique node identifier and message receiving port to each subscription node; Collect vehicle parking status messages, occupant vital signs sampling messages, and original status messages of various hardware units in the cabin, and encapsulate them into a standard format rest scene status frame. Retrieve the finite state machine of the rest scenario pre-stored in the vehicle domain controller, input the rest scenario state frame into the internal logic unit of the finite state machine, and complete the current rest scenario state transition determination. Based on the target scenario state output by the finite state machine, the node identifiers of each subscribed node are matched to generate a node-specific subscription-based collaborative control message; The collaborative control message is distributed to the subscription node with the corresponding node identifier through the dedicated interactive bus of the rest. After parsing the message, each subscription node performs the corresponding hardware adjustment operation. The system receives hardware execution feedback messages from each subscription node in real time, repackages and updates the rest scene state frame, and feeds it back into the finite state machine to achieve iterative determination of the scene state.

[0007] The beneficial effects of this invention are as follows: This technical solution establishes a dedicated interactive bus channel for in-vehicle rest, unifying the access of various hardware control units as subscription nodes. This effectively breaks down the technical barriers of independent control modules in existing rest modes, achieving standardized interconnection and interoperability of multiple hardware units in the cockpit. By uniformly encapsulating multi-source operating conditions, vital signs, and hardware status messages into standard rest scenario status frames, and combining this with the finite state machine built into the in-vehicle domain controller to complete centralized determination and transition of scenario states, a complete rest scenario-based collaborative control mechanism is constructed, solving the core problems of scattered interaction logic and lack of global collaboration in the original system. Based on the node identifier, dedicated collaborative control messages are distributed in a targeted manner, ensuring the consistency of timing and accuracy of execution of various hardware adjustment actions, avoiding response deviations caused by independent control. At the same time, through closed-loop feedback of hardware execution messages and iterative updates of status frames, the control strategy can be dynamically adjusted according to real-time operating conditions, occupant vital signs, and hardware status, continuously adapting to the dynamic needs of rest scenarios, significantly improving the user experience of in-vehicle rest scenarios. The standardized bus architecture also simultaneously improves the system's scalability and functional iteration efficiency.

[0008] Furthermore, the steps of establishing a dedicated interactive bus channel for in-vehicle naps, registering each hardware control unit involved in nap control within the cabin as a bus subscription node, and assigning a unique node identifier and message receiving port to each subscription node include: The vehicle bus network is divided into sections, and an independent transmission bandwidth is isolated as a dedicated interactive bus channel for rest. The bus message transmission priority is configured to be higher than that of regular cockpit control messages. It traverses the cockpit seat controller, air conditioning controller, window controller, interior lighting controller, and audio-visual controller to complete the identification of hardware units; Each identified hardware unit is assigned a unique binary node identifier. Simultaneously, each node identifier is bound to an independent message receiving port within the bus channel. A node port mapping table is generated and stored locally.

[0009] Furthermore, the step of collecting vehicle parking status messages, occupant vital sign sampling messages, and original status messages of various hardware units in the cabin, and uniformly encapsulating them into a standard format nap scene status frame includes: Read raw data on parking gear position, electronic handbrake lock, and vehicle power level from the vehicle's VCU and generate a parking condition message. The vehicle collects data on human respiration, heart rate, and lying posture using in-vehicle vital signs sensors, and generates occupant vital signs sampling reports. Read the current gear, power, opening degree, and opening / closing status data of each subscription node respectively, and generate the original status message of the hardware unit; Set a unified frame header, frame check bit, and data segmentation field, and concatenate the three types of messages in a fixed data segmentation order to encapsulate and generate a single-frame rest scene status frame.

[0010] Furthermore, the step of retrieving the finite state machine for the rest scenario pre-stored in the vehicle domain controller, inputting the rest scenario state frame into the internal logic unit of the finite state machine, and completing the current rest scenario state transition determination includes: The finite state machine internally divides into four basic scenario states: standby state, nap start state, nap maintain state, and nap exit state, and stores the threshold conditions for transitions between each state. Analyze the segmented data within the state frame of the rest scene and extract the parking condition threshold, occupant vital signs threshold, and hardware status threshold. The extracted thresholds are compared one by one with the pre-stored jump trigger condition thresholds of the finite state machine, and the target scene state after matching is output.

[0011] Furthermore, the step of generating a node-specific subscription-based collaborative control message by matching the node identifier of each subscribing node with the target scenario state output by the finite state machine includes: A pre-stored scene state-node control parameter mapping table is used, which records the adjustment parameter range corresponding to each node identifier under each type of target scene state. Based on the target scene state, retrieve the adjustment parameter range of all nodes in the mapping table, and combine it with the original hardware state within the current rest scene state frame to correct the adjustment parameters of each node. Using the corresponding node identifier as the message target address, and carrying the corrected adjustment parameters and message check code, a unique collaborative control message is independently generated for each subscribing node.

[0012] Furthermore, the steps of receiving hardware execution feedback messages from each subscribed node in real time, re-encapsulating and updating the rest scene state frame and feeding it back into the finite state machine to realize the iterative determination of the scene state include: Set a fixed message polling period to periodically receive hardware execution feedback messages uploaded by each subscribed node after execution is completed; The actual hardware adjustment results in the feedback message are analyzed, and the original state segment data of the corresponding hardware unit in the original rest scene state frame is replaced to generate the updated scene state frame. The updated scene state frame is re-input into the finite state machine, and the scene state transition determination process is repeated.

[0013] Furthermore, the method also includes: Upon receiving an external pause exit trigger signal, the finite state machine is invoked to switch to the pause exit state; Based on the exit status, a reset control message is generated for each subscription node and simultaneously sent to all subscription nodes. After each node completes a hardware reset, the data interaction link between the dedicated interactive bus for the rest period and each subscribed node is disconnected.

[0014] The second aspect of the present invention proposes: A control system for a vehicle in a rest mode, wherein the system includes: The registration module is used to establish a dedicated interactive bus channel for in-vehicle rest, registering each hardware control unit in the cabin that participates in rest control as a bus subscription node, and assigning a unique node identifier and message receiving port to each subscription node. The data acquisition module is used to collect vehicle parking status messages, occupant vital sign sampling messages, and original status messages of various hardware units in the cabin, and encapsulate them into a standard format rest scene status frame. The determination module is used to retrieve the finite state machine of the rest scenario pre-stored in the vehicle domain controller, input the rest scenario state frame into the internal logic unit of the finite state machine, and complete the current rest scenario state transition determination. The generation module is used to generate node-specific subscription-based collaborative control messages based on the target scenario state output by the finite state machine and the node identifiers of each subscribed node. The execution module is used to distribute collaborative control messages to the subscription nodes identified by the corresponding node via the dedicated interactive bus of the rest area. Each subscription node parses the message and then performs the corresponding hardware adjustment operation. The update module is used to receive hardware execution feedback messages from each subscription node in real time, repackage the feedback messages to update the rest scene state frame and feed them back to the finite state machine to realize the cyclic iterative determination of the scene state.

[0015] Furthermore, the steps of establishing a dedicated interactive bus channel for in-vehicle naps, registering each hardware control unit involved in nap control within the cabin as a bus subscription node, and assigning a unique node identifier and message receiving port to each subscription node include: The vehicle bus network is divided into sections, and an independent transmission bandwidth is isolated as a dedicated interactive bus channel for rest. The bus message transmission priority is configured to be higher than that of regular cockpit control messages. It traverses the cockpit seat controller, air conditioning controller, window controller, interior lighting controller, and audio-visual controller to complete the identification of hardware units; Each identified hardware unit is assigned a unique binary node identifier. Simultaneously, each node identifier is bound to an independent message receiving port within the bus channel. A node port mapping table is generated and stored locally.

[0016] Furthermore, the step of collecting vehicle parking status messages, occupant vital sign sampling messages, and original status messages of various hardware units in the cabin, and uniformly encapsulating them into a standard format nap scene status frame includes: Read raw data on parking gear position, electronic handbrake lock, and vehicle power level from the vehicle's VCU and generate a parking condition message. The vehicle collects data on human respiration, heart rate, and lying posture using in-vehicle vital signs sensors, and generates occupant vital signs sampling reports. Read the current gear, power, opening degree, and opening / closing status data of each subscription node respectively, and generate the original status message of the hardware unit; Set a unified frame header, frame check bit, and data segmentation field, and concatenate the three types of messages in a fixed data segmentation order to encapsulate and generate a single-frame rest scene status frame.

[0017] Furthermore, the step of retrieving the finite state machine for the rest scenario pre-stored in the vehicle domain controller, inputting the rest scenario state frame into the internal logic unit of the finite state machine, and completing the current rest scenario state transition determination includes: The finite state machine internally divides into four basic scenario states: standby state, nap start state, nap maintain state, and nap exit state, and stores the threshold conditions for transitions between each state. Analyze the segmented data within the state frame of the rest scene and extract the parking condition threshold, occupant vital signs threshold, and hardware status threshold. The extracted thresholds are compared one by one with the pre-stored jump trigger condition thresholds of the finite state machine, and the target scene state after matching is output.

[0018] Furthermore, the step of generating a node-specific subscription-based collaborative control message by matching the node identifier of each subscribing node with the target scenario state output by the finite state machine includes: A pre-stored scene state-node control parameter mapping table is used, which records the adjustment parameter range corresponding to each node identifier under each type of target scene state. Based on the target scene state, retrieve the adjustment parameter range of all nodes in the mapping table, and combine it with the original hardware state within the current rest scene state frame to correct the adjustment parameters of each node. Using the corresponding node identifier as the message target address, and carrying the corrected adjustment parameters and message check code, a unique collaborative control message is independently generated for each subscribing node.

[0019] Furthermore, the steps of receiving hardware execution feedback messages from each subscribed node in real time, re-encapsulating and updating the rest scene state frame and feeding it back into the finite state machine to realize the iterative determination of the scene state include: Set a fixed message polling period to periodically receive hardware execution feedback messages uploaded by each subscribed node after execution is completed; The actual hardware adjustment results in the feedback message are analyzed, and the original state segment data of the corresponding hardware unit in the original rest scene state frame is replaced to generate the updated scene state frame. The updated scene state frame is re-input into the finite state machine, and the scene state transition determination process is repeated.

[0020] Furthermore, the method also includes: Upon receiving an external pause exit trigger signal, the finite state machine is invoked to switch to the pause exit state; Based on the exit status, a reset control message is generated for each subscription node and simultaneously sent to all subscription nodes. After each node completes a hardware reset, the data interaction link between the dedicated interactive bus for the rest period and each subscribed node is disconnected.

[0021] The third aspect of the present invention proposes: An in-vehicle controller includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the control method for a vehicle nap mode as described above.

[0022] The fourth aspect of the present invention proposes: A computer-readable storage medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the control method for a vehicle rest mode as described above.

[0023] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0024] Figure 1 A flowchart of the control method for a vehicle in rest mode provided in the first embodiment of the present invention; Figure 2 This is a structural block diagram of the control system for a vehicle in a rest mode provided in the third embodiment of the present invention.

[0025] The following detailed description, in conjunction with the accompanying drawings, will further illustrate the present invention. Detailed Implementation

[0026] To facilitate understanding of the present invention, a more complete description will be given below with reference to the accompanying drawings. Several embodiments of the invention are illustrated in the drawings. However, the invention can be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete.

[0027] It should be noted that when a component is said to be "fixed to" another component, it can be directly on the other component or there may be an intervening component. When a component is said to be "connected to" another component, it can be directly connected to the other component or there may be an intervening component. The terms "vertical," "horizontal," "left," "right," and similar expressions used in this document are for illustrative purposes only.

[0028] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0029] Please see Figure 1 The diagram shows a control method for vehicle nap mode provided in the first embodiment of the present invention. The control method for vehicle nap mode provided in this embodiment can dynamically adjust the control strategy according to real-time operating conditions, occupant vital signs and hardware status, continuously adapt to the dynamic needs of the nap scenario, significantly improve the user experience of the in-vehicle nap scenario, and the standardized bus architecture also improves the scalability and functional iteration efficiency of the system.

[0030] Specifically, this embodiment provides: A control method for a vehicle in a rest mode, wherein the method includes: Step S10: Establish a dedicated interactive bus channel for in-vehicle rest, register each hardware control unit in the cabin that participates in rest control as a bus subscription node, and assign a unique node identifier and message receiving port to each subscription node. It should be noted that an independent dedicated interactive bus channel for the rest stop is constructed based on the cockpit domain bus. All hardware control units involved in rest stop control within the cockpit are registered as subscription nodes on the bus, and each subscription node is assigned a globally unique node identifier and a dedicated message receiving port. This step separates rest stop control services from regular cockpit control services through logical isolation, and uses a subscription-publish communication mode to achieve targeted distribution of control messages, avoiding interference from broadcast messages to unrelated hardware, while providing a unified communication benchmark for the timing-coordinated control of multiple nodes.

[0031] Step S20: Collect vehicle parking status messages, occupant vital signs sampling messages, and original status messages of various hardware units in the cabin, and encapsulate them into a standard format rest scene status frame. It should be noted that three types of heterogeneous data sources are collected simultaneously: parking status messages output by the vehicle's VCU, occupant vital sign sampling messages output by the in-vehicle sensor system, and raw hardware unit status messages fed back by each subscribed node. These three types of data are encapsulated into a standard-format rest scenario status frame according to a unified protocol. The uniformly encapsulated status frame serves as the sole input carrier for the finite state machine, integrating the status, human body, and hardware data scattered across different buses and nodes into structured single-frame data. This simplifies the parsing process of subsequent logic units and reduces the computational overhead of the domain controller.

[0032] Step S30: Retrieve the finite state machine of the rest scene pre-stored in the vehicle domain controller, input the rest scene state frame into the internal logic unit of the finite state machine, and complete the current rest scene state transition determination. It should be noted that the finite state machine program for the rest scenario, pre-stored in the flash memory of the vehicle domain controller, is retrieved. The encapsulated rest scenario state frame is input into the internal logic operation unit of the finite state machine, and the state transition determination of the current rest scenario is completed through condition matching and rule judgment. The finite state machine carries all the business rules of the rest scenario in the form of discrete states, transforming the complex multi-condition combination judgment into a standardized state transition process, ensuring the determinism and traceability of state switching.

[0033] Step S40: Based on the target scenario state output by the finite state machine, match the node identifier of each subscribed node to generate a node-specific subscription-based collaborative control message; It should be noted that, based on the target scenario state output by the finite state machine, the node identifiers of each subscribing node are matched to generate a unique subscription-based collaborative control message for each node. Each message uses a node-oriented addressing method and contains only the adjustment parameters, instruction sequence number, and verification information of the corresponding node, achieving fine-grained control of "one instruction per node" and reducing the proportion of invalid data transmitted on the bus.

[0034] Step S50: Distribute collaborative control messages to the corresponding subscription nodes via the dedicated interactive bus of the rest area. Each subscription node parses the message and then performs the corresponding hardware adjustment operation. It's important to note that, through the dedicated interactive bus, collaborative control messages are distributed to the corresponding subscribed nodes according to the mapping table of node ports. Each subscribed node listens for messages on its own port using a hardware message filtering mechanism. Upon receiving a valid message, it parses the internal adjustment parameters and executes the corresponding hardware adjustment operations, including seat posture adjustment, air conditioning temperature and airflow adjustment, interior lighting brightness adjustment, window opening adjustment, and audio-visual system content and volume adjustment. This targeted distribution mechanism ensures that commands are accurately delivered to the target hardware, avoiding malfunctions caused by bus crosstalk.

[0035] Step S60: Receive hardware execution feedback messages from each subscribed node in real time, repackage the feedback messages to update the rest scene state frame and feed them back to the finite state machine to realize the iterative determination of the scene state.

[0036] It should be noted that the system receives hardware execution feedback messages from each subscribed node in real time, parses and repackages the feedback data, updates the original rest scene state frame, and feeds the updated state frame back to the input of the finite state machine to perform state transition determination again, thus realizing the cyclical iterative determination of the scene state. Through the closed-loop feedback mechanism, the hardware execution progress can be tracked in real time, state deviations can be corrected, and the continuity and consistency of the scene control process can be ensured.

[0037] Second Embodiment Furthermore, the steps of establishing a dedicated interactive bus channel for in-vehicle naps, registering each hardware control unit involved in nap control within the cabin as a bus subscription node, and assigning a unique node identifier and message receiving port to each subscription node include: The vehicle bus network is divided into sections, and an independent transmission bandwidth is isolated as a dedicated interactive bus channel for rest. The bus message transmission priority is configured to be higher than that of regular cockpit control messages. It traverses the cockpit seat controller, air conditioning controller, window controller, interior lighting controller, and audio-visual controller to complete the identification of hardware units; Each identified hardware unit is assigned a unique binary node identifier. Simultaneously, each node identifier is bound to an independent message receiving port within the bus channel. A node port mapping table is generated and stored locally.

[0038] It should be noted that the CANFD bus network in the vehicle's cockpit domain is logically divided. A dedicated message ID segment is configured through the gateway as a dedicated interactive bus channel for the mini-refresher. This ID segment does not overlap with the ID range of regular cockpit control messages, achieving logical isolation of transmission bandwidth. Simultaneously, messages within this ID segment are configured to have a higher transmission priority than regular cockpit entertainment control messages. In the CANFD arbitration domain, a smaller ID value achieves a higher arbitration priority, ensuring that even under high bus load, mini-refresher control commands can still be transmitted within a preset time delay, avoiding control command delays caused by bus congestion.

[0039] The system sends a device enumeration command to the cockpit bus, traversing five core hardware units: seat controller, air conditioning controller, window controller, interior lighting controller, and audio / video controller. Each controller, upon receiving the enumeration command, returns a device descriptor containing information such as the manufacturer ID, function code, and firmware version number. The domain controller then parses the descriptor to identify the hardware unit's identity and function. The traversal process automatically skips unresponsive, communication-abnormal, or non-controllable hardware units, only including those that can communicate normally and support parameter adjustment in the subsequent registration scope, ensuring the availability of all subscribed nodes.

[0040] Each identified hardware unit is assigned a unique 8-bit binary node identifier. These identifiers are segmented by hardware type to ensure global uniqueness. Simultaneously, each node identifier is bound to an independent message receiving port within the bus channel. The port corresponds to a fixed offset from the message ID, establishing a one-to-one mapping between nodes and ports. A node port mapping table is generated and stored in the cockpit domain controller's non-volatile memory. This table is automatically loaded into memory during system power-on initialization for subsequent message distribution. This unique identifier and dedicated port design enables precise addressing of subscribed nodes, providing the address basis for targeted message distribution.

[0041] Furthermore, the step of collecting vehicle parking status messages, occupant vital sign sampling messages, and original status messages of various hardware units in the cabin, and uniformly encapsulating them into a standard format nap scene status frame includes: Read raw data on parking gear position, electronic handbrake lock, and vehicle power level from the vehicle's VCU and generate a parking condition message. The vehicle collects data on human respiration, heart rate, and lying posture using in-vehicle vital signs sensors, and generates occupant vital signs sampling reports. Read the current gear, power, opening degree, and opening / closing status data of each subscription node respectively, and generate the original status message of the hardware unit; Set a unified frame header, frame check bit, and data segmentation field, and concatenate the three types of messages in a fixed data segmentation order to encapsulate and generate a single-frame rest scene status frame.

[0042] It should be noted that three types of raw data are parsed from the VCU status messages of the vehicle's CAN network: parking gear signal, electronic parking brake lock status, and vehicle power level. The gear signal determines whether the vehicle is in P gear, the electronic parking brake signal determines whether it is locked, and the power level determines whether the vehicle is in ACC or OK gear. These three types of signals are packaged according to a preset message format to generate a parking condition message. The parking condition is a prerequisite safety condition for activating the rest mode; this type of data is used to determine whether the vehicle is in a stationary and safe state, serving as a pre-verification basis for mode triggering.

[0043] Multiple sensor systems deployed within the vehicle collect occupant status data: a cockpit millimeter-wave radar collects respiratory rate and heart rate values; seat pressure sensors collect body pressure distribution data and calculate lying posture angles; and in-vehicle occupant monitoring cameras assist in identifying occupant position and status. After fusion and verification, the multi-sensor data is integrated into an occupant vital signs sampling report. This vital signs data is used to determine the occupant's presence and physical condition, and is one of the core parameters for state machine switching, startup, maintenance, and wake-up.

[0044] Status query commands are sent sequentially to all registered subscription nodes to read the current operating parameters of each node: the seat controller returns the backrest angle, leg rest extension, and massage level; the air conditioning controller returns the target temperature, fan speed, and internal / external circulation mode; the window controller returns the opening degree of all four windows and the sunroof opening; the lighting controller returns the dome light brightness and ambient light color; and the audio / video controller returns the volume, playback status, and audio source type. After summarizing the status data of all nodes, a raw status message for the hardware unit is generated. This type of data reflects the initial state of each hardware component before triggering the nap and serves as the baseline data for calculating adjustments and achieving a smooth state transition.

[0045] A fixed-length standard frame format is defined, consisting of a 2-byte frame header field, a 1-byte data segment identifier field, a data payload field, and a 2-byte CRC16 checksum. The data payload field is divided into three segments in a fixed order: a 4-byte parking condition segment, an 8-byte occupant vital signs segment, and a 32-byte hardware status segment. Each segment contains the corresponding data content and a length identifier. The three types of messages are sequentially filled into their respective segments, the CRC checksum of the entire frame is calculated and filled into the checksum, and finally a complete single-frame rest scene state frame is generated. The unified frame format enables the structured integration of multi-source heterogeneous data. The finite state machine only needs to parse according to a fixed protocol to obtain all input parameters, reducing parsing complexity.

[0046] Furthermore, the step of retrieving the finite state machine for the rest scenario pre-stored in the vehicle domain controller, inputting the rest scenario state frame into the internal logic unit of the finite state machine, and completing the current rest scenario state transition determination includes: The finite state machine internally divides into four basic scenario states: standby state, nap start state, nap maintain state, and nap exit state, and stores the threshold conditions for transitions between each state. Analyze the segmented data within the state frame of the rest scene and extract the parking condition threshold, occupant vital signs threshold, and hardware status threshold. The extracted thresholds are compared one by one with the pre-stored jump trigger condition thresholds of the finite state machine, and the target scene state after matching is output.

[0047] It should be noted that the finite state machine pre-divides into four basic scenario states: standby state, nap start state, nap maintenance state, and nap exit state. The standby state corresponds to the regular cockpit state when the nap function is not activated; all hardware is controlled by regular cockpit logic, only listening for nap trigger conditions. The nap start state is a transitional state, executing a series of sequential adjustment actions such as reclining the seat, adjusting the air conditioning temperature, dimming the lights, and switching audio / video. The nap maintenance state is a steady state, where all hardware maintains the target parameter range, making only minor adjustments based on vital signs data, while continuously monitoring exit trigger conditions. The nap exit state is a transitional state, executing reset actions such as resetting the seat, restoring the air conditioning, gradually brightening the lights, and gradually increasing the volume. The machine also stores the threshold values ​​for transitions between each state, clearly defining the target state that each state can transition to and its corresponding judgment conditions, forming the logical rule base of the state machine.

[0048] The input rest scenario state frames are segmented and parsed according to data segmentation identifiers. The values ​​of gear position, handbrake, and power level are extracted for the parking condition segment; respiratory rate, heart rate, and lying angle are extracted for the occupant vital signs segment; and the operating values ​​of each node are extracted for the hardware status segment. These are then organized into three sets of threshold parameters that can be directly used for comparison. This step transforms the structured frame data into decision parameters that the state machine can directly compute, completing the preprocessing of the input data.

[0049] The extracted threshold parameters are compared one by one with the pre-stored jump trigger condition thresholds in the finite state machine. Following the priority rule of "exception exit first, state sequence jump," the target scenario state to be entered is determined. The comparison uses an item-by-item AND operation logic; a jump is triggered only when all trigger conditions for a state are met simultaneously. If any exception exit condition is met, the jump directly to the exit state. For example, if the parking condition is not met, the system directly determines to remain in standby mode; when parking, occupant presence, and user trigger command are all met simultaneously, the system determines to jump from standby mode to the nap start state. The matching determination based on preset rules is deterministic; the same input corresponds to a unique state output, effectively avoiding logical conflicts and state disorder.

[0050] Furthermore, the step of generating a node-specific subscription-based collaborative control message by matching the node identifier of each subscribing node with the target scenario state output by the finite state machine includes: A pre-stored scene state-node control parameter mapping table is used, which records the adjustment parameter range corresponding to each node identifier under each type of target scene state. Based on the target scene state, retrieve the adjustment parameter range of all nodes in the mapping table, and combine it with the original hardware state within the current rest scene state frame to correct the adjustment parameters of each node. Using the corresponding node identifier as the message target address, and carrying the corrected adjustment parameters and message check code, a unique collaborative control message is independently generated for each subscribing node.

[0051] It should be noted that the vehicle domain controller pre-stores a scenario state-node control parameter mapping table locally. This mapping table uses a two-dimensional array structure, with row indices corresponding to the enumerated values ​​of the four scenario states and column indices corresponding to the ID numbers of each node. Each storage unit contains three fields: minimum parameter value, maximum parameter value, and adjustment step size. The parameter range is pre-set based on ergonomic calibration data and the functional requirements of the rest scenario, covering various control parameters such as seat angle, air conditioning temperature and humidity, lighting brightness, and audio / video volume, serving as the basis for generating control commands.

[0052] Based on the target scenario state output by the finite state machine, the adjustment parameter ranges corresponding to all nodes are retrieved from the mapping table. Combined with the original hardware state data within the current rest scenario state frame, the difference between the current state and the median of the target range is calculated. Following the preset adjustment rate curve, the adjustment increment within a single cycle is calculated, generating the target adjustment parameter value for the current cycle. For moving components such as seats and windows, a gradual start-stop rate limit is added to the parameter correction process. The step size is reduced at the beginning and end of the adjustment to avoid mechanical shock and operating noise, ensuring the smoothness of the adjustment process.

[0053] For each subscribed node, its unique node identifier is used as the target address field of the message, filled with the modified adjustment parameters, and supplementary fields such as instruction sequence number, data length, and CRC checksum are added to generate a unique collaborative control message for that node. Each node's message is independent, containing only the instructions it needs to execute, without carrying control information from other nodes, effectively reducing the length of a single message frame and lowering the bus transmission load. The messages use a point-to-point addressing method; only the target node's hardware filter will receive messages with the corresponding ID, while other nodes automatically filter out irrelevant messages.

[0054] Furthermore, the steps of receiving hardware execution feedback messages from each subscribed node in real time, re-encapsulating and updating the rest scene state frame and feeding it back into the finite state machine to realize the iterative determination of the scene state include: Set a fixed message polling period to periodically receive hardware execution feedback messages uploaded by each subscribed node after execution is completed; The actual hardware adjustment results in the feedback message are analyzed, and the original state segment data of the corresponding hardware unit in the original rest scene state frame is replaced to generate the updated scene state frame. The updated scene state frame is re-input into the finite state machine, and the scene state transition determination process is repeated.

[0055] It's worth noting that a fixed 100ms polling period is set, employing a combination of proactive querying and proactive reporting to collect feedback: during transitional states, the domain controller proactively sends query commands to each node to obtain real-time execution status; during steady-state maintenance, each node proactively uploads status feedback, reducing the domain controller's scheduling overhead. The feedback messages include information such as the hardware's current operating parameters, execution progress, and fault status codes. Fixed-period polling allows for control over bus interaction frequency while ensuring real-time feedback, avoiding excessive bus resource consumption due to frequent communication.

[0056] The hardware execution feedback messages returned by each node are parsed to extract the actual hardware adjustment results. An incremental update method is used to replace the original state segment data of the corresponding hardware unit in the rest scenario state frame, while unchanged segments retain their original values ​​to reduce memory copy overhead. Simultaneously, the latest sampled data of parking conditions and occupant vital signs are updated synchronously, the entire frame checksum is recalculated, and an updated rest scenario state frame is generated. This step synchronizes the actual hardware execution results to the input state, ensuring that the state machine input always reflects the latest system state.

[0057] The updated rest scenario state frame is re-input into the logic unit of the finite state machine, and the scenario state transition determination process is repeated. If the hardware is still in the adjustment process, the current transition state is maintained, and adjustment commands continue to be issued; if the hardware has been adjusted to the target parameter range, it transitions to the steady-state maintenance state; if an abnormal operating condition or abnormal vital signs are detected, a state transition to the protection or exit state is triggered. When the state remains unchanged for three consecutive cycles, the polling cycle is automatically reduced to 500ms, entering low-overhead steady-state monitoring; when a state transition occurs, the polling frequency is restored to 100ms. Through iterative looping, a complete control closed loop is formed, which can track the execution progress and correct state deviations in real time.

[0058] Furthermore, the method also includes: Upon receiving an external pause exit trigger signal, the finite state machine is invoked to switch to the pause exit state; Based on the exit status, a reset control message is generated for each subscription node and simultaneously sent to all subscription nodes. After each node completes a hardware reset, the data interaction link between the dedicated interactive bus for the rest period and each subscribed node is disconnected.

[0059] The system receives various external input trigger signals for the nap exit, categorized into three types: user-initiated triggers (including physical nap buttons, voice wake-up exit commands, and steering wheel multifunction button operations); operational condition triggers (including disengaging from P gear, releasing the electronic parking brake, and pressing the accelerator pedal); and safety triggers (including vehicle collision warnings, emergency braking, external occupant warnings, and occupant vital signs abnormality warnings). Upon receiving any valid exit trigger signal, the system immediately invokes a finite state machine to forcibly switch to the nap exit state. This state has the highest jump priority and can interrupt all other operating states, ensuring timely exit response.

[0060] Based on the exit state of the rest mode, the initial state parameters of each hardware device recorded just moments before entering rest mode are retrieved as the reset baseline, rather than the default factory values, to generate reset control messages for all subscribed nodes. These reset messages are then synchronously distributed to all subscribed nodes via the rest mode's dedicated interactive bus using a broadcast and node verification method. This controls the smooth reset of hardware such as seats, air conditioning, lighting, windows, and audio-visual equipment to their pre-entry state at a preset rate. The synchronous distribution mechanism ensures consistent timing of reset actions across all hardware devices, and the reset process employs gradual adjustment to avoid abrupt changes in parameters.

[0061] After receiving reset completion feedback messages from all subscribed nodes and confirming that all hardware has completed the reset, an orderly link disconnection process is executed: First, the transmission of short-term control messages is stopped, and the bus transmission buffer is cleared; then, the subscription registration of each node is cancelled, and the message filtering channel of the corresponding hardware is closed; finally, the previously isolated bus bandwidth quota is released, the gateway restores the scheduling priority of regular cockpit messages, and the cockpit bus returns to normal operating mode. Link disconnection and resource release can prevent dedicated channels from occupying bus resources for a long time, ensuring the normal operation of other cockpit functions.

[0062] Please see Figure 2 The third embodiment of the present invention provides: A control system for a vehicle in a rest mode, wherein the system includes: The registration module is used to establish a dedicated interactive bus channel for in-vehicle rest, registering each hardware control unit in the cabin that participates in rest control as a bus subscription node, and assigning a unique node identifier and message receiving port to each subscription node. The data acquisition module is used to collect vehicle parking status messages, occupant vital sign sampling messages, and original status messages of various hardware units in the cabin, and encapsulate them into a standard format rest scene status frame. The determination module is used to retrieve the finite state machine of the rest scenario pre-stored in the vehicle domain controller, input the rest scenario state frame into the internal logic unit of the finite state machine, and complete the current rest scenario state transition determination. The generation module is used to generate node-specific subscription-based collaborative control messages based on the target scenario state output by the finite state machine and the node identifiers of each subscribed node. The execution module is used to distribute collaborative control messages to the subscription nodes identified by the corresponding node via the dedicated interactive bus of the rest area. Each subscription node parses the message and then performs the corresponding hardware adjustment operation. The update module is used to receive hardware execution feedback messages from each subscription node in real time, repackage the feedback messages to update the rest scene state frame and feed them back to the finite state machine to realize the cyclic iterative determination of the scene state.

[0063] Furthermore, the steps of establishing a dedicated interactive bus channel for in-vehicle naps, registering each hardware control unit involved in nap control within the cabin as a bus subscription node, and assigning a unique node identifier and message receiving port to each subscription node include: The vehicle bus network is divided into sections, and an independent transmission bandwidth is isolated as a dedicated interactive bus channel for rest. The bus message transmission priority is configured to be higher than that of regular cockpit control messages. It traverses the cockpit seat controller, air conditioning controller, window controller, interior lighting controller, and audio-visual controller to complete the identification of hardware units; Each identified hardware unit is assigned a unique binary node identifier. Simultaneously, each node identifier is bound to an independent message receiving port within the bus channel. A node port mapping table is generated and stored locally.

[0064] Furthermore, the step of collecting vehicle parking status messages, occupant vital sign sampling messages, and original status messages of various hardware units in the cabin, and uniformly encapsulating them into a standard format nap scene status frame includes: Read raw data on parking gear position, electronic handbrake lock, and vehicle power level from the vehicle's VCU and generate a parking condition message. The vehicle collects data on human respiration, heart rate, and lying posture using in-vehicle vital signs sensors, and generates occupant vital signs sampling reports. Read the current gear, power, opening degree, and opening / closing status data of each subscription node respectively, and generate the original status message of the hardware unit; Set a unified frame header, frame check bit, and data segmentation field, and concatenate the three types of messages in a fixed data segmentation order to encapsulate and generate a single-frame rest scene status frame.

[0065] Furthermore, the step of retrieving the finite state machine for the rest scenario pre-stored in the vehicle domain controller, inputting the rest scenario state frame into the internal logic unit of the finite state machine, and completing the current rest scenario state transition determination includes: The finite state machine internally divides into four basic scenario states: standby state, nap start state, nap maintain state, and nap exit state, and stores the threshold conditions for transitions between each state. Analyze the segmented data within the state frame of the rest scene and extract the parking condition threshold, occupant vital signs threshold, and hardware status threshold. The extracted thresholds are compared one by one with the pre-stored jump trigger condition thresholds of the finite state machine, and the target scene state after matching is output.

[0066] Furthermore, the step of generating a node-specific subscription-based collaborative control message by matching the node identifier of each subscribing node with the target scenario state output by the finite state machine includes: A pre-stored scene state-node control parameter mapping table is used, which records the adjustment parameter range corresponding to each node identifier under each type of target scene state. Based on the target scene state, retrieve the adjustment parameter range of all nodes in the mapping table, and combine it with the original hardware state within the current rest scene state frame to correct the adjustment parameters of each node. Using the corresponding node identifier as the message target address, and carrying the corrected adjustment parameters and message check code, a unique collaborative control message is independently generated for each subscribing node.

[0067] Furthermore, the steps of receiving hardware execution feedback messages from each subscribed node in real time, re-encapsulating and updating the rest scene state frame and feeding it back into the finite state machine to realize the iterative determination of the scene state include: Set a fixed message polling period to periodically receive hardware execution feedback messages uploaded by each subscribed node after execution is completed; The actual hardware adjustment results in the feedback message are analyzed, and the original state segment data of the corresponding hardware unit in the original rest scene state frame is replaced to generate the updated scene state frame. The updated scene state frame is re-input into the finite state machine, and the scene state transition determination process is repeated.

[0068] Furthermore, the method also includes: Upon receiving an external pause exit trigger signal, the finite state machine is invoked to switch to the pause exit state; Based on the exit status, a reset control message is generated for each subscription node and simultaneously sent to all subscription nodes. After each node completes a hardware reset, the data interaction link between the dedicated interactive bus for the rest period and each subscribed node is disconnected.

[0069] The fourth embodiment of the present invention provides an in-vehicle controller, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the control method for the vehicle nap mode as described above.

[0070] The fifth embodiment of the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the control method for the vehicle rest mode as described above.

[0071] In summary, the control method and system for vehicle nap mode provided in the above embodiments of the present invention can dynamically adjust the control strategy according to real-time operating conditions, occupant vital signs and hardware status, continuously adapt to the dynamic needs of the nap scenario, significantly improve the user experience of the vehicle nap scenario, and the standardized bus architecture also improves the scalability and functional iteration efficiency of the system.

[0072] It should be noted that the above modules can be functional modules or program modules, and can be implemented through software or hardware. For modules implemented through hardware, the above modules can reside in the same processor; or the above modules can be located in different processors in any combination.

[0073] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-including system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device.

[0074] More specific examples of computer-readable media (a non-exhaustive list) include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which the program can be printed, because the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0075] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0076] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0077] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the appended claims.

Claims

1. A control method for a vehicle in a rest mode, characterized in that, The method includes: Establish a dedicated interactive bus channel for in-vehicle naps, register each hardware control unit in the cabin that participates in nap control as a bus subscription node, and assign a unique node identifier and message receiving port to each subscription node; Collect vehicle parking status messages, occupant vital signs sampling messages, and original status messages of various hardware units in the cabin, and encapsulate them into a standard format rest scene status frame. Retrieve the finite state machine of the rest scenario pre-stored in the vehicle domain controller, input the rest scenario state frame into the internal logic unit of the finite state machine, and complete the current rest scenario state transition determination. Based on the target scenario state output by the finite state machine, the node identifiers of each subscribed node are matched to generate a node-specific subscription-based collaborative control message; The collaborative control message is distributed to the subscription node with the corresponding node identifier through the dedicated interactive bus of the rest. After parsing the message, each subscription node performs the corresponding hardware adjustment operation. The system receives hardware execution feedback messages from each subscription node in real time, repackages and updates the rest scene state frame, and feeds it back into the finite state machine to achieve iterative determination of the scene state.

2. The control method for vehicle rest mode according to claim 1, characterized in that, The steps of establishing a dedicated interactive bus channel for in-vehicle naps, registering each hardware control unit involved in nap control within the cabin as a bus subscription node, and assigning a unique node identifier and message receiving port to each subscription node include: The vehicle bus network is divided into sections, and an independent transmission bandwidth is isolated as a dedicated interactive bus channel for rest. The bus message transmission priority is configured to be higher than that of regular cockpit control messages. It traverses the cockpit seat controller, air conditioning controller, window controller, interior lighting controller, and audio-visual controller to complete the identification of hardware units; Each identified hardware unit is assigned a unique binary node identifier, and each node identifier is simultaneously bound to an independent message receiving port within the bus channel. A node port mapping table is generated and stored locally.

3. The control method for vehicle rest mode according to claim 1, characterized in that, The steps of collecting vehicle parking status messages, occupant vital sign sampling messages, and original status messages of various hardware units in the cockpit, and uniformly encapsulating them into a standard format rest scene status frame include: Read raw data on parking gear position, electronic handbrake lock, and vehicle power level from the vehicle's VCU and generate a parking condition message. The vehicle collects data on human respiration, heart rate, and lying posture using in-vehicle vital signs sensors, and generates occupant vital signs sampling reports. Read the current gear, power, opening degree, and opening / closing status data of each subscription node respectively, and generate the original status message of the hardware unit; Set a unified frame header, frame check bit, and data segmentation field, and concatenate the three types of messages in a fixed data segmentation order to encapsulate and generate a single-frame rest scene status frame.

4. The control method for vehicle rest mode according to claim 1, characterized in that, The steps of retrieving the finite state machine for the rest scenario pre-stored in the vehicle domain controller, inputting the rest scenario state frame into the internal logic unit of the finite state machine, and completing the current rest scenario state transition determination include: The finite state machine internally divides into four basic scenario states: standby state, nap start state, nap maintain state, and nap exit state, and stores the threshold conditions for transitions between each state. Analyze the segmented data within the state frame of the rest scene and extract the parking condition threshold, occupant vital signs threshold, and hardware status threshold. The extracted thresholds are compared one by one with the pre-stored jump trigger condition thresholds of the finite state machine, and the target scene state after matching is output.

5. The control method for vehicle rest mode according to claim 1, characterized in that, The step of generating a node-specific subscription-based collaborative control message by matching the node identifier of each subscribing node with the target scenario state output by the finite state machine includes: A pre-stored scene state-node control parameter mapping table is used, which records the adjustment parameter range corresponding to each node identifier under each type of target scene state. Based on the target scene state, retrieve the adjustment parameter range of all nodes in the mapping table, and combine it with the original hardware state within the current rest scene state frame to correct the adjustment parameters of each node. Using the corresponding node identifier as the message target address, and carrying the corrected adjustment parameters and message check code, a unique collaborative control message is independently generated for each subscribing node.

6. The control method for vehicle rest mode according to claim 1, characterized in that, The steps of receiving hardware execution feedback messages from each subscribed node in real time, re-encapsulating and updating the rest scene state frame and feeding it back into the finite state machine to realize the iterative determination of the scene state include: Set a fixed message polling period to periodically receive hardware execution feedback messages uploaded by each subscribed node after execution is completed; The actual hardware adjustment results in the feedback message are analyzed, and the original state segment data of the corresponding hardware unit in the original rest scene state frame is replaced to generate the updated scene state frame. The updated scene state frame is re-input into the finite state machine, and the scene state transition determination process is repeated.

7. The control method for vehicle rest mode according to claim 1, characterized in that, The method further includes: Upon receiving an external pause exit trigger signal, the finite state machine is invoked to switch to the pause exit state; Based on the exit status, a reset control message is generated for each subscription node and simultaneously sent to all subscription nodes. After each node completes a hardware reset, the data interaction link between the dedicated interactive bus for the rest period and each subscribed node is disconnected.

8. A control system for a vehicle in a rest mode, characterized in that, The system includes: The registration module is used to establish a dedicated interactive bus channel for in-vehicle rest, registering each hardware control unit in the cabin that participates in rest control as a bus subscription node, and assigning a unique node identifier and message receiving port to each subscription node. The data acquisition module is used to collect vehicle parking status messages, occupant vital sign sampling messages, and original status messages of various hardware units in the cabin, and encapsulate them into a standard format rest scene status frame. The determination module is used to retrieve the finite state machine of the rest scenario pre-stored in the vehicle domain controller, input the rest scenario state frame into the internal logic unit of the finite state machine, and complete the current rest scenario state transition determination. The generation module is used to generate node-specific subscription-based collaborative control messages based on the target scenario state output by the finite state machine and the node identifiers of each subscribed node. The execution module is used to distribute collaborative control messages to the subscription nodes identified by the corresponding node via the dedicated interactive bus of the rest area. Each subscription node parses the message and then performs the corresponding hardware adjustment operation. The update module is used to receive hardware execution feedback messages from each subscription node in real time, repackage the feedback messages to update the rest scene state frame and feed them back to the finite state machine to realize the cyclic iterative determination of the scene state.

9. An on-board controller, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the control method for the vehicle rest mode as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the control method for the vehicle rest mode as described in any one of claims 1 to 7.

Images