A network protocol based vehicle segment wake-up method

Abstract

The application discloses a vehicle section wake-up method based on a network protocol, and is applied to a distributed network communication system comprising a gateway and multiple sub-network sections. In view of the problem that the existing whole-vehicle unified wake-up mechanism leads to excessively high static energy consumption and lacks scene perception, the method determines a function scene according to a local wake-up source by a wake-up trigger node, sets corresponding scene flag bits in a network management message, performs arbitration analysis on the scene flag bits in combination with a bottom-layer hardware wake-up signal by a gateway controller, and performs directional forwarding of the message to a matched target network section. A maintaining wake-up controller of the target network section continuously sends the message to maintain a network wake-up state during function execution. After the scene function is finished, each node actively stops sending the message, and the gateway releases the network after a timeout, so that the target network section is cooperatively put into sleep. The application can selectively wake up relevant network sections according to scenes, and significantly reduces vehicle static energy consumption.

Description

Technical Field

[0001] This invention belongs to the field of vehicle network sleep-wake technology, specifically relating to a segmented vehicle wake-up method based on network protocols. Background Technology

[0002] With the development of intelligent connected vehicles, the number of electronic control units (ECUs) in vehicles has increased significantly. A modern new energy vehicle typically carries dozens or even hundreds of ECUs, distributed across multiple functional domains such as the powertrain domain, body domain, chassis domain, and intelligent driving domain. ECUs in each functional domain are connected via bus networks such as CAN and LIN, and different network segments are routed and forwarded through gateway controllers. Regarding vehicle sleep / wake-up control, the industry currently widely adopts the AUTOSAR Network Management (NM) specification as a standardized solution. The AUTOSAR NM specification defines the format of network management messages and the state machine transition logic. Each node coordinates the network's wake-up and sleep states by periodically sending and receiving network management messages.

[0003] In existing technologies, the ECU wake-up process in new energy vehicles typically employs a unified wake-up mechanism: when any node identifies a valid wake-up source, it wakes up the entire network by sending a network management message, meaning all ECUs within all network segments are simultaneously awakened. The working principle of this unified wake-up method is as follows: after an ECU detects a wake-up source, it sends a network management message. The gateway controller receives this message and forwards it indiscriminately to all network segments. ECUs within each network segment then enter the wake-up state upon receiving the message. Under this mechanism, the gateway controller only plays the role of transparent message forwarding and lacks the ability to selectively route messages based on the wake-up scenario.

[0004] Furthermore, although the existing AUTOSAR NM network management messages reserve a user data area (Byte2 to Byte7) for application-layer customization, current technical solutions do not utilize this user data area to carry functional scenario information. In other words, existing network management messages do not contain any information that can identify the current wake-up scenario type. The gateway controller cannot obtain the specific functional scenario corresponding to the current wake-up request from the message, and therefore cannot make selective routing and forwarding decisions accordingly.

[0005] The aforementioned existing technical solutions have at least the following four technical problems: First, the unified wake-up mechanism leads to excessive static energy consumption for the entire vehicle. When the vehicle is turned off and stationary, certain functional scenarios (such as remote control and charging / discharging) only require a small number of specific ECUs to operate. However, the existing unified wake-up mechanism wakes up all ECUs in all network segments simultaneously. A large number of ECUs unrelated to the current scenario are unnecessarily woken up and kept running, significantly increasing the vehicle's static current consumption. If the vehicle is stationary for a long time, the battery may be depleted, leading to a series of problems such as the vehicle failing to start, electronic control module failure, shortened battery life, or even battery damage. This problem is particularly prominent when the vehicle is turned off and stationary, relying solely on the vehicle's battery for power.

[0006] Second, gateway controllers lack scenario awareness. In existing technologies, after receiving network management messages, gateway controllers simply forward the messages to all network segments according to a fixed routing table, lacking the ability to differentiate routing based on the wake-up scenario. Gateway controllers cannot distinguish whether the current wake-up request corresponds to different functional scenarios such as global wake-up, remote control, or charging / discharging, and therefore can only adopt a "forward all" strategy. The root cause of this problem is that existing network management messages do not carry information that can identify the functional scenario type, and gateway controllers lack the information input needed to make selective forwarding decisions.

[0007] Third, hibernation control lacks scenario-level fine-grained management. Current technologies rely solely on the standard timeout mechanism of the AUTOSAR NM specification: after all nodes stop sending network management messages, each node's NM state machine times out and enters a pre-hibernation mode, eventually entering hibernation. This mechanism operates at the network-wide level—either all network segments are woken up, or all network segments are hibernating, failing to achieve segmented control where some segments are woken up while others remain silent. Furthermore, the network lacks a coordination mechanism where a specific controller actively maintains the wake-up state of a particular network segment and proactively releases the network after the scenario ends.

[0008] Fourth, the platform portability of wake-up control logic is insufficient. In existing technologies, achieving differentiated wake-up control for different scenarios typically requires developing complex scenario judgment logic on each ECU. Furthermore, scenario definitions and network segmentation differ across vehicle models and electronic / electrical architectures, making it difficult to reuse wake-up control solutions across different platforms. Each vehicle model switch or architecture upgrade necessitates redeveloping and adapting the wake-up control logic, increasing development costs and time. Summary of the Invention

[0009] The purpose of this invention is to address the shortcomings of the aforementioned background technology by providing a vehicle segmented wake-up method based on network protocols. This method can selectively wake up relevant network segments according to different functional scenarios, thereby solving technical problems such as excessive static energy consumption of the whole vehicle, lack of scene perception capability of the gateway controller, coarse granularity of sleep control, and insufficient platform portability under the existing unified wake-up mechanism.

