Vehicle-mounted network sleep management method and system
By introducing a three-layer timer mechanism in the vehicle network, the synchronous sleep of the main controller, sub-controllers and nodes is ensured, which solves the problem of node delayed sleep and increased static power consumption of the whole vehicle caused by the Sleep.Ind/Sleep.Ack message interaction delay, and achieves efficient sleep state switching.
Patent Information
- Application Number
- CN202511975533.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-25
- Publication Date
- 2026-03-17
AI Technical Summary
In the vehicle network, the delay in the interaction between Sleep.Ind and Sleep.Ack messages causes some nodes to enter a sleep state late, increasing the static power consumption of the entire vehicle.
A three-layer timer mechanism is adopted between the main controller, sub-controllers and nodes. Through hierarchical instruction issuance and signal reporting, it is ensured that all nodes synchronously enter sleep mode after the timer expires.
It achieves highly synchronized sleep of nodes in the vehicle network, avoiding the problems of delayed sleep and increased static power consumption of the whole vehicle.
Smart Images

Figure CN121690898A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of automotive technology, and more specifically, to an in-vehicle network sleep management method and system. Background Technology
[0002] With the rapid evolution of automotive electronics and intelligent technologies, the number of onboard electronic control units (ECUs) is increasing exponentially, significantly enhancing the topological complexity and data exchange volume of the vehicle's CAN bus network. Under these circumstances, how to coordinate and control all onboard ECUs in a unified manner when the vehicle needs to enter sleep mode is a pressing technical problem that needs to be solved.
[0003] In related solutions, multi-node synchronous sleep is generally achieved through the interaction of Sleep.Ind and Sleep.Ack messages. However, due to the interaction delay of Sleep.Ind / Sleep.Ack messages, some nodes may enter the sleep state with a delay, increasing the static power consumption of the entire vehicle. Summary of the Invention
[0004] The present invention aims to, for example, provide a method and system for managing sleep in a vehicle network, which can at least partially solve the above-mentioned technical problems.
[0005] The embodiments of the present invention can be implemented as follows: In a first aspect, embodiments of the present invention provide an in-vehicle network sleep management method, applied to an in-vehicle network sleep management system. The in-vehicle network sleep management system includes a main controller, multiple sub-controllers, and multiple nodes. The main controller is communicatively connected to each of the sub-controllers, each sub-controller is communicatively connected to multiple nodes, and each node corresponds to only one sub-controller. The method includes: The main controller sends a first sleep command to each of the sub-controllers and starts a first timer; upon receiving a second sleep ready signal from all the sub-controllers and after the first timer has expired, the main controller controls the entire vehicle network to enter a sleep state. Each of the sub-controllers receives the first sleep instruction, generates a second sleep instruction and sends it to the corresponding nodes, and starts a second timer; each of the sub-controllers, upon receiving the first sleep ready signal from all the corresponding nodes and after the second timer expires, sends the second sleep ready signal back to the main controller. Each node receives the second sleep command and starts the third timer; after the third timer expires, each node enters a pre-sleep state and sends a first sleep ready signal back to the sub-controller.
[0006] Optionally, before the main controller sends the first sleep command to each of the sub-controllers, the method further includes: The main controller monitors engine status signals and CAN bus data status signals in real time. If the engine status signal is an engine power-off signal and the CAN bus data status signal is a bus no data signal, then the main controller generates the first sleep command.
[0007] Optionally, the method further includes: After the first timer starts, the main controller acquires the subnet wake-up request messages and engine power-on signals sent by each of the sub-controllers in real time until the first timer ends. If the main controller receives the subnet wake-up request message or the engine power-on signal before the first timer expires, the main controller resets the first timer and sends a mainnet sleep interruption command to each of the subcontrollers.
[0008] Optionally, the method further includes: After the second timer is started, each of the sub-controllers acquires the node wake-up request messages sent by the corresponding nodes in real time until the second timer ends; If the sub-controller receives a node wake-up request message or a main network sleep interruption command before the second timer expires, the sub-controller resets the second timer and sends a sub-network sleep interruption command to each node.
[0009] Optionally, the method further includes: After the third timer is started, each node acquires its corresponding local wake-up signal in real time until the third timer ends. If a node receives the corresponding local wake-up signal or the subnet sleep interruption command before the third timer expires, the node resets the third timer.
[0010] Optionally, the method further includes: Each of the sub-controllers monitors the first handshake message of the corresponding node in real time; If the sub-controller does not receive the first handshake message from the same node for a preset number of consecutive preset times within a preset time period, the sub-controller determines that the node is a faulty node.
[0011] Optionally, after the sub-controller determines that the node is a faulty node, the method further includes: The sub-controller sends a fault notification to the faulty node and isolates the faulty node when sending the second sleep command; After receiving the fault notification, the faulty node sends a limp home message to the sub-controller to confirm the fault status.
[0012] Optionally, the main controller and each of the sub-controllers are connected via Ethernet communication, and each sub-controller is connected to its corresponding node via a CAN bus.
[0013] Optionally, the duration of the first timer is greater than the duration of the second timer, and the duration of the second timer is greater than the duration of the third timer.
[0014] Secondly, embodiments of the present invention provide an in-vehicle network sleep management system, which includes a main controller, multiple sub-controllers and multiple nodes. The main controller is communicatively connected to each of the sub-controllers, each sub-controller is communicatively connected to multiple nodes, and each node corresponds to only one sub-controller. The main controller is used to send a first sleep command to each of the sub-controllers and start a first timer; after receiving a second sleep ready signal from all the sub-controllers and after the first timer has expired, it controls the entire vehicle network to enter a sleep state. Each of the sub-controllers is configured to receive the first sleep instruction, generate a second sleep instruction and send it to the corresponding nodes, and start a second timer; each of the sub-controllers, upon receiving the first sleep ready signal from all the corresponding nodes and after the second timer has expired, sends the second sleep ready signal back to the main controller. Each node is configured to receive the second sleep command and start the third timer; after the third timer expires, each node enters a pre-sleep state and sends a first sleep ready signal back to the sub-controller.
[0015] The beneficial effects of the embodiments of the present invention include, for example: The system employs an in-vehicle network sleep management system comprising a main controller, multiple sub-controllers, and multiple nodes. When a vehicle needs to enter sleep mode, a three-tiered timer is set for the main controller, each sub-controller, and each node. The sub-controller is notified when the third timer on each node ends; the main controller is notified when the second timer on each sub-controller ends; and finally, the main controller synchronizes all nodes and sub-controllers into sleep mode after the first timer on the main controller ends. This achieves synchronized node sleep and eliminates delayed sleep. Attached Figure Description
[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0017] Figure 1 An architecture diagram of an in-vehicle network sleep management system provided in an embodiment of the present invention; Figure 2 A flowchart illustrating the steps of an in-vehicle network sleep management method provided in this embodiment of the invention; Figure 3 This is one of the wake-up steps of a vehicle network sleep management method provided in an embodiment of the present invention; Figure 4 The second flowchart of the wake-up steps of an in-vehicle network sleep management method provided in this embodiment of the invention; Figure 5 The third flowchart of the wake-up steps of a vehicle network sleep management method provided in this embodiment of the invention.
[0018] Icons: 01-Vehicle network sleep management system; 10-Main controller; 20-Sub-controller; 30-Node. Detailed Implementation
[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.
[0020] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.
[0021] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.
[0022] Furthermore, the terms "first" and "second" are used only to distinguish descriptions and should not be interpreted as indicating or implying relative importance.
[0023] It should be noted that, where there is no conflict, the features in the embodiments of the present invention can be combined with each other.
[0024] Please see Figure 1 This invention provides an in-vehicle network sleep management system 01, including a main controller 10, multiple sub-controllers 20 and multiple nodes 30. The main controller 10 is communicatively connected to each sub-controller 20, each sub-controller 20 is communicatively connected to multiple nodes 30, and each node 30 corresponds to only one sub-controller 20.
[0025] The main controller 10 is used to send a first sleep command to each sub-controller 20 and start a first timer; after receiving the second sleep ready signal from all sub-controllers 20 and after the first timer ends, it controls the entire vehicle network to enter a sleep state.
[0026] Each sub-controller 20 is used to receive a first sleep command, generate a second sleep command and send it to the corresponding nodes 30, and start a second timer; each sub-controller 20, after receiving the first sleep ready signal from all the corresponding nodes 30 and after the second timer has expired, sends the second sleep ready signal to the main controller 10.
[0027] Each node 30 is used to receive the second sleep command and start the third timer; after the third timer ends, each node 30 enters the pre-sleep state and sends the first sleep ready signal back to the sub-controller 20.
[0028] like Figure 1 As shown, the communication between the main controller 10, each sub-controller 20, and each node 30 forms a "tree" architecture. The main controller 10 communicates with multiple sub-controllers 20, and each sub-controller 20 communicates with multiple nodes 30. When the car needs to sleep, the main controller 10 first sends a first sleep command to each sub-controller 20 and starts a first timer. After receiving the first sleep command, each sub-controller 20 generates a second sleep command and sends it to the node 30 it communicates with, while starting a second timer. After receiving the second sleep command, each node 30 starts a third timer.
[0029] When the third timer finishes its countdown, each node 30 enters a pre-sleep state and sends a first sleep ready signal to the sub-controller 20 it is communicating with. After receiving the first sleep ready signals from all corresponding nodes 30, each sub-controller 20 waits for the second timer to finish its countdown and then sends a second sleep ready signal to the main controller 10. After receiving the second sleep ready signals from all sub-controllers 20, the main controller 10 waits for the first timer to finish its countdown and then uniformly controls all sub-controllers 20 and nodes 30 to synchronously begin sleep.
[0030] Corresponding to an in-vehicle network sleep management system, this invention provides an in-vehicle network sleep management method, applied to an in-vehicle network sleep management system. The in-vehicle network sleep management system includes a main controller, multiple sub-controllers, and multiple nodes. The main controller is communicatively connected to each of the sub-controllers, each sub-controller is communicatively connected to multiple nodes, and each node corresponds to only one sub-controller. The method includes, for example: Figure 2 The following steps are shown: Step S110: The main controller sends a first sleep command to each of the sub-controllers and starts a first timer; upon receiving a second sleep ready signal from all the sub-controllers and after the first timer has expired, the main controller controls the entire vehicle network to enter a sleep state.
[0031] Step S120: Each sub-controller receives the first sleep instruction, generates a second sleep instruction and sends it to the corresponding nodes, and starts the second timer; each sub-controller, upon receiving the first sleep ready signal from all corresponding nodes and after the second timer expires, sends the second sleep ready signal back to the main controller.
[0032] Step S130: Each node receives the second sleep command and starts the third timer; after the third timer expires, each node enters a pre-sleep state and sends a first sleep ready signal back to the sub-controller.
[0033] The main controller can be a VCU (Vehicle Control Unit), the sub-controllers can be DCUs (Domain Controller Units), and the nodes can be ECUs (Electronic Control Units). The main controller sends a first sleep command (e.g., command frame 0x5A0) to each sub-controller and simultaneously starts a first timer. Upon receiving the first sleep command, each sub-controller generates a second sleep command applicable to its managed nodes (e.g., command frame 0x5A1) and sends it to the corresponding nodes, while simultaneously starting a second timer. Upon receiving the second sleep command, each node starts a third timer and enters a pre-sleep state upon the expiration of the third timer, then sends a first sleep ready signal (e.g., command frame 0x5A2) to its subordinate sub-controller. Each sub-controller must wait for all its managed nodes to send a first sleep ready signal and for its own second timer to expire before sending a second sleep ready signal to the main controller. Finally, the main controller, after confirming that it has received the second sleep ready signals from all sub-controllers and that its own first timer has expired, controls the entire vehicle network to enter a unified sleep state.
[0034] By issuing instructions step by step, reporting ready signals step by step, and using a coordinated timeout mechanism with independent timers at each level, the system ensures that all units in the vehicle network can switch to a low-power state in a highly synchronized manner. This effectively solves the problems of node sleep asynchrony and increased vehicle static power consumption caused by simple message interaction delays.
[0035] Optionally, the main controller and each of the sub-controllers are connected via Ethernet communication, and each sub-controller is connected to its corresponding node via a CAN bus.
[0036] As an optional implementation, the main controller and each sub-controller can communicate via Ethernet, and each sub-controller can communicate with its corresponding node via a CAN bus. Ethernet provides high-bandwidth, low-latency backbone communication, suitable for the main network layer to quickly distribute global commands and summarize status. CAN bus, on the other hand, is a reliable network standard widely used in the automotive field, suitable for connecting a large number of nodes. The architecture combining the Ethernet backbone and CAN subnets realizes a hierarchical network of "main network layer - subnet layer - node layer," balancing management efficiency, real-time performance, and cost.
[0037] Optionally, the duration of the first timer is greater than the duration of the second timer, and the duration of the second timer is greater than the duration of the third timer.
[0038] In practical applications, the duration of the first timer can be longer than that of the second timer, and the duration of the second timer can be longer than that of the third timer. This decreasing duration setting ensures that the sleep preparation process is completed step by step from the node layer, followed by the sub-controllers, and finally converges at the main controller. This allows the sleep state switching of the entire system to converge in an orderly manner in time, achieving a high degree of synchronization. For example, the first timer is 2000 milliseconds, the second timer is 1500 milliseconds, and the third timer is 1000 milliseconds.
[0039] Optionally, before the main controller sends the first sleep command to each of the sub-controllers, the method further includes: The main controller monitors engine status signals and CAN bus data status signals in real time.
[0040] If the engine status signal is an engine power-off signal and the CAN bus data status signal is a bus no data signal, then the main controller generates the first sleep command.
[0041] The main controller triggers the first sleep command by monitoring the engine status signal and the CAN bus data status signal in real time. The first sleep command is only generated when the engine status signal is detected as an engine power-off signal (e.g., the vehicle ignition switch KL15 is off) and the CAN bus data status signal is simultaneously detected as a no-data signal (meaning no application message interaction on the bus). This ensures that the sleep process only starts when the vehicle is off and the bus is idle, preventing accidental triggering of sleep when the vehicle is still running or the bus is busy, thus improving system reliability and safety. It is understandable that if the vehicle is a new energy electric vehicle, the monitored "engine status signal" could be the main power supply power-on / off signal of the new energy electric vehicle to confirm whether the vehicle is running or not.
[0042] Optionally, the method further includes, for example, Figure 3 The following steps are shown: Step S210: After the first timer starts, the main controller acquires the subnet wake-up request messages and engine power-on signals sent by each of the sub-controllers in real time until the first timer ends.
[0043] Step S220: If the main controller receives the subnet wake-up request message or the engine power-on signal before the first timer expires, the main controller resets the first timer and sends a mainnet sleep interruption command to each of the subcontrollers.
[0044] During the entire period from the start of the first timer until its end, the main controller continuously acquires subnet wake-up request messages and engine power-on signals that may be sent by each subcontroller. If the main controller acquires any subnet wake-up request message or engine power-on signal before the first timer expires naturally, the main controller immediately resets the first timer, canceling the current sleep countdown, and sends a mainnet sleep interruption command to all subcontrollers. This allows the sleep preparation process to be interrupted by new wake-up requests, ensuring the system can respond promptly to events such as vehicle startup or emergency subnet wake-up, enhancing the overall vehicle network's responsiveness.
[0045] Optionally, the method further includes, for example, Figure 4 The following steps are shown: Step S310: After the second timer starts, each sub-controller acquires the node wake-up request message sent by the corresponding node in real time until the second timer ends.
[0046] Step S320: If the sub-controller receives the node wake-up request message or the main network sleep interruption instruction before the second timer expires, the sub-controller resets the second timer and sends the sub-network sleep interruption instruction to each node.
[0047] Furthermore, from the start of the second timer by the sub-controller until its expiration, each sub-controller continuously acquires node wake-up request messages that may be sent by the nodes under its jurisdiction, while simultaneously listening for the main network sleep interruption command from the main controller. If a sub-controller acquires any node wake-up request message or main network sleep interruption command before the second timer expires, the sub-controller resets its second timer and sends a subnet sleep interruption command to all its subordinate nodes. This allows wake-up events from the node layer or upper layers to quickly interrupt the subnet-level sleep preparation, forming a top-down interrupt propagation path and ensuring rapid propagation and consistent action of the interrupt signal.
[0048] Optionally, the method further includes, for example, Figure 5 The following steps are shown: Step S410: After the third timer starts, each node acquires its corresponding local wake-up signal in real time until the third timer ends.
[0049] Step S420: If a node obtains the corresponding local wake-up signal or the subnet sleep interruption instruction before the third timer ends, the node resets the third timer.
[0050] Furthermore, from the start of the third timer on each node until its expiration, each node continuously acquires its corresponding local wake-up signal, such as hardware interface signals like the brake pedal, while simultaneously listening for subnet sleep interrupt commands from the upper-level sub-controller. If a node acquires a local wake-up signal (such as the brake pedal signal) or a subnet sleep interrupt command before the third timer expires, that node resets its third timer. This design ensures that nodes can promptly exit the sleep preparation state based on local events or upper-level commands. Additionally, nodes can be configured to block application message wake-up triggers to prevent accidental wake-ups caused by non-critical communication messages.
[0051] Optionally, the method further includes: Each sub-controller monitors the first handshake message of the corresponding node in real time.
[0052] If the sub-controller does not receive the first handshake message from the same node for a preset number of consecutive preset times within a preset time period, the sub-controller determines that the node is a faulty node.
[0053] Each sub-controller assesses the communication health of each node under its jurisdiction by monitoring the first handshake messages periodically sent by that node in real time. If a sub-controller fails to receive a first handshake message from the same node for a preset number of consecutive times (e.g., 3 times) within a preset time period (e.g., 260ms), that node is considered a faulty node. This fault detection mechanism allows sub-controllers to promptly identify nodes that are out of contact or have abnormal communication. The same method can be used to assess the communication health between the main controller and each sub-controller, enabling the main controller to determine whether a communication failure has occurred between it and the sub-controllers.
[0054] Optionally, after the sub-controller determines that the node is a faulty node, the method further includes: The sub-controller sends a fault notification to the faulty node and isolates the faulty node when sending the second sleep command.
[0055] After receiving the fault notification, the faulty node sends a limp home message to the sub-controller to confirm the fault status.
[0056] When a sub-controller determines that a node is faulty, it sends a fault notification to that node and isolates it when sending a second sleep command, meaning it stops sending sleep commands to that node or waits for its response. Upon receiving the fault notification, the faulty node sends a LimpHome message to the sub-controller to confirm its fault status. This ensures that a single node failure does not block the sleep process of the entire subnet or the entire network, while also ensuring that the behavior of the faulty node conforms to the specifications.
[0057] The present invention has at least the following beneficial effects: The system employs an in-vehicle network sleep management system comprising a main controller, multiple sub-controllers, and multiple nodes. When a vehicle needs to enter sleep mode, a three-tiered timer is set for the main controller, each sub-controller, and each node. The sub-controller is notified when the third timer on each node ends; the main controller is notified when the second timer on each sub-controller ends; and finally, the main controller synchronizes all nodes and sub-controllers into sleep mode after the first timer on the main controller ends. This achieves synchronized node sleep and eliminates delayed sleep.
[0058] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of the invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.
[0059] In addition, the functional modules in the various embodiments of the present invention can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.
[0060] If the functionality is implemented as a software module 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 invention, or the part that contributes to the prior art, or a 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 invention. 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.
[0061] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.
Claims
1. An in-vehicle network sleep management method characterized by comprising: The application is applied to a vehicle-mounted network sleep management system, which comprises a main controller, a plurality of sub-controllers and a plurality of nodes, the main controller is in communication connection with each sub-controller, each sub-controller is in communication connection with a plurality of nodes, and each node corresponds to only one sub-controller; the method comprises: The main controller sends a first sleep instruction to each sub-controller respectively, and starts a first timer; after receiving a second sleep ready signal fed back by all sub-controllers and the first timer ends, the main controller controls the whole vehicle-mounted network to enter a sleep state; Each sub-controller receives the first sleep instruction, generates a second sleep instruction and sends it to each corresponding node, and starts a second timer; after receiving a first sleep ready signal fed back by all corresponding nodes and the second timer ends, each sub-controller feeds back the second sleep ready signal to the main controller; Each node receives the second sleep instruction and starts a third timer; after the third timer ends, each node enters a pre-sleep state and feeds back a first sleep ready signal to the sub-controller.
2. The in-vehicle network sleep management method of claim 1, wherein, Before the main controller sends a first sleep instruction to each sub-controller respectively, the method further comprises: The main controller monitors an engine state signal and a CAN bus data state signal in real time; If the engine state signal is an engine power-down signal and the CAN bus data state signal is a bus no-data signal, the main controller generates the first sleep instruction.
3. The in-vehicle network sleep management method of claim 1, wherein, The method further comprises: After the first timer starts, the main controller acquires a sub-network wake-up request packet and an engine power-on signal sent by each sub-controller in real time until the first timer ends; If the main controller acquires the sub-network wake-up request packet or the engine power-on signal before the first timer ends, the main controller resets the first timer and sends a main network sleep interruption instruction to each sub-controller.
4. The in-vehicle network sleep management method of claim 3, wherein, The method further comprises: After the second timer starts, each sub-controller acquires a node wake-up request packet sent by each corresponding node in real time until the second timer ends; If the sub-controller acquires the node wake-up request packet or the main network sleep interruption instruction before the second timer ends, the sub-controller resets the second timer and sends a sub-network sleep interruption instruction to each node.
5. The in-vehicle network sleep management method of claim 4, wherein, The method further comprises: After the third timer starts, each node acquires a local wake-up signal corresponding to each node in real time until the third timer ends; If a node acquires a corresponding local wake-up signal or the sub-network sleep interruption instruction before the third timer ends, the node resets the third timer.
6. The in-vehicle network sleep management method of claim 1, wherein, The method further comprises: Each sub-controller monitors a first handshake packet of a corresponding node in real time; If the sub-controller does not receive the first handshake packet of the same node within a preset time length for a preset number of times in succession, the sub-controller determines that the node is a faulty node.
7. The in-vehicle network sleep management method of claim 6, wherein, After the sub-controller determines that the node is a faulty node, the method further comprises: The sub-controller sends a fault notification to the faulty node and isolates the faulty node when sending the second sleep instruction; After receiving the fault notification, the faulty node sends a limp-home packet to the sub-controller to confirm the fault state.
8. The in-vehicle network sleep management method according to any one of claims 1 to 7, characterized by, The main controller and each sub-controller are connected through an Ethernet communication, and each sub-controller is connected with a corresponding node through a CAN bus.
9. The in-vehicle network sleep management method according to any one of claims 1 to 7, characterized by, The duration of the first timer is longer than that of the second timer, and the duration of the second timer is longer than that of the third timer.
10. An in-vehicle network sleep management system, characterized by, The vehicle-mounted network sleep management system comprises a main controller, a plurality of sub-controllers, and a plurality of nodes, the main controller is connected with each sub-controller, each sub-controller is connected with a plurality of nodes, and each node corresponds to only one sub-controller; The main controller is configured to send a first sleep instruction to each sub-controller and start a first timer, and after receiving a second sleep ready signal fed back by all sub-controllers and the first timer ends, control the entire vehicle-mounted network to enter a sleep state; Each sub-controller is configured to receive the first sleep instruction, generate a second sleep instruction and send it to each corresponding node, and start a second timer; After receiving a first sleep ready signal fed back by all corresponding nodes and the second timer ends, each sub-controller feeds back the second sleep ready signal to the main controller; Each node is configured to receive the second sleep instruction and start a third timer; After the third timer ends, each node enters a pre-sleep state and feeds back a first sleep ready signal to the sub-controller.