[0010] The technical solution adopted in this invention is: a vehicle segmented wake-up method based on network protocols, applied to a distributed network communication system including a gateway controller and electronic control units distributed in multiple sub-network segments, the method comprising: After identifying a valid local wake-up source, the wake-up trigger node determines the corresponding functional scenario based on the type of the local wake-up source and includes the corresponding scenario flag in the network management message and sends it to its network segment. The gateway controller in the network segment where the wake-up trigger node is located receives the network management message, performs arbitration parsing by combining the status of the underlying hardware wake-up signal with the scenario flag, determines the target network segment that needs to be woken up, and forwards the network management message to the target network segment that matches the functional scenario. After receiving the network management message and being woken up, the wake-up controller in the target network segment sets the corresponding scene flag to valid and continuously sends the network management message during the scene function execution to maintain the network wake-up state of the target network segment. After the scenario function ends, the sustained wake-up controller actively stops sending network management messages. After the gateway controller does not receive other network management messages within a preset time, it actively stops sending its own network management messages to release the network, so that each node in the target network segment can enter a sleep state in accordance with the network management specifications.

[0011] In the above technical solution, the network management message follows the AUTOSAR network management specification; in the data field of the network management message, the 0th byte corresponds to the node address, the 1st byte corresponds to the control bit vector, and the 2nd to 7th bytes are the user data area; the scene flag bit is set in the 3rd byte of the user data area.

[0012] In the above technical solution, different bits in the third byte correspond to different functional scenarios, and the specific mapping rule is as follows: When the scenario is global wake-up, the 0th bit of the 3rd byte is set to 1; When the scenario is remote control, the first bit of the third byte is set to 1; When the scenario is related to charging and discharging, the second bit of the third byte is set to 1.

[0013] In the above technical solution, the logic of the gateway controller performing arbitration parsing in conjunction with the underlying hardware wake-up signal includes: The gateway controller identifies the status of the KL15 ignition signal. When the KL15 hardware connection is valid, the gateway controller does not rely on the setting of the scene flag bit in the received network management message, but actively sets the global wake-up flag to valid and forwards the network management message to all network segments for global wake-up.

[0014] In the above technical solution, when the KL15 hardware connection is invalid, the gateway controller performs a logical OR operation based on the functional scenario flag in the received network management message to determine the target network segment and perform targeted forwarding.

[0015] In the above technical solution, when the network management message received by the gateway controller contains only a scenario flag representing remote control that is set to valid, the gateway controller sends a network management message to the remote control network segment and actively sets the remote control flag to valid in order to wake up the controllers related to the remote control scenario.

[0016] In the above technical solution, when the functional scenario is related to charging and discharging, the specific interaction logic is as follows: When the wake-up trigger node detects that the wake-up source related to charging and discharging is valid, it actively sets the charging and discharging scenario flag to valid and sends it to the network segment where the wake-up trigger node is located via a network management message; After receiving and recognizing the flag bit, the gateway controller actively sets the charging and discharging scenario flag bit to valid and routes the network management message to the power-related network segment. The power domain controller within the power-related network segment acts as a maintain-wake controller, setting the charging / discharging scenario flag to active and continuously sending network management messages to maintain the network wake-up state of the power-related network segment.

[0017] In the above technical solution, the general controllers in the target network segment, except for the wake-up controller, are passively woken up only according to the AUTOSAR network management specification after receiving the network management message. They do not parse or recognize the scene flag bit, and enter the waiting sleep state after the network management message stops being sent.

[0018] The present invention also provides a vehicle network communication gateway controller, configured with program instructions that, when executed, cause the gateway controller to perform the following operations: Receive network management messages from the wake-up trigger node and extract the scene flag bit in the user data area of ​​the message; Monitor the status of the vehicle's underlying hardware wake-up signals; When the underlying hardware wake-up signal is valid, the network management message is forwarded to all network segments to perform a global wake-up; when the underlying hardware wake-up signal is invalid, a logical OR operation is performed on the scene flag bit to actively set the corresponding scene flag bit to valid, and the network management message is only routed and forwarded to the specific network segment corresponding to the scene flag bit. After a specific network segment function is completed and no network management message for that network segment is received within a preset time, it actively stops sending its own network management messages to release the network.

[0019] This invention also provides a message routing and forwarding method for a gateway node, applied to a gateway controller in a vehicle network communication system. The method includes the following steps: Receive network management messages containing specific scenario flags and extract the values ​​of the scenario flags; Identify and obtain the status of the vehicle's underlying hardware wake-up signal, as well as the network management wake-up status of other controllers in the same network segment; When the underlying hardware wake-up signal is determined to be valid, the gateway node broadcasts and forwards the network management message to all network segments to achieve global wake-up; When the underlying hardware wake-up signal is determined to be invalid, the gateway node performs a logical OR operation based on the extracted scene flag bit and sends the network management message only to the relevant network segment that needs to be woken up corresponding to the scene flag bit.

[0020] The beneficial effects of this invention are as follows: This invention achieves closed-loop control from scene recognition to targeted wake-up and then to orderly sleep by establishing a complete process: the wake-up trigger node determines the functional scene, the gateway controller arbitrates and resolves the data and forwards it in a targeted manner, the wake-up controller maintains the network wake-up state, and the scene ends and the system goes into hibernation. Compared with existing unified wake-up schemes, this method can keep ECUs in network segments unrelated to the current functional scene silent, and only wake up network segments related to the scene, thereby significantly reducing the static energy consumption of the vehicle during the vehicle's off-state and effectively avoiding problems such as vehicle failure to start, electronic control module failure, and shortened battery life caused by battery depletion. Simultaneously, due to the adoption of a two-level sleep trigger mechanism—the wake-up controller actively stops sending messages after the scene ends and the gateway controller releases the network after a timeout—it can ensure the complete execution of the scene function while achieving timely and orderly network release, avoiding unnecessary occupation of network resources.

[0021] Furthermore, the network management messages of this invention conform to the AUTOSAR NM specification, and the scene flag is set in the 3rd byte of the user data area. This design makes full use of the user data area mechanism reserved in the AUTOSAR NM specification, and scene information can be transmitted without modifying the underlying communication protocol stack, ensuring full compatibility with the existing AUTOSAR software architecture and reducing the development cost and integration risk of the solution implementation.

[0022] Furthermore, this invention designs a specific mapping relationship between different bits in the third byte and functional scenarios: bit 0 corresponds to global wake-up, bit 1 corresponds to remote control, and bit 2 corresponds to charging / discharging scenarios. This single-byte, multi-bit encoding method enables the gateway controller to quickly parse scenario information through simple bit operations, resulting in extremely low computational overhead, making it suitable for implementation on resource-constrained embedded ECU platforms. Simultaneously, a single byte can support parallel encoding of up to eight scenarios, reserving ample margin for subsequent scenario expansion.

[0023] Furthermore, this invention employs arbitration logic whereby the gateway controller directly executes global wake-up without relying on the scenario flag when the KL15 hardware connection is valid. This design ensures that all ECUs can promptly enter working state upon vehicle power-on, guaranteeing the integrity and reliability of the vehicle's functions. The arbitration strategy, which prioritizes hardware signals over scenario flags, avoids the safety risk of some ECUs failing to wake up after vehicle power-on due to software scenario flag anomalies, thus improving system robustness.

[0024] Furthermore, this invention employs a mechanism whereby the gateway controller determines the specific target network segment by performing a logical OR operation on the scenario flag bit when the KL15 hardware connection is invalid. When multiple wake-up triggering nodes simultaneously request different functional scenarios, the gateway controller can synthesize the set of all target network segments that need to be woken up through a single bit operation, completing the routing decision within a single NM message cycle, thus achieving parallel wake-up for multiple scenarios. This avoids the response delay caused by serially judging multiple scenarios and improves the overall response processing efficiency of the system.

[0025] Furthermore, this invention defines a specific forwarding strategy for the gateway controller to send messages only to the remote control network segment in remote control scenarios. In remote control scenarios, typically only a small number of controllers, such as the T-Box, need to participate in the operation; ECUs in the powertrain domain, chassis domain, and other network segments do not need to be woken up. Through this targeted wake-up strategy, the number of participating ECUs can be reduced by more than 60% compared to a global wake-up scheme, resulting in a significant reduction in static current consumption. The energy-saving effect is particularly significant for scenarios where remote control operations are frequently performed while the vehicle is stationary and off.

[0026] Furthermore, this invention proposes an interactive process in charging and discharging scenarios where the power domain controller initiates wake-up as the wake-up trigger node, the gateway controller performs arbitration routing, and the power domain controller simultaneously acts as a wake-up maintenance controller to continuously maintain the network. The technical advantages of this interactive logic are: the power domain controller, as the controller directly involved in the charging and discharging function, possesses both the ability to detect charging and discharging wake-up sources and the responsibility of maintaining the network wake-up state. Wake-up initiation and network maintenance are completed by the same controller, reducing communication overhead for cross-node coordination and improving response efficiency and system reliability in charging and discharging scenarios. After receiving the network management message carrying the charging and discharging scenario flag from the power domain controller, the gateway controller only maintains the wake-up state of the power-related network segments and does not forward messages to unrelated network segments such as remote control network segments. This ensures that only the power-related network segments are in working condition during charging and discharging, while other network segments remain silent, minimizing auxiliary energy consumption during charging, which is beneficial for improving charging efficiency and protecting battery life.

[0027] Furthermore, this invention proposes that general controllers within the target network segment are passively woken up only according to the AUTOSAR NM specification, without parsing or recognizing scene flags. General controllers do not require any additional scene parsing software logic; their sleep / wake-up behavior is entirely driven by the standard mechanism of the AUTOSAR NM specification, thus significantly reducing the cost of modifying existing ECU software. In vehicle platform development, only gateway controllers and a small number of sustained wake-up controllers need adaptation development for scene flags; the remaining large number of general controllers can directly reuse existing software. This greatly promotes the platform-based porting and large-scale deployment of the segmented wake-up scheme.

[0028] Furthermore, the gateway controller of this invention implements a complete functional chain of "receiving and extracting → hardware signal monitoring → arbitration routing → network release" through configuration program instructions, centralizing the core control logic of segmented wake-up to a single node of the gateway controller. The technical advantage of this centralized architecture is that the decision logic for segmented wake-up does not need to be distributed across various ECUs; iterative optimization of the segmented wake-up function across the entire vehicle can be achieved with a one-time configuration and upgrade on the gateway controller, resulting in low maintenance costs and high upgrade efficiency. In addition, this invention is not limited to a specific hardware signal type, enabling the gateway controller to adapt to various vehicle platforms using different hardware wake-up signals (such as KL15, ACC, body domain hardware wake-up signals, etc.), exhibiting good versatility and portability.

[0029] Furthermore, the gateway node message routing and forwarding method of the present invention describes the complete logical flow of the gateway node executing routing and forwarding decisions after receiving a message from the perspective of method steps. This method, through a two-level determination mechanism of "hardware wake-up signal status judgment + scene flag bit logical OR operation," compresses all the logic of the routing and forwarding decision into a single hardware signal status read and a single bit OR operation, resulting in extremely low computational complexity and suitability for efficient execution on resource-constrained embedded ECU platforms. In addition, this method adopts the higher-level concept of "lower-level hardware wake-up signal," and is not limited to a specific hardware signal type, facilitating adaptation and application in different vehicle platforms and electronic and electrical architectures.

[0030] In summary, this invention introduces a scene flag mechanism into the user data area of ​​network management messages and implements a two-level arbitration architecture that combines hardware signal priority arbitration with scene flag logic OR operation, using the gateway controller as the core hub. This completely solves the problems of excessive static energy consumption of the whole vehicle caused by the unified wake-up mechanism in the prior art, the lack of scene awareness capability of the gateway controller, the lack of scene-level fine-grained management of sleep control, and the insufficient platform portability of wake-up control logic. The technical solution of this invention has simple control logic, requiring only software adaptation on the gateway controller and a few wake-up trigger nodes. Generally, the controller does not need any modification, which facilitates low-cost portability and reuse between different vehicle platforms and electronic and electrical architectures, and has significant engineering practical value. Attached Figure Description

[0031] Figure 1 This is a schematic diagram of the network segmented wake-up process in an embodiment of the present invention.

[0032] Figure 2 This is a schematic diagram of the network topology of the electronic control unit in an embodiment of the present invention.

[0033] Figure 3 This is a schematic diagram of the network management message format in an embodiment of the present invention. Detailed Implementation

[0034] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments to facilitate a clear understanding of the present invention, but these descriptions do not constitute a limitation on the present invention.

[0035] like Figure 1 As shown, this invention provides a vehicle segmented wake-up method based on network protocols, applied to a distributed network communication system including a gateway controller and electronic control units distributed across multiple sub-network segments. The method includes: After identifying a valid local wake-up source, the wake-up trigger node determines the corresponding functional scenario based on the type of the local wake-up source and includes the corresponding scenario flag in the network management message and sends it to its network segment. The gateway controller within the network segment receives the network management message, performs arbitration parsing by combining the status of the underlying hardware wake-up signal with the scenario flag, determines the target network segment that needs to be woken up, and forwards the network management message to the target network segment that matches the functional scenario. After receiving the network management message and being woken up, the wake-up controller in the target network segment sets the corresponding scene flag to valid and continuously sends the network management message during the scene function execution to maintain the network wake-up state of the target network segment. After the scenario function ends, the sustained wake-up controller actively stops sending network management messages. After the gateway controller does not receive other network management messages within a preset time, it actively stops sending its own network management messages to release the network, so that each node in the target network segment can enter a sleep state in accordance with the network management specifications.

[0036] In the description of this invention, it should be noted that the term "network management message" refers to the NM PDU defined in the AUTOSAR Network Management (NM) specification, "network segment" refers to each CAN bus subnet interconnected through the gateway controller, and "scenario flag bit" refers to the bit mark set in the user data area of ​​the network management message to identify the functional scenario.

[0037] Example 1 This embodiment provides a vehicle segmented wake-up method based on network protocols, applicable to a distributed network communication system that includes a gateway controller and electronic control units (ECUs) distributed across multiple sub-network segments.

[0038] like Figure 2 As shown, in the distributed network communication system of this invention, each electronic control unit (ECU) is classified according to its functional domain. ECUs with the same functional domain are distributed on the same CAN bus segment, while ECUs with different functional domains are distributed on different CAN bus segments. The segments are interconnected via a gateway controller. In this embodiment, the network topology includes at least the following segments: Vehicle domain network segment: includes ECUs such as the vehicle domain controller, which are responsible for the control and management of vehicle electrical functions; Power domain network segment: includes power domain controllers (such as battery management system BMS, motor controller MCU, etc.), which are responsible for power system and charging and discharging related functions; Remote control network segment: Includes ECUs such as T-Box controllers related to remote control functions, responsible for receiving and executing remote commands.

[0039] As the core hub, the gateway controller is physically connected to all the aforementioned network segments. It can receive messages from any network segment and route and forward the messages to the target network segment according to preset rules. In the technical solution of this invention, since the gateway controller is physically connected to all network segments simultaneously, regardless of which network segment the wake-up trigger node is located in, when the wake-up trigger node broadcasts a network management message on its own network segment, the gateway controller can directly receive the message through its physical connection to that network segment. This is an inherent characteristic of the CAN bus broadcast communication mechanism.

[0040] The technical advantage of the aforementioned network topology is that by dividing ECUs into different network segments according to their functional domains and using the gateway controller as the sole communication bridge between these segments, the gateway controller gains the ability to selectively route and forward cross-segment packets. This structure forms the physical basis for segmented wake-up—ECUs within a network segment are only woken up when the gateway controller forwards network management packets to that segment; network segments where the gateway controller does not forward packets remain silent, thus achieving the technical objective of on-demand wake-up and reducing overall vehicle static energy consumption.

[0041] like Figure 3 As shown, the network management message used in this embodiment follows the AUTOSAR network management specification. Its CAN message data field consists of 8 bytes (Byte0 to Byte7), and the definitions of each byte are as follows: Byte0 (0th byte): The source node identifier for the network management message, used to identify the network node that sent the message; Byte1 (first byte): Corresponds to the control bit vector (CBV) of the network management message, used to carry control information defined by the AUTOSAR NM specification, including active wake-up bit, NM coordinator sleep bit, etc. Bytes 2 to 7 (2nd to 7th bytes): This is the user data area, which can be customized by the application layer.

[0042] In this invention, the third byte (Byte3) of the user data area is specifically defined as a scene flag field. Different bits in this byte correspond to different functional scenes, and the specific mapping rules are as follows: Bit 0 of Byte3: Global wake-up flag. When this bit is set to 1, it indicates that the current scenario is a global wake-up scenario, requiring the controllers in all network segments to be woken up; Bit 1 of Byte3: Remote control flag. When this bit is set to 1, it indicates that the current scenario is a remote control scenario, and only the network segment related to the remote control function needs to be woken up; The second bit of Byte3 (Byte3.bit2): Charge / discharge scenario flag. When this bit is set to 1, it indicates that the current scenario is a charge / discharge related scenario, and only the power domain related network segment needs to be woken up.

[0043] The above message format design is based on the user data area mechanism reserved in the AUTOSAR NM specification, enabling the transmission of scenario information without modifying the underlying communication protocol stack. By encoding different functional scenarios in different bits of a single byte, it ensures both the efficiency of information transmission (a single byte can support up to 8 scenarios) and facilitates the gateway controller to quickly parse and determine the target network segment through simple bit operations, reducing the computational complexity of arbitration parsing.

[0044] like Figure 1 As shown, the network segmented wake-up method in this embodiment includes the following steps: Step S101: The wake-up trigger node identifies the local wake-up source and determines the functional scenario.

[0045] Upon detecting a valid local wake-up source, the wake-up trigger node (i.e., an ECU with active wake-up capability) determines the corresponding functional scenario based on the type of the local wake-up source. The local wake-up source can be a hardware signal (such as a charging gun insertion signal, a remote key signal, etc.) or a software trigger condition (such as a wake-up command issued by a remote control platform). Based on the type of wake-up source, the wake-up trigger node sets the corresponding scenario flag to valid (i.e., sets the corresponding bit to 1) in Byte 3 of the network management message and sends the network management message to its corresponding CAN bus segment.

[0046] Step S102: The gateway controller receives the message and performs arbitration parsing.

[0047] After receiving the network management message sent by the wake-up trigger node, the gateway controller within the network segment performs arbitration parsing by combining the status of the underlying hardware wake-up signal with the scenario flag in the message to determine the target network segment that needs to be woken up. The core logic of the arbitration parsing is as follows: (a) When the underlying hardware wake-up signal is valid (e.g., the KL15 ignition signal is valid, meaning the vehicle is in the power-on start-up state), regardless of how the scenario flags in Byte3 of the network management message are set, the gateway controller actively sets the global wake-up flag (Byte3.bit0) to valid and forwards the network management message to all network segments to achieve global wake-up. This is because when the vehicle is powered on and started, all ECUs need to participate in the work to ensure the normal operation of the vehicle functions, and there is no need to perform segmented wake-up judgment at this time.

[0048] (b) When the underlying hardware wake-up signal is invalid (e.g., the KL15 ignition signal is invalid, meaning the vehicle is in a stationary, off-state state), the gateway controller performs a logical OR operation based on the functional scenario flag bit in Byte3 of the received network management message. Specifically, the gateway controller performs a bitwise OR operation on each bit of the corresponding Byte3 in the network management messages from all nodes within the network segment to comprehensively determine the set of all functional scenarios that need to be woken up. Based on this, it determines the target network segments that need to be woken up and forwards the network management messages only to these target network segments. When forwarding messages, the gateway controller actively sets the corresponding scenario flag bit in its own network management message to be valid.

[0049] The technical advantages of the aforementioned arbitration resolution mechanism are as follows: Through a two-level arbitration architecture that uses hardware signal priority judgment and scene flag logical OR operation, the gateway controller can quickly achieve global wake-up in power-on scenarios to ensure the availability of vehicle functions, and accurately identify the currently required functional scenarios and wake up only the relevant network segments in engine-off and stationary scenarios, thereby achieving an optimal balance between functional assurance and energy consumption control. The logical OR operation design allows the gateway controller to process multiple scene wake-up requests in parallel when multiple nodes request different scenarios simultaneously, without queuing, thus improving system response efficiency.

[0050] Step S103: The wake-up controller in the target network segment is woken up and maintains the network.

[0051] The wake-up maintainer (WHM) within the target network segment (i.e., the ECU designated to maintain the wake-up state of the network segment) is awakened upon receiving a network management message forwarded by the gateway controller. After being awakened, the WHM sets the corresponding scenario flag to active and continuously and periodically sends network management messages during scenario function execution to maintain the network wake-up state of the target network segment.

[0052] In the AUTOSAR network management specification, the network management state machine remains in Network Mode when receiving or sending network management messages and will not enter Prepare Bus-Sleep Mode. Therefore, the maintain-wake controller can keep all nodes in the target network segment in a network-wake state by continuously sending network management messages until the scenario function is completed.

[0053] Step S104: The general controller is passively woken up.

[0054] Within the target network segment, general controllers, excluding the wake-up controller, are passively woken up only according to the AUTOSAR network management specification upon receiving a network management message; that is, their NM state machine transitions from Bus-Sleep Mode to Network Mode. General controllers do not parse or recognize the scene flag bit content in Byte 3 of the network management message; their wake-up and sleep behaviors are entirely driven by the standard mechanisms of the AUTOSAR NM specification. The technical advantage of this design is that general controllers do not require additional scene parsing logic, reducing the cost of modifying the ECU software and facilitating platform-based design and software reuse across vehicle models.

[0055] Step S105: Collaborate with the sleep function after the scene function ends.

[0056] After the scenario function ends, the wake-up controller actively stops sending network management messages. If the gateway controller does not receive any other network management messages from the target network segment within a preset time (which is related to the timeout period of the NM Timeout Timer in the AUTOSAR NM specification), it determines that the scenario function of that network segment has ended and then actively stops sending its own network management messages to release the network. Subsequently, each node in the target network segment, according to the standard sleep procedure of the AUTOSAR network management specification, has its respective NM state machine transition from Network Mode through Prepare Bus-Sleep Mode to Bus-Sleep Mode, and they collectively enter a sleep state.

[0057] The aforementioned collaborative hibernation mechanism triggers the hibernation process by maintaining the wake-up controller's active cessation of message transmission, achieving a timely response of hibernation upon the end of the scenario; the gateway controller sets a preset timeout as a safety margin to avoid accidental triggering of hibernation due to momentary communication interruption; each node enters hibernation according to the standard procedure of the AUTOSAR NM specification, ensuring the orderliness and consistency of the hibernation process and avoiding communication conflicts.

[0058] When the wake-up scenario is global wake-up, after the vehicle is powered on, the gateway controller detects that the underlying hardware wake-up signal (such as the KL15 ignition signal) is valid. At this time, the gateway controller does not rely on the setting of the scenario flag bit in the received network management message, but actively sets the global wake-up flag bit (Byte3.bit0) to valid and forwards the network management message to all network segments. The passive wake-up controllers in each network segment are normally woken up after receiving the network management message and begin to execute their respective application functions. After the vehicle is powered off, when the KL15 signal becomes invalid, each network node releases the network according to the AUTOSAR network management specification and enters a sleep state collaboratively.

[0059] In a global wake-up scenario, controllers other than the gateway controller do not need to identify or set the scenario flag. Global wake-up is a fundamental scenario for ensuring the integrity of vehicle functions. Its technical effect is to ensure that all ECUs are available after the vehicle is powered on, meeting the full functional requirements of normal driving, diagnosis, calibration, etc.

[0060] When the wake-up scenario is a remote control related scenario, the wake-up triggering node (such as a T-Box controller) recognizes that the local wake-up source is valid (for example, receiving a wake-up command issued by the remote control platform), sets the remote control flag bit (Byte3.bit1) in Byte3 of the network management message to be valid, and sends the network management message to its network segment.

[0061] Upon receiving the network management message, the gateway controller detects that only the remote control flag in Byte3 is set to valid, and that the underlying hardware wake-up signal (such as KL15) is invalid at this time, thus determining that the current scenario is a remote control scenario. Based on this, the gateway controller only sends network management messages to the remote control network segment and actively sets the remote control flag (Byte3.bit1) in its own message to be valid in order to wake up the relevant controllers in the remote control scenario.

[0062] In remote control scenarios, network segments unrelated to remote control, such as the power domain network segment and the body domain network segment, will not receive network management messages, and their internal ECUs remain silent. The technical effect of this segmented wake-up strategy is that when remote control functions are executed while the vehicle is off and stationary, only the necessary controllers are woken up, significantly reducing the number of ECUs involved in the operation. This results in a significant reduction in overall vehicle static energy consumption, extends battery range, and avoids problems such as the vehicle failing to start due to a depleted battery.

[0063] When the wake-up scenario is related to charging and discharging, the specific interaction logic is as follows: (1) The power domain controller (such as the battery management system BMS) acts as a wake-up trigger node. After detecting that the wake-up source related to charging and discharging is valid (such as the charging gun insertion signal), it actively sets the charging and discharging scenario flag bit (Byte3.bit2) to valid and sends it to the power domain network segment where it is located through network management messages.

[0064] (2) The gateway controller receives the network management message through its physical connection to the power domain network segment. After recognizing that the charging and discharging scenario flag bit in Byte3 is set to valid, it actively sets the charging and discharging scenario flag bit (Byte3.bit2) in its own message to valid, and only maintains the transmission of network management messages on the power-related network segment, and does not forward messages to the remote control network segment, the vehicle domain network segment, or other network segments unrelated to the charging and discharging function.

[0065] (3) After the power domain controller completes the wake-up initiation, it also acts as a wake-up maintenance controller, keeping the charging and discharging scenario flag bit active and continuously sending network management messages during the execution of the charging and discharging function to maintain the network wake-up status of the power-related network segments and ensure that the communication links required for the charging and discharging function are continuously available during the execution.

[0066] (4) After the vehicle completes the charging and discharging function, the power domain controller, as the maintain wake-up controller, actively stops sending network management messages. If the gateway controller does not receive other network management messages from the power-related network segment within a preset time, it actively stops sending its own network management messages to release the network, and the vehicle network enters a sleep state in coordination.

[0067] In charging and discharging scenarios, network segments unrelated to the charging and discharging function, such as the remote control network segment, remain silent. When the vehicle is in a stationary state with the engine off, and charging or V2L (Vehicle to Load) discharging function is performed, only the ECUs related to the power domain are activated, while the other ECUs remain dormant. This minimizes auxiliary energy consumption during charging and discharging, improves charging efficiency, and protects battery life. In actual vehicle applications during charging and discharging, the wake-up trigger node depends on the specific electronic and electrical architecture configuration. It can be the power domain controller itself, or other controllers with charging and discharging wake-up source detection capabilities, such as the charging management module. The technical principle is consistent with the interaction process described above.

[0068] Example 2 This embodiment provides a vehicle network communication gateway controller. The gateway controller is configured with program instructions that, when executed by a processor, enable the gateway controller to perform message arbitration and routing forwarding functions in a segmented wake-up scenario.

[0069] Combination Figure 1 and Figure 2 As shown, the core operation flow executed by the gateway controller is as follows: Operation 1: Receive the message and extract the scene flag.

[0070] The gateway controller receives network management messages from the wake-up trigger node and extracts the scene flag value from Byte3 of the message's user data area. The gateway controller parses the state of each bit in Byte3 to obtain the functional scene information corresponding to the current wake-up request.

[0071] Operation 2: Monitor the status of the underlying hardware wake-up signal.

[0072] The gateway controller monitors the status of the vehicle's underlying hardware wake-up signal in real time. In this embodiment, the underlying hardware wake-up signal is specifically the KL15 ignition signal. The KL15 signal is a hardware level signal indicating the vehicle's ignition switch status, and its valid / invalid state directly reflects whether the vehicle is powered on and running. In other embodiments, the underlying hardware wake-up signal can also be an ACC signal, a body domain hardware wake-up signal, or other hardware signals that reflect the overall operating status of the vehicle.

[0073] Operation 3: Arbitrate and route forwarding based on hardware signal status.

[0074] When the underlying hardware wake-up signal is valid (e.g., KL15 hardware connection is valid), the gateway controller performs a global forwarding action. Specifically, the gateway controller, without relying on the setting of the scenario flag bit in the received network management message, actively sets the global wake-up flag bit (Byte3.bit0) to valid and forwards the network management message to all network segments, achieving global wake-up. At this time, the global forwarding has higher priority than the scenario flag bit judgment, ensuring that all ECUs can start normally when the vehicle is powered on.

[0075] When the underlying hardware wake-up signal is invalid (e.g., KL15 hardware connection is invalid), the gateway controller performs a logical OR operation on the received scenario flag. Specifically, the gateway controller performs a bitwise OR operation on each bit of Byte3 in all network management messages received at the current time, comprehensively determines all currently active functional scenarios, and then determines the set of target network segments that need to be woken up. The gateway controller actively sets the corresponding scenario flag to valid and routes network management messages only to the specific network segment corresponding to the scenario flag, without sending network management messages to other network segments.

[0076] The specific decision logic for the logical OR operation is as follows: If only Byte3.bit0 is 1 in the OR operation result, the gateway controller sends a network management message to all network segments and actively sets Byte3.bit0 to valid; If only Byte3.bit1 is 1 in the OR operation result, the gateway controller will only send network management messages to the remote control network segment and actively set Byte3.bit1 to valid; If only Byte3.bit2 is 1 in the OR operation result, the gateway controller will only send network management messages to the power-related network segments and actively set Byte3.bit2 to valid; If multiple bits in the OR operation result are simultaneously 1 (e.g., Byte3.bit1 and Byte3.bit2 are both 1), the gateway controller simultaneously sends network management messages to the remote control network segment and the power-related network segment, and sets the corresponding flag bits to valid, thereby enabling parallel wake-up in multiple scenarios.

[0077] Step 4: Release the network after the function ends.

[0078] After a specific network segment's function is completed, the keep-wake controller within that segment stops sending network management messages. If the gateway controller detects that no network management messages have been received from that segment within a preset time, it determines that the segment's function has ended and proactively stops sending its own network management messages to release the network. The gateway controller then enters a hibernation process according to the AUTOSAR network management policy.

[0079] In this embodiment, the gateway controller achieves precise segmented wake-up routing control with extremely low computational overhead through a two-level arbitration architecture (hardware signal priority judgment + scene flag bit logical OR operation). This gateway controller only needs to add a one-byte scene flag bit definition to the user data area of ​​the network management message, without modifying the underlying implementation of the AUTOSAR NM protocol stack, resulting in strong compatibility and easy portability and reuse across different vehicle platforms. Through the logical OR operation mechanism, the gateway controller naturally supports parallel wake-up for multiple scenes. When multiple wake-up sources trigger different scenes simultaneously, the network segments corresponding to each scene can be woken up synchronously, resulting in high system response efficiency.

[0080] Example 3 This example provides a message routing and forwarding method for a gateway node, applied to a gateway controller in a vehicle network communication system. This example focuses on describing the specific steps of the gateway node performing routing and forwarding decisions after receiving network management messages.

[0081] Combination Figure 1 and Figure 2 As shown, the message routing and forwarding method in this embodiment includes the following steps: Step S301: Receive the message and extract the scene flag bit.

[0082] The gateway node receives a network management message containing a specific scenario flag. The user data area of ​​this network management message carries the scenario flag information, and the gateway node extracts the value of the scenario flag from it. The bit definition of the scenario flag is as shown in Example 1. Figure 3 The message format shown.

[0083] Step S302: Identify the hardware wake-up signal status and the network management wake-up status.

[0084] The gateway node identifies and obtains the status of the vehicle's underlying hardware wake-up signals (such as the KL15 ignition signal status), as well as the network management wake-up status of other controllers in its network segment. The network management wake-up status of other controllers in the network segment refers to whether the gateway node checks whether other controllers in its network segment are also sending network management messages, in order to fully understand the wake-up request situation of the current network segment.

[0085] Step S303: Execute global wake-up when the hardware wake-up signal is valid.

[0086] When the gateway node determines that the underlying hardware wake-up signal is valid, it broadcasts and forwards the network management message to all network segments to achieve global wake-up. This step ensures that all ECUs can start and communicate normally when the vehicle is powered on.

[0087] Step S304: Perform directed forwarding when the hardware wake-up signal is invalid.

[0088] When the gateway node determines that the underlying hardware wake-up signal is invalid, it performs a logical OR operation based on the extracted scenario flag to determine the set of functional scenarios that need to be woken up and their corresponding target network segments. It then sends network management messages only to the relevant network segments that need to be woken up, corresponding to the scenario flag. Unselected network segments will not receive network management messages, and their internal ECUs remain silent.

[0089] Although this embodiment (Embodiment 3) and Embodiment 2 involve the same gateway controller hardware, they differ in their protection perspectives. Embodiment 2 describes the functional modules and operational capabilities that the gateway controller should be configured with from a product perspective; this embodiment describes the specific judgment steps and logical flow of the gateway node executing routing and forwarding decisions after receiving network management messages from a methodological perspective. Together, they constitute a complete technical solution description for the segmented wake-up routing function of the gateway controller.

[0090] The message routing and forwarding method described in this embodiment employs a two-level decision-making mechanism—a hardware wake-up signal status judgment and a scene flag bit logical OR operation—enabling gateway nodes to complete routing and forwarding decisions with a concise and efficient logical flow. The method's decision logic involves only one hardware signal status read and one bit OR operation, resulting in extremely low computational complexity, making it suitable for implementation on resource-constrained embedded ECU platforms. Furthermore, this method abstracts the underlying hardware wake-up signal as a higher-level concept, not limiting it to specific hardware signal types, facilitating adaptation and application across different vehicle platforms and electronic / electrical architectures. When the underlying hardware wake-up signal is specifically a KL15 ignition signal, the existing KL15 hardware circuit of the vehicle's electrical system can be directly reused without incurring additional hardware costs.

[0091] Through the technical solutions described in the above three embodiments, the present invention achieves the following comprehensive technical effects: First, by implementing segmented wake-up of different network segments based on different functional scenarios, the controllers related to the scenario can communicate normally, while unrelated controllers remain silent, greatly reducing the vehicle's static energy consumption. Taking a certain new energy vehicle as an example, in a remote control scenario, only the controllers of the remote control-related network segments are woken up. Compared with a global wake-up solution, the number of ECUs involved can be reduced by more than 60%, and the corresponding static current consumption can be reduced to less than 40% of that with global wake-up.

[0092] Secondly, the control logic is simple, facilitating platform-based design. The gateway controller's arbitration resolution relies solely on a single byte of the scenario flag in the user data area of ​​the network management message and a logical OR operation, eliminating the need to write complex judgment logic for different scenarios. Generally, the controller does not need to recognize the scenario flag at all, simply adhering to the standard behavior of the AUTOSAR NM specification. This design allows the segmented wake-up scheme to be ported to different vehicle platforms at low cost, requiring only adjustments to the bit mapping rules of Byte3 based on the vehicle's network segment division and functional scenario definition.

[0093] Third, it improves overall response and processing efficiency. Through a logical OR operation mechanism, the gateway controller can comprehensively determine multiple scenario requests at once, complete routing decisions and simultaneously wake up multiple target network segments within a single NM message cycle, avoiding the latency caused by sequential wake-up.

[0094] Fourth, it effectively avoids the problem of battery depletion caused by prolonged vehicle idling. Through a segmented wake-up strategy, when the vehicle performs charging, discharging, remote control, and other functions while the engine is off and idle, the battery only needs to supply power to a small number of related ECUs, significantly extending the battery's usable time and avoiding problems such as vehicle failure to start, electronic control module malfunctions, shortened battery life, or even damage caused by battery depletion.

[0095] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

[0096] The contents not described in detail in this specification are existing technologies known to those skilled in the art.

Claims

1. A vehicle segmented wake-up method based on network protocols, applied to a distributed network communication system including a gateway controller and electronic control units distributed across multiple sub-network segments, characterized in that, The method includes: After identifying a valid local wake-up source, the wake-up trigger node determines the corresponding functional scenario based on the type of the local wake-up source and includes the corresponding scenario flag in the network management message and sends it to its network segment. The gateway controller in the network segment where the wake-up trigger node is located receives the network management message, performs arbitration parsing by combining the status of the underlying hardware wake-up signal with the scenario flag, determines the target network segment that needs to be woken up, and forwards the network management message to the target network segment that matches the functional scenario. After receiving the network management message and being woken up, the wake-up controller in the target network segment sets the corresponding scene flag to valid and continuously sends the network management message during the scene function execution to maintain the network wake-up state of the target network segment. After the scenario function ends, the sustained wake-up controller actively stops sending network management messages. After the gateway controller does not receive other network management messages within a preset time, it actively stops sending its own network management messages to release the network, so that each node in the target network segment can enter a sleep state in accordance with the network management specifications.

2. The method according to claim 1, characterized in that, The network management message follows the AUTOSAR network management specification; in the data field of the network management message, the 0th byte corresponds to the node address, the 1st byte corresponds to the control bit vector, and the 2nd to 7th bytes are the user data area; the scene flag bit is set in the 3rd byte of the user data area.

3. The method according to claim 2, characterized in that, Different bits in the third byte correspond to different functional scenarios, and the specific mapping rules are as follows: When the scenario is global wake-up, the 0th bit of the 3rd byte is set to 1; When the scenario is remote control, the first bit of the third byte is set to 1; When the scenario is related to charging and discharging, the second bit of the third byte is set to 1.

4. The method according to claim 1, characterized in that, The logic for arbitration resolution by the gateway controller in conjunction with the underlying hardware wake-up signal includes: The gateway controller identifies the status of the KL15 ignition signal. When the KL15 hardware connection is valid, the gateway controller does not rely on the setting of the scene flag bit in the received network management message, but actively sets the global wake-up flag to valid and forwards the network management message to all network segments for global wake-up.

5. The method according to claim 4, characterized in that, When the KL15 hardware connection is invalid, the gateway controller performs a logical OR operation based on the functional scenario flag in the received network management message to determine the target network segment and perform targeted forwarding.

6. The method according to claim 5, characterized in that, When the gateway controller receives a network management message containing only a scenario flag representing remote control that is set to valid, the gateway controller sends a network management message to the remote control network segment and actively sets the remote control flag to valid in order to wake up the controllers related to the remote control scenario.

7. The method according to claim 5, characterized in that, When the functional scenario is related to charging and discharging, the specific interaction logic is as follows: When the wake-up trigger node detects that the wake-up source related to charging and discharging is valid, it actively sets the charging and discharging scenario flag to valid and sends it to the network segment where the wake-up trigger node is located via a network management message; After receiving and recognizing the flag bit, the gateway controller actively sets the charging and discharging scenario flag bit to valid and routes the network management message to the power-related network segment. The power domain controller within the power-related network segment acts as a maintain-wake controller, setting the charging / discharging scenario flag to active and continuously sending network management messages to maintain the network wake-up state of the power-related network segment.

8. The method according to claim 1, characterized in that, Within the target network segment, all controllers except the one that maintains wake-up control are passively woken up according to the AUTOSAR network management specification after receiving a network management message. They do not parse or recognize the scenario flag bit, and enter a waiting sleep state after the network management message stops being sent.

9. A vehicle network communication gateway controller, characterized in that, The gateway controller is configured with program instructions that, when executed, cause it to perform the following operations: Receive network management messages from the wake-up trigger node and extract the scene flag bit in the user data area of ​​the message; Monitor the status of the vehicle's underlying hardware wake-up signals; When the underlying hardware wake-up signal is valid, the network management message is forwarded to all network segments to perform a global wake-up; when the underlying hardware wake-up signal is invalid, a logical OR operation is performed on the scene flag bit to actively set the corresponding scene flag bit to valid, and the network management message is only routed and forwarded to the specific network segment corresponding to the scene flag bit. After a specific network segment function is completed and no network management message for that network segment is received within a preset time, it will proactively stop sending its own network management messages to release the network.

10. A message routing and forwarding method for a gateway node, applied to a gateway controller in a vehicle network communication system, characterized in that, The method includes the following steps: Receive network management messages containing specific scenario flags and extract the values ​​of the scenario flags; Identify and obtain the status of the vehicle's underlying hardware wake-up signal, as well as the network management wake-up status of other controllers in the same network segment; When the underlying hardware wake-up signal is determined to be valid, the gateway node broadcasts and forwards the network management message to all network segments to achieve global wake-up; When the underlying hardware wake-up signal is determined to be invalid, the gateway node performs a logical OR operation based on the extracted scene flag bit and sends the network management message only to the relevant network segment that needs to be woken up corresponding to the scene flag bit.

Images