A network management method of a vehicle, a vehicle, and a storage medium

Abstract

The application provides a network management method of a vehicle, the vehicle and a storage medium, and belongs to the technical field of vehicles. The method comprises the following steps: determining a first type of ECU and a second type of ECU in each ECU of the vehicle; wherein the first type of ECU supports a network management protocol, and the second type of ECU does not support the network management protocol; controlling the working state of the first type of ECU according to a network management message associated with the network management protocol; and performing power distribution operation on the second type of ECU according to a power distribution strategy corresponding to the functional requirement of the second type of ECU, so as to control the working state of the second type of ECU; wherein the power distribution strategy is used for the second type of ECU to realize the functional requirement when the ignition switch is off. The method can reasonably reduce the number of ECUs supporting the network management protocol, and reduce the development difficulty and cost.

Description

Technical Field

[0001] This application relates to the field of vehicles, and more specifically, to a network management method for vehicles, a vehicle, and a storage medium in the field of vehicles. Background Technology

[0002] Currently, vehicle network management primarily utilizes AUTOSAR (Automotive Open System Architecture) and OSEK (Open Systems and Interfaces for Vehicle Electronic Systems) network management. Electronic Control Units (ECUs) requiring functionality when the ignition switch is off (IG OFF) all need to support network management protocols. As vehicle configurations increase and functions become more numerous, the number of ECUs also increases. This necessitates suppliers possessing greater development capabilities or purchasing protocol stacks to implement network management, significantly increasing the costs of vehicle and component development and testing. Therefore, how to reasonably reduce the number of ECUs supporting network management protocols, thereby lowering development difficulty and costs, has become a pressing technical challenge. Summary of the Invention

[0003] This application provides a network management method for a vehicle, a vehicle, and a storage medium. This method can reasonably reduce the number of ECUs supporting network management protocols, thereby reducing development difficulty and cost.

[0004] In a first aspect, a network management method for a vehicle is provided. The method includes: identifying a first type of ECU and a second type of ECU among various ECUs in the vehicle; wherein the first type of ECU supports a network management protocol, and the second type of ECU does not support the network management protocol; controlling the operating state of the first type of ECU according to a network management message associated with the network management protocol; and performing a power distribution operation on the second type of ECU according to a power distribution strategy corresponding to the functional requirements of the second type of ECU, thereby controlling the operating state of the second type of ECU; wherein the power distribution strategy is used to enable the second type of ECU to achieve the functional requirements when the ignition switch is off.

[0005] The above technical solution divides the ECUs in the vehicle into two main categories: Category 1 ECUs that support network management protocols and Category 2 ECUs that do not. For Category 1 ECUs, the operating state is controlled according to network management messages associated with the network management protocol. For Category 2 ECUs, power distribution operations are performed on the ECUs according to the power distribution strategy corresponding to their functional requirements to control their operating state. This allows Category 2 ECUs in the vehicle to fulfill their functional requirements even when the ignition switch is off, without needing to support the network management protocol, based on the power distribution strategy. This helps to reasonably reduce the number of ECUs supporting the network management protocol, thereby reducing development difficulty and cost.

[0006] In conjunction with the first aspect, in some possible implementations, after determining the first type of ECU and the second type of ECU, the method further includes: dividing the second type of ECU into several subclasses according to the functional requirements of each ECU in the second type of ECU; wherein each subclass corresponds to its own power distribution strategy; the step of performing power distribution operations on the second type of ECU according to the power distribution strategy corresponding to the functional requirements of the second type of ECU to control the working state of the second type of ECU includes: performing power distribution operations on the ECUs under each subclass according to the power distribution strategy corresponding to each subclass in the second type of ECU to control the working state of the ECUs under each subclass in the second type of ECU.

[0007] The above technical solution, by dividing the second type of ECU into several subcategories and formulating specific power distribution strategies for each subcategory, allows for precise control of power supply based on the actual functional requirements of the ECUs within each subcategory. This means that power is only supplied to the relevant ECUs when needed, reducing unnecessary power consumption. Dividing the second type of ECU into multiple subcategories facilitates modular management and maintenance, and the power distribution strategy for each subcategory can be configured and optimized independently, reducing the complexity of vehicle network management.

[0008] In conjunction with the first aspect, in some possible implementations, the plurality of subclasses include: a first subclass, a second subclass, a third subclass, and a fourth subclass; the ECUs under the first subclass are powered by IG or VC+, and begin communication when the power switch is turned on, and stop communication when the power switch is turned off; the ECUs under the second subclass are powered by B+ or VB+, and begin communication when the ignition switch is turned on, and stop communication when the ignition switch is turned off; the ECUs under the third subclass are powered by VC+, and begin communication when the ignition switch is turned on, and stop communication after the ignition switch is turned off or after a power-down handshake; the ECUs under the fourth subclass are powered by VC+, and begin communication when the power switch is turned on, and stop communication after a power-down handshake.

[0009] In conjunction with the first aspect, in some possible implementations, the power distribution strategy corresponding to the first subclass is a power-down delay strategy; the step of performing power distribution operations on the ECU under each subclass according to the power distribution strategy corresponding to each subclass in the second type of ECU to control the working state of the ECU under each subclass in the second type of ECU includes: if it is detected that the ignition switch changes from the on state to the off state, then after a preset power-down delay time, a power-down operation is performed on the ECU under the first subclass.

[0010] The above technical solution, by adopting a power-down delay strategy, allows the ECU under the first subclass to have time to complete some functional requirements (such as uploading logs, saving settings, self-testing, status updates, etc.) before power-down. This helps ensure that the ECU under the first subclass can successfully complete the relevant functional requirements before power-down even if it does not support network management protocols. Power is then cut off after the relevant functional requirements are completed, preventing data loss or damage.

[0011] In conjunction with the first aspect, in some possible implementations, the power distribution strategy corresponding to the third subclass and the fourth subclass is a power-down handshake strategy. The step of performing power distribution operations on the ECUs under each subclass according to the power distribution strategy corresponding to each subclass in the second type of ECU, to control the working state of the ECUs under each subclass in the second type of ECU, includes: determining whether the target ECU needs to enter the power-down process; wherein the target ECU is an ECU under the third subclass or the fourth subclass; if it is determined that a power-down process needs to be entered, a power-down request message is sent to the target ECU; if a power-down response message is received from the target ECU, a power-down operation is performed on the target ECU; wherein the power-down response message is sent by the target ECU after receiving the power-down request message and determining that the power-down conditions are met.

[0012] The above technical solution achieves more intelligent and reliable power management by implementing a power-down handshake strategy for ECUs in the third and fourth subcategories and exchanging messages when the power-down process needs to be initiated to ensure orderly power-down. The VIU only performs the power-down operation on the target ECU after receiving the power-down response message, ensuring that the target ECU is powered down only after the power-down conditions are met, avoiding problems caused by power-down interruptions, and ensuring that power is cut off only after all preparations are completed, thus improving stability.

[0013] In conjunction with the first aspect, in some possible implementations, after sending a power-down request message to the target ECU, the method further includes: starting a timer from the moment the power-down request message is sent to obtain a first timer duration; if the first timer duration exceeds a first preset timer duration and no power-down response message is received from the target ECU, then a power-down operation is performed on the target ECU.

[0014] The above technical solution, by setting a first preset time period, ensures that even if the target ECU does not reply to the power-down response message in a timely manner, it will not wait indefinitely. If the target ECU fails to complete the necessary tasks and reply to the power-down response message within the first preset time period, or if the target ECU has sent the power-down response message but the VIU has not successfully received it due to network issues, a forced power-down operation will be performed to prevent the power management of the entire system from failing due to problems with individual ECUs. By setting a reasonable first preset time period, it ensures that unnecessary power is cut off in a timely manner when necessary, saving battery power and preventing power waste in the entire vehicle's electrical system due to abnormal behavior of individual ECUs.

[0015] In conjunction with the first aspect, in some possible implementations, the power-down operation on the target ECU includes: if a power-down response message is received from the target ECU, then a second timing duration is started; or, if the first timing duration exceeds a first preset duration and a power-down response message is still not received from the target ECU, then a second timing duration is started; if the second timing duration exceeds a second preset duration, then a power-down operation is performed on the target ECU.

[0016] The aforementioned technical solution, through a dual timing mechanism (first timing duration and second timing duration), provides more stringent power-down control logic. The second timing duration provides an additional time window, with the second preset duration serving as the final time limit for the power-down operation. This ensures that the power-down operation is forcibly executed when necessary, while also providing sufficient time for the target ECU to complete its necessary tasks. The introduction of the second preset duration mechanism further delays the power-down operation to the target ECU upon receiving a power-down response message or in the event of a timeout, significantly improving system reliability and safety, and enhancing fault tolerance. This dual timing mechanism provides a more refined and intelligent solution for power management and communication control, ensuring optimized vehicle performance and improved user experience.

[0017] In conjunction with the first aspect, in some possible implementations, after the second timing duration is obtained from the start of timing, the method further includes: if the conditions for stopping the power-down process are detected when the second timing duration has not exceeded the second preset duration, a power-down cancellation request message is sent to the target ECU to instruct the target ECU to enter normal working state and reply with a power-down cancellation response message; if the power-down cancellation response message is received from the target ECU before the second timing duration exceeds the second preset duration, the timing of the second timing duration is cancelled; if the power-down cancellation response message is not received from the target ECU when the second timing duration exceeds the second preset duration, the sending of the power-down cancellation request message is stopped, and power is continued to be supplied to the target ECU.

[0018] The above technical solution, by detecting that the conditions for stopping the power-down process are met and sending a power-down cancellation request message, can flexibly adjust the power management strategy according to real-time conditions, avoiding unnecessary power-down operations. Once the conditions for stopping the power-down process are detected, a power-down cancellation request message is immediately sent to the target ECU, instructing it to resume normal operation, ensuring that the target ECU can enter normal operation as soon as possible according to actual needs.

[0019] Secondly, a vehicle network management device is provided, comprising: a determining module for determining a first type of ECU and a second type of ECU among various ECUs of the vehicle; wherein the first type of ECU supports a network management protocol, and the second type of ECU does not support the network management protocol; a first control module for controlling the operating state of the first type of ECU according to a network management message associated with the network management protocol; and a second control module for performing power distribution operations on the second type of ECU according to a power distribution strategy corresponding to the functional requirements of the second type of ECU, thereby controlling the operating state of the second type of ECU; wherein the power distribution strategy is used to enable the second type of ECU to achieve the functional requirements when the ignition switch is off.

[0020] Thirdly, a vehicle is provided, comprising: a memory for storing executable program code; and a processor for calling and running the executable program code from the memory, causing the vehicle to perform the method described in the first aspect or any possible implementation thereof.

[0021] Fourthly, a computer program product is provided, comprising: computer program code, which, when run on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation thereof.

[0022] Fifthly, a computer-readable storage medium is provided that stores computer program code, which, when executed on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation thereof. Attached Figure Description

[0023] Figure 1 This is a schematic flowchart illustrating a vehicle network management method provided in an embodiment of this application;

[0024] Figure 2 This is a schematic diagram of a VIU power distribution classification provided in an embodiment of this application;

[0025] Figure 3 This is a schematic diagram of an ECU state transition provided in an embodiment of this application;

[0026] Figure 4 This is a schematic flowchart illustrating a power-down handshake strategy provided in an embodiment of this application;

[0027] Figure 5 This is a schematic diagram of the structure of a vehicle network management device provided in an embodiment of this application;

[0028] Figure 6 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application. Detailed Implementation

[0029] The technical solutions in this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0030] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0031] The main task of vehicle network management is to coordinate network nodes to enter sleep mode synchronously and to wake up associated nodes after the vehicle is powered off, thus enabling the vehicle to function normally after power failure. It also reduces the vehicle's static current, ensuring that the vehicle can be started after prolonged parking.

[0032] Currently, vehicle network management primarily relies on AUTOSAR and OSEK network management. ECUs requiring functionality in the vehicle's IGOFF mode must support these network management protocols. As vehicle configurations increase and more functions are implemented, the number of network management nodes also grows. This necessitates suppliers possessing greater development capabilities or purchasing protocol stacks to implement network management, significantly increasing the costs of vehicle and component development and testing. However, the inventors of this application have discovered the following problems with current network management methods:

[0033] (1) Both the AUTOSAR network management protocol and the OSEK network management protocol have high requirements for ECU suppliers and high component development costs.

[0034] (2) The increased complexity of vehicle network and ECU software increases the workload of development and testing. However, many ECUs have relatively simple functional requirements in IGOFF mode. To achieve these simple functional requirements, supporting AUTOSAR or OSEK network management protocols results in a waste of resources.

[0035] Therefore, how to reasonably reduce the number of ECUs supporting network management protocols and lower development difficulty and cost has become an urgent technical problem to be solved. To at least address this technical problem, embodiments of this application provide a vehicle network management method applied to a controller in the vehicle. This controller can be a controller with power distribution functions in the vehicle, such as a Vehicle Integrated Unit (VIU). The VIU can manage and coordinate the power distribution of various electrical systems within the vehicle. The following description will use the VIU as the executing entity. This network management method mainly refers to the management method of the vehicle's communication network, controlling the operating state of the ECU to enable or disable communication.

[0036] Figure 1 This is a schematic flowchart of a vehicle network management method provided in an embodiment of this application.

[0037] For example, such as Figure 1 As shown, the network management method for this vehicle includes:

[0038] Step 101: Among the various ECUs in the vehicle, identify the first type of ECU and the second type of ECU; wherein, the first type of ECU supports the network management protocol, while the second type of ECU does not support the network management protocol;

[0039] Step 102: Control the operating state of the first type of ECU according to the network management message associated with the network management protocol;

[0040] Step 103: Based on the power distribution strategy corresponding to the functional requirements of the second type of ECU, perform power distribution operations on the second type of ECU to control its operating state. The power distribution strategy is used to enable the second type of ECU to fulfill its functional requirements when the ignition switch is off.

[0041] exist Figure 1 In the illustrated embodiment, the ECUs in the vehicle are divided into two main categories: a first category of ECUs that support the network management protocol and a second category of ECUs that do not support the network management protocol. For the first category of ECUs, their operating state is controlled according to network management messages associated with the network management protocol. For the second category of ECUs, power distribution operations are performed according to the power distribution strategy corresponding to their functional requirements to control their operating state. This allows the second category of ECUs in the vehicle to achieve their functional requirements without supporting the network management protocol, which helps to reasonably reduce the number of ECUs supporting the network management protocol, thus reducing development difficulty and cost. Furthermore, this embodiment reduces the number of ECUs supporting the network management protocol without affecting the functional requirements of these ECUs when the vehicle's IG OFF position is maintained.

[0042] The following is about Figure 1 The specific implementation methods of each step in the illustrated embodiment are explained below:

[0043] In step 101, the ECUs in the vehicle are divided into two main categories: Category 1 ECUs that support network management protocols and Category 2 ECUs that do not support network management protocols. The network management protocol can be either the AUTOSAR network management protocol or the OSEK network management protocol; this embodiment does not specifically limit this.

[0044] The first type of ECU has more and more complex functional requirements in the IG OFF position. The second type of ECU has fewer and simpler functional requirements in the IG OFF position, which can be understood as the vehicle's ignition switch being turned off. In practice, the first type of ECU has more functional requirements in the IG OFF position than the second type. The complexity of the first type of ECU's functional requirements in the IG OFF position is also higher than that of the second type. In other words, ECUs with more and more complex functional requirements in the IG OFF position still need to support network management protocols to achieve their functional requirements, while ECUs with fewer and simpler functional requirements in the IG OFF position may not need to support network management protocols and can achieve their functional requirements based on corresponding power distribution strategies. Because the second type of ECU has fewer and simpler functional requirements in the IG OFF position, even if a power distribution strategy needs to be set, this strategy can be relatively simple and not too complex.

[0045] For example, ECUs such as the body domain controller and powertrain domain controller have many functional requirements in the IG OFF position, which necessitates support for network management protocols. Without these protocols, fulfilling these functional requirements in the IG OFF position would be very complex. ECUs such as the air conditioning controller and instrument cluster head unit, on the other hand, have fewer functional requirements in the IG OFF position and can therefore not support network management protocols, achieving their functional requirements through zoned power distribution.

[0046] In step 102, for the first type of ECU, the operating state of the first type of ECU is controlled according to the Network Management (NM) message associated with the network management protocol. In network management, the NM message is used to perform critical tasks such as node status management, sleep and wake-up control, and fault detection and recovery, ensuring the efficient and stable operation of the vehicle's internal communication network. The wake-up and sleep states of the first type of ECU are uniformly controlled through the NM message.

[0047] In practical implementation, the format and content of NM messages are defined according to the network management protocol, such as activity messages, sleep request messages, and wake-up messages. When it is necessary to change the working state of the first type of ECU (such as entering hibernation or waking up), this can be achieved by sending the corresponding NM message to the first type of ECU. After receiving the NM message, the first type of ECU updates its own state and performs the corresponding operation (such as entering hibernation mode or resuming communication).

[0048] For example, the BCM (Body Control Module) in the driver's cab is a type 1 ECU that supports network management protocols. When the driver turns the ignition (IG) switch from OFF to ON, the VIU sends an NM wake-up message. Upon receiving the NM wake-up message, the BCM immediately resumes normal operation and prepares to receive and send data.

[0049] In step 103, the power distribution strategy is used to enable the second-type ECU to fulfill its functional requirements when the ignition switch is off (IG OFF). The fulfillment of these functional requirements depends on the power supply status of the second-type ECU. For example, functional requirements might include data storage and continued heat dissipation. Therefore, the second-type ECU needs to perform operations related to data storage and continued heat dissipation while powered on to fulfill these functional requirements. For the second-type ECU, a reasonable power distribution strategy controls the operating state of ECUs that do not support network management protocols. Specifically, the functional requirements of the second-type ECU in the IG OFF position can be clearly defined. For example, some ECUs may need to maintain a low-power mode after the vehicle is turned off, while other ECUs are completely powered off. Based on the functional requirements of the second-type ECU in the IG OFF position, corresponding power distribution strategies are formulated for the second-type ECU, such as on-demand power supply, timed power-off, delayed power-off, and constant power supply. The VIU performs power distribution operations on the second-type ECU based on the vehicle's power status and network sleep / wake-up status, combined with power-down delay and power-down handshake strategies, to control the operating state of the second-type ECU, enabling it to fulfill its corresponding functional requirements in the IG OFF position. When the ignition switch is off (IG OFF), the second type of ECU will not directly enter sleep mode if there is a functional requirement. Instead, it will complete the required functional requirement under the power distribution strategy.

[0050] In one possible implementation, after determining the first type of ECU and the second type of ECU, the method further includes: dividing the second type of ECU into several subclasses according to the functional requirements of each ECU in the second type of ECU; wherein each subclass corresponds to its own power distribution strategy. Correspondingly, the above-mentioned power distribution operation on the second type of ECU according to the power distribution strategy corresponding to the functional requirements of the second type of ECU to control the working state of the second type of ECU includes: performing power distribution operation on the ECUs under each subclass according to the power distribution strategy corresponding to each subclass of the second type of ECU to control the working state of the ECUs under each subclass of the second type of ECU.

[0051] It is understandable that the realization of an ECU's functional requirements depends on whether the ECU is powered and whether it has communication capabilities. Therefore, the functional requirements of an ECU can include power supply requirements and communication requirements, which will be described separately below:

[0052] Power supply requirements refer to the type of power source the ECU is powered by. For example, the ECU may be powered by IG, VC+, B+, or VB+.

[0053] In a vehicle's electronic and electrical systems, different power symbols (such as IG, VC+, B+, and VB+) represent different types of power lines.

[0054] IG power supply means that the ignition power is controlled by the ignition switch. The IG circuit is only powered when the ignition switch is in the ON or ACC position. When the ignition switch is off (IG OFF), the IG circuit is de-energized. IG power supply is mainly used in equipment such as engine management systems and body control systems that need to operate in response to changes in ignition status.

[0055] VC+ (Vehicle Control Positive) is typically used to power specific control modules or sensors, providing a stable power supply specifically for certain control modules (such as the BCM body control module, ABS anti-lock braking system, etc.). It is also usually affected by the ignition switch or other control logic, depending on the vehicle's design, to ensure that critical control modules can function properly when needed, and may maintain power even when the ignition switch is off.

[0056] B+ (Battery Positive) power is drawn directly from the positive terminal of the battery and is not controlled by the ignition switch. Regardless of the ignition switch position, as long as the battery connection is normal, the B+ circuit always has power. B+ power supply is used in critical systems that require continuous power, such as anti-theft systems, remote start systems, and memory seat settings.

[0057] VB+ (Vehicle Battery Positive) is similar to B+, but sometimes specifically refers to the battery power after voltage regulation or protection. As long as the battery connection is normal, the VB+ line always has power. In some cases, VB+ may be processed by a voltage regulator or protection circuit to ensure the stability and safety of the output voltage. VB+ power supply is used in critical systems that require a more stable power source, such as T-Boxes (Telematics Boxes) and communication modules.

[0058] Communication requirements refer to the conditions under which an ECU initiates and deactivates communication. Communication requirements can be categorized into the following four types:

[0059] Communication requirement 1: Communication begins when the power switch is on and ends when the power switch is off.

[0060] Communication requirement 2: Communication begins when the ignition switch is on (IG On) and ends when the ignition switch is off (IG OFF).

[0061] Communication requirement 3: Communication shall cease after the ignition switch is turned off (IG OFF) or after a power-down handshake.

[0062] Communication requirement 4: Communication begins when the power switch is turned on and ends after a power-off handshake.

[0063] In this context, "Power On" means the vehicle's power system is activated, allowing power to be supplied to the ECU, which is then ready to begin operation. "Power OFF" means the vehicle's power system is de-energized, the ECU is powered down, and the communication link is interrupted. "IG On" means the ignition switch is in the "On" position, some electrical systems begin receiving power, and the engine management system and other critical systems prepare to start. The vehicle enters the "IG On" state when the driver places the ignition key or uses a button to turn the ignition switch to the "On" position. "IG OFF" means the ignition switch is in the "Off" position, most electrical systems stop receiving primary power, but some critical systems may maintain minimal activity. Systems such as the anti-theft system and remote start system may continue to operate, listening for abnormal signals or awaiting remote commands. When the vehicle is parked and does not need to be started immediately, it typically switches to the "IG OFF" state to ensure safety and save energy.

[0064] Power-down handshake refers to the process of performing a power-down operation on the ECU based on a preset power-down message transmission and reception strategy. For example, the preset power-down message transmission and reception strategy may include: before the VIU powers off the ECU, it sends a power-down request message to the ECU; and after receiving a power-down response message indicating that the ECU has confirmed that it can be powered down, it then performs the power-down operation on the ECU.

[0065] Stopping communication, or shutting down communication, can be achieved by powering down the ECU. ECU communication shutdown means the ECU stops sending and receiving messages. Starting communication, or enabling communication, can be achieved by powering down the ECU. ECU communication startup means the ECU can send and receive messages as needed.

[0066] The above technical solution, by dividing the second-class ECUs into several subclasses and formulating specific power distribution strategies for each subclass, can precisely control the power supply according to actual functional requirements. This means that power is only supplied to the relevant ECUs when needed, reducing unnecessary power consumption. Dividing the second-class ECUs into multiple subclasses facilitates modular management and maintenance, and the power distribution strategy for each subclass can be configured and optimized independently, reducing the complexity of the overall system.

[0067] In this embodiment, based on the functional requirements of each ECU in the second type of ECU, the second type of ECU can be divided into several subcategories, including: a first subcategory, a second subcategory, a third subcategory, and a fourth subcategory. These four subcategories are described below:

[0068] The ECUs in the first subclass (referred to as Class I ECUs) are powered by IG or VC+, and communication begins when the power switch is on and ends when the power switch is off. Combining the four communication requirements mentioned above, Class I ECUs possess the aforementioned communication requirement 1. For example, Class I ECUs include: WPC (Wireless Power Charger Controller), AC (Air Conditioning Controller), AVAS (Acoustic Vehicle Alerting System), ECAS (Electronic Controlled Air Suspension), EBS (Electronic Braking System), and EPB (Electrical Park Brake).

[0069] The second subclass of ECUs (referred to as Class II ECUs) are powered by B+ or VB+, and communication begins when the ignition switch is on (IG On) and ends when the ignition switch is off (IG Off). Combining the four communication requirements mentioned above, Class II ECUs fulfill communication requirement 2. For example, Class II ECUs include: TPMS (Tire Pressure Monitoring System), EPS (Electric Power Steering), and EMS (Engine Management System).

[0070] The third subclass of ECUs (referred to as Class III ECUs) are powered by VC+ and begin communication when the ignition switch is on (IG On), and stop communication after the ignition switch is off (IG Off) or after a power-down handshake. Combining the four communication requirements mentioned above, Class III ECUs possess communication requirement 3. For example, Class III ECUs include: IFC (Intelligent Forward Camera), BSDL (Blind Spot Detection Radar Left), BSDR (Blind Spot Detection Radar Right), and RET (Retarder control module).

[0071] The ECUs in the fourth subcategory (referred to as Class IV ECUs) are powered by VC+ and begin communication when the power switch is turned on (IG On), and stop communication after a power-down handshake. Combining the four communication requirements mentioned above, Class IV ECUs possess the fourth of these communication requirements. For example, Class IV ECUs include: HCML (Headlamp Control Model Left Hand), HCMR (Headlamp Control Model Right Hand), AVM (Around View Monitor), ICM (Instrument Cluster Module), and HUD (Head-Up Display).

[0072] For example, the VIU performs power distribution operations on the ECUs under each subclass according to the power distribution strategy corresponding to each subclass, in order to control the operating state of the ECUs under each subclass. See also Figure 2 , Figure 2 This is a schematic diagram of a VIU power distribution classification provided in an embodiment of this application. (Through...) Figure 2 As can be seen, the power distribution classification of VIU includes: Class I ECU, Class II ECU, Class III ECU, and Class IV ECU. Class I ECUs include: WPC, AVAS, ECAS, EBS, and EPB. Class II ECUs include: TPMS, EPS, and EMS. Class III ECUs include: IFC, BSDL, BSDR, and RET. Class IV ECUs include: HCML, HCMR, AVM, ICM, and HUD. For example, the ECU status list can be seen in Table 1 below:

[0073] Table 1

[0074]

[0075] Table 1 shows the communication transmission and reception states of the ECU in various states. For example, when the ECU is in the OFF State, both transmission and reception are disabled. When the ECU is in the Normal Working State, both transmission and reception are enabled.

[0076] Figure 3 This is a schematic diagram of an ECU state transition provided in an embodiment of this application.

[0077] For example, such as Figure 3As shown, the ECU starts communicating when Power On, and the ECU state jumps from OFF State to Startup Mode. After initialization is completed in Startup Mode, it enters Normal Working State.

[0078] In the Normal Working State, if a network error is detected, the system transitions to the Bus Error State. In the Bus Error State, if the network error is resolved (Error Handled), the system transitions back to the Normal Working State. In the Bus Error State, if the network error persists for a certain period of time, the system transitions to Shutdown Mode.

[0079] In Normal Working State, if a power-down handshake command (power-down request message) is received, or the power switch is detected to be off (Power OFF) or the ignition switch is detected to be off (IG OFF), the system will switch from Normal Working State to Shutdown Mode.

[0080] In Shutdown Mode, if a power-down handshake cancellation command (power-down cancellation request message) is received, the system transitions from Shutdown Mode to Normal Working State. In Shutdown Mode, if the ECU is completely powered off, the system transitions from Shutdown Mode to OFF State.

[0081] In one possible implementation, the power distribution strategy corresponding to the first subclass is a power-down delay strategy. The above-mentioned power distribution operation is performed on the ECU under each subclass according to the power distribution strategy corresponding to each subclass in the second type of ECU to control the working state of the ECU under each subclass in the second type of ECU, including: if the ignition switch is detected to switch from the on state to the off state, then after a preset power-down delay time, the ECU under the first subclass is powered down.

[0082] The power-down delay strategy means that if the ignition switch is detected to switch from the on state to the off state (IG On to IG OFF), the Class I ECU will not be powered down immediately. Instead, the power-down operation will be performed on the Class I ECU after a preset power-down delay period. The preset power-down delay period can be pre-calibrated, for example, based on the functional requirements of the Class I ECU. Optionally, the preset power-down delay period for the Class I ECU can be 30 seconds.

[0083] Considering that AVAS, ECAS, EBS, and EPB in Class I ECUs typically employ indirect network management, they may not support any network management and can meet functional requirements without requiring specific power distribution strategies. Therefore, the power-down delay strategy in this embodiment can primarily target WPC and AC in the aforementioned Class I ECUs.

[0084] In the specific implementation, if the ignition switch is detected to switch from the on state (IG On) to the off state (IG OFF), a timer starts from the moment the IG On switches to IG OFF. After the timer reaches the preset power-down delay, the VIU performs a power-down operation on the Class I ECU to de-energize it. Figure 2 If a switch from IG On to IG OFF is detected, the VIU will power down the WPC and AC under the Class I ECU after a 30-second delay. Depending on the functional requirements of the WPC and AC, the power-down delay time can be set separately for each. The power-down delay times set for the WPC and AC can be the same or different; this embodiment does not impose specific limitations on this.

[0085] The above technical solution employs a power-down delay strategy for Class I ECUs, enabling them to complete necessary functional operations within a preset power-down delay period. These operations include pre-power-down self-tests and pre-power-down data storage. By adopting this power-down delay strategy, Class I ECUs have time to complete certain functional requirements (such as uploading logs, saving settings, self-tests, and status updates) before power-down. This helps ensure that even ECUs in Class I that do not support network management protocols can successfully complete relevant functional requirements before power-down, preventing data loss or corruption.

[0086] In one possible implementation, the power distribution strategy corresponding to the second subclass is: a power-down without delay strategy; the above-mentioned power distribution operation is performed on the ECU under each subclass according to the power distribution strategy corresponding to each subclass in the second type of ECU, so as to control the working state of the ECU under each subclass in the second type of ECU, including: if the ignition switch is detected to switch from the on state to the off state, then a power-down operation is performed on the ECU under the second subclass.

[0087] Since a Class II ECU initiates communication when IG is ON and disables it when IG is OFF, and has no functional requirements when IG is OFF, if the ignition switch is detected to switch from ON to OFF, the VIU can directly power down the Class II ECU. In other words, a Class II ECU has no functional requirements when IG is OFF, and therefore no power or communication requirements; thus, communication is directly disabled when IG is OFF.

[0088] In one possible implementation, the power distribution strategy corresponding to the third and fourth subclasses is a power-down handshake strategy. The above-mentioned power distribution operation is performed on the ECUs under each subclass according to the power distribution strategy corresponding to each subclass in the second type of ECU, in order to control the working state of the ECUs under each subclass in the second type of ECU, including the following S11 to S13:

[0089] S11: Determine whether the target ECU needs to enter the power-down process.

[0090] The target ECU is an ECU belonging to either the third or fourth subclass. In other words, the power distribution strategy set for both Class III and Class IV ECUs is a power-down handshake strategy. The power-down handshake strategy can be understood as: performing a power-down operation on the target ECU based on the power-down message transmission and reception strategy between the VIU and the target ECU. For example, the implementation of the power-down handshake strategy may include steps S11 to S13.

[0091] Specifically, the VIU can determine whether the target ECU needs to enter the power-down process based on preset trigger conditions. For example, if the VIU determines that trigger condition 1 or trigger condition 2 is met, it determines that the target ECU needs to enter the power-down process. If the VIU determines that neither trigger condition 1 nor trigger condition 2 is met, it determines that the target ECU does not need to enter the power-down process.

[0092] Triggering condition 1: Vehicle operating mode switching, such as switching from normal power distribution mode to factory mode or parking mode. According to the mode switching strategy, the target ECU needs to be powered down after the vehicle operating mode is switched.

[0093] Triggering condition 2: The vehicle power supply is switched to IG OFF state, which requires powering down the target ECU.

[0094] S12: If it is determined that the power-down process needs to be initiated, a power-down request message is sent to the target ECU.

[0095] Specifically, if the VIU determines that a power-down procedure needs to be initiated, it sends a power-down request message to the target ECU. This power-down request message is sent in a maximum of n frames, each frame lasting m milliseconds. Once the VIU receives a power-down response message from the target ECU, it stops sending the power-down request message. Both n and m can be pre-defined; for example, n can be set to 5 and m to 500. Therefore, after determining that a power-down procedure needs to be initiated, the VIU will send a maximum of 5 power-down request messages to the target ECU, each frame lasting 500 milliseconds.

[0096] S13: If a power-down response message is received from the target ECU, a power-down operation is performed on the target ECU. The power-down response message is sent by the target ECU after receiving the power-down request message and determining that the power-down conditions are met.

[0097] The power-down request message is an event-type message. After receiving the power-down request message, the target ECU must reply with a power-down response message. After sending the power-down response message, the target ECU needs to immediately stop sending application messages, but can still receive messages.

[0098] To ensure that the target ECU completes its required functional operations before power-down, the target ECU can determine whether the power-down conditions are met before replying with a power-down response message. If the target ECU determines that it meets the power-down conditions, it then replies with a power-down response message to the VIU, ensuring that the ECU has completed its required functional operations when the VIU performs the power-down operation. The power-down conditions can be determined based on the target ECU's own functional logic, aiming to measure whether the target ECU's functional requirements have been fulfilled. For example, the power-down condition for some ECUs is: necessary data storage has been completed before power-down. The power-down condition for ECUs related to thermal management is: necessary heat dissipation has been completed before power-down. Once the target ECU has completed its necessary functional operations before power-down, it can determine that the power-down conditions are met and then reply with a power-down response message to the VIU. Upon receiving this power-down response message, the VIU performs the power-down operation on the target ECU to de-energize it.

[0099] The above implementation method achieves more intelligent and reliable power management by implementing a power-down handshake strategy for ECUs under the third and fourth subclasses and exchanging messages when the power-down process needs to be entered to ensure orderly power-down. The VIU only performs the power-down operation on the target ECU after receiving the power-down response message, ensuring that the target ECU is powered down only after the power-down conditions are met, avoiding problems caused by power-down midway, and ensuring that power is cut off only after all preparations are completed, thus improving stability.

[0100] In one possible implementation, after sending a power-down request message to the target ECU, the method further includes: starting a timer from the moment the power-down request message is sent to obtain a first timer duration; if the first timer duration exceeds a first preset timer duration and no power-down response message is received from the target ECU, then a power-down operation is performed on the target ECU.

[0101] Specifically, the VIU can start a first timer when sending a power-down request message to obtain a first timing duration and determine in real time whether the first timing duration exceeds a first preset duration. If the first timing duration exceeds the first preset duration and no power-down response message is received from the target ECU, it indicates that the failure to receive the power-down response message from the target ECU may be due to network transmission problems. To prevent the vehicle battery from being completely depleted, the VIU can perform a power-down operation on the target ECU to force it to shut down.

[0102] The first preset duration can be pre-defined. Referring to the example above, after the VIU determines that a power-down process needs to be initiated, the VIU sends a maximum of 5 power-down request messages to the target ECU, each frame lasting 500 milliseconds. In this case, the first preset duration can be defined as 5 × 500 milliseconds = 2.5 seconds.

[0103] The above implementation, by setting a first preset timeout, ensures that even if the target ECU does not promptly respond to the power-down response message, it will not wait indefinitely. If the target ECU fails to complete the necessary tasks and respond to the power-down response message within the first preset timeout, or if the target ECU has sent the power-down response message but the VIU has not successfully received it due to network issues, a forced power-down operation will be performed to prevent the entire system's power management from failing due to a fault in an individual ECU. By setting a reasonable first preset timeout, it ensures that unnecessary power is promptly cut off when necessary, saving battery power and preventing power waste in the entire vehicle's electrical system due to abnormal behavior of an individual ECU.

[0104] In one possible implementation, the above-mentioned power-down operation on the target ECU includes: if a power-down response message is received from the target ECU, then a second timing duration is started; if the second timing duration exceeds a second preset duration, then a power-down operation is performed on the target ECU.

[0105] In this implementation, if the VIU receives a power-down response message from the target ECU, it will not immediately power down the target ECU. Instead, it will start a second timer to obtain a second timing duration. When the second timing duration exceeds a second preset duration, the target ECU will then be powered down. In practice, the existence of a second timing duration can be determined by the functional requirements of the target ECU itself. For example, some target ECUs may require a delay after receiving the power-down response message before powering down. In such cases, the VIU will start timing after receiving the power-down response message to obtain a second timing duration. If the second timing duration exceeds the second preset duration, the target ECU will be powered down.

[0106] In one possible implementation, the above-mentioned power-down operation on the target ECU includes: if the first timing duration exceeds the first preset duration and no power-down response message is received from the target ECU, then timing begins to obtain a second timing duration; if the second timing duration exceeds the second preset duration, then a power-down operation is performed on the target ECU.

[0107] In this implementation, if no power-down response message is received from the target ECU after the first timing period exceeds the first preset timing period, the VIU will not immediately perform a power-down operation on the target ECU. Instead, it will start a second timer to obtain a second timing period. When the second timing period exceeds the second preset timing period, the target ECU will then be powered down.

[0108] The aforementioned second preset duration can be pre-calibrated, which can be understood as the power-down delay duration of the target ECU. It can be set according to the functional requirements of the target ECU itself, such as being calibrated to 5 seconds. However, this embodiment does not make a specific limitation on this.

[0109] The aforementioned technical solution, through a dual timing mechanism (first timing duration and second timing duration), provides more stringent power-down control logic. The second timing duration provides an additional time window, with the second preset duration serving as the final time limit for the power-down operation. This ensures that the power-down operation is forcibly executed when necessary, while also providing sufficient time for the target ECU to complete its necessary tasks. The introduction of the second preset duration mechanism further delays the power-down operation to the target ECU upon receiving a power-down response message or in the event of a timeout, significantly improving system reliability and safety, and enhancing fault tolerance. This dual timing mechanism provides a more refined and intelligent solution for power management and communication control, ensuring optimized vehicle performance and improved user experience.

[0110] Figure 4 This is a schematic flowchart illustrating a power-down handshake strategy provided in an embodiment of this application.

[0111] For example, such as Figure 4 As shown, taking the VIU as an example, the implementation of the power-down handshake strategy includes the following methods:

[0112] Step 401: VIU is powered normally.

[0113] Step 402: The VIU determines whether to enter the power-down process. If yes, proceed to step 403; otherwise, continue to step 401.

[0114] In conjunction with the above, the VIU can determine whether to enter the power-down process based on preset trigger conditions. For example, if the VIU determines that trigger condition 1 or trigger condition 2 is met, it determines that the power-down process needs to be entered. If the VIU determines that neither trigger condition 1 nor trigger condition 2 is met, it determines that the power-down process does not need to be entered.

[0115] Triggering condition 1: Vehicle operating mode switching, such as switching from normal power distribution mode to factory mode or parking mode. According to the mode switching strategy, the ECU needs to be powered down after the switch.

[0116] Triggering condition 2: The vehicle power supply is switched to IG OFF state, which requires powering down the ECU.

[0117] Step 403: The VIU sends a power-down request message to the ECU and starts the Timeout1 timer.

[0118] The "Start Timeout1" can be understood as: starting the timer from the moment the power-down request message is sent, and obtaining the first timeout duration.

[0119] Step 404: The VIU waits for the ECU to reply with a power-down response message.

[0120] Step 405: The VIU determines whether a power-down response message has been received or whether Timeout1 has timed out. If yes, proceed to step 406 or step 407; otherwise, proceed to step 404.

[0121] The VIU's determination of whether Timeout1 has timed out can be understood as: the VIU determining whether the first timing duration has exceeded the first preset duration. If the VIU receives a power-down response message from the ECU or the VIU determines that the first timing duration has exceeded the first preset duration, then step 406 or step 407 is executed.

[0122] Step 406: VIU performs Timeout2 timing (optional for some ECUs).

[0123] Step 406 is optional; whether or not Timeout2 is performed can be determined by the functional requirements of the ECU, and this embodiment does not specifically limit this. Timeout2 can be understood as follows: if a power-down response message is received from the target ECU, then timing begins to obtain the second timing duration. Alternatively, it can be understood as: if the first timing duration exceeds the first preset duration, and a power-down response message is still not received from the target ECU, then timing begins to obtain the second timing duration.

[0124] Step 407: The VIU performs a power-down operation.

[0125] Specifically, if Timeout2 times out, that is, the second timing duration exceeds the second preset duration, the VIU will perform a power-down operation.

[0126] Steps 401 to 407 are performed on the VIU side. Steps 408 to 411, performed on the ECU side, are explained below:

[0127] Step 408: The ECU determines whether it has received a power-down request message. If yes, proceed to step 409; otherwise, continue with step 408.

[0128] The power-down request message received by the ECU is the power-down request message sent by the VIU to the ECU in step 403 above.

[0129] Step 409: The ECU determines whether the power-down conditions are met. If yes, proceed to step 410; otherwise, continue with step 409.

[0130] The power-down condition can be determined based on the functional logic of the ECU itself, aiming to measure whether the ECU's functional requirements have been fulfilled. Different ECUs may have different power-down conditions due to their different functional requirements.

[0131] Step 410: The ECU replies with a power-down response message to the VIU, and then stops sending application messages, but can receive messages.

[0132] Step 411: Within Timeout2, the ECU stores data (optional for some ECUs).

[0133] Within Timeout2, the ECU's data storage can be understood as follows: The ECU performs data storage operations within its power-down delay duration, i.e., as long as the second timing duration does not exceed the second preset duration, to ensure that the ECU completes the data storage function before power-down. It can be understood that when step 406 exists on the VIU side, step 411 will exist on the ECU side. Conversely, when step 406 does not exist on the VIU side, step 411 will not exist on the ECU side.

[0134] It should be noted that, Figure 4 The ECUs mentioned here refer to either Class III or Class IV ECUs. Considering that the RET in a Class III ECU typically uses indirect network management and may not support any network management, nor require a dedicated power distribution strategy to meet functional requirements, the power-down handshake strategy in this embodiment can primarily target the remaining Class III and Class IV ECUs, excluding the RET. In other words, the power-down handshake strategy can primarily target IFC, BSDL, BSDR, HCML, HCMR, AVM, ICM, and HUD.

[0135] In one possible implementation, after obtaining the second timing duration upon starting the timing, the following steps S21 to S23 are also included:

[0136] S21: If the second timing duration does not exceed the second preset duration, and the conditions for stopping the power-down process are detected, a power-down cancellation request message is sent to the target ECU to instruct the target ECU to enter the normal working state and reply with a power-down cancellation response message.

[0137] If the second timing duration does not exceed the second preset duration, it indicates that the current power-down delay time for the target ECU is within the specified time. If the conditions for stopping the power-down process are met at this point, it means that the power-down conditions have changed, and the VIU needs to continue supplying power to the target ECU. Since the VIU has already sent a power-down request message to the target ECU, it can send a cancel power-down request message to the target ECU to ensure that the VIU continues to supply power. Under normal circumstances, if the target ECU receives the cancel power-down request message, it should enter normal working state and reply with a cancel power-down response message. The cancel power-down request message is an event-type message; upon receiving this message, the target ECU must immediately restore network communication and enter normal working state.

[0138] The conditions for stopping the power-down process described above can be preset to determine whether the power-down process of the target ECU should be canceled and normal power supply to the target ECU should be restored.

[0139] For example, after receiving a power-down request message, the target ECU can switch to Shutdown Mode. As shown in Table 1 above, in Shutdown Mode, the target ECU is prohibited from sending data, but can still receive data. When the target ECU receives a cancel power-down request message in Shutdown Mode, it switches from Shutdown Mode to Normal Working State and enters normal working state. In normal working state, the target ECU can normally receive and send data.

[0140] S22: If a power-off cancellation response message is received from the target ECU before the second timing duration exceeds the second preset duration, then the timing of the second timing duration is cancelled.

[0141] Specifically, if the VIU receives a power-off cancellation response message from the target ECU before the second timing duration exceeds the second preset duration, it means that the target ECU has successfully restored network communication and entered normal working state. At this time, the VIU cancels the timing of the second timing duration, that is, the VIU no longer performs the timing of the second timing duration, and the VIU will continue to supply power to the target ECU.

[0142] S23: If a power-off cancellation response message is not received from the target ECU after the second timing period exceeds the second preset time, then stop sending power-off cancellation request messages and continue to supply power to the target ECU.

[0143] Specifically, if the VIU has not received the power-off cancellation response message by the second timeout period exceeds the second preset timeout period, it indicates that the VIU may not have received the power-off response message within the specified time due to network communication issues. In order to avoid the VIU frequently sending power-off cancellation request messages that may not receive a reply, the VIU will no longer send power-off cancellation request messages to the target ECU, but will continue to supply power to the target ECU.

[0144] The above implementation method, by detecting whether the conditions for stopping the power-down process are met and sending a power-down cancellation request message, can flexibly adjust the power management strategy according to the real-time situation and avoid unnecessary power-down operations. Once the conditions for stopping the power-down process are detected, a power-down cancellation request message is immediately sent to the target ECU, instructing it to resume normal operation, ensuring that the target ECU can enter normal operation as soon as possible according to actual needs.

[0145] In this embodiment, different power distribution strategies are defined by combining the VIU's own power distribution function. Combined with the power-down handshake strategy, the VIU's power distribution function enables and disables network communication to achieve the functional requirements of the ECU. This significantly reduces the number of ECUs that support network management protocols (AUTOSAR / OSEK). For example, the second type of ECU in the vehicle does not need to support network management protocols, which reduces development difficulty and testing costs.

[0146] Figure 5 This is a schematic diagram of the structure of a vehicle network management device provided in an embodiment of this application.

[0147] For example, such as Figure 5 As shown, the network management device 500 of the vehicle includes:

[0148] The determination module 501 is used to determine a first type of ECU and a second type of ECU among the various ECUs of the vehicle; wherein the first type of ECU supports the network management protocol, and the second type of ECU does not support the network management protocol;

[0149] The first control module 502 is used to control the working state of the first type of ECU according to the network management message associated with the network management protocol;

[0150] The second control module 503 is used to perform power distribution operations on the second type of ECU according to a power distribution strategy corresponding to the functional requirements of the second type of ECU, so as to control the working state of the second type of ECU. The power distribution strategy is used to enable the second type of ECU to achieve the functional requirements when the ignition switch is off.

[0151] In one possible implementation, the network management device further includes: a classification module, configured to, after determining the first type of ECU and the second type of ECU, divide the second type of ECU into several sub-categories according to the functional requirements of each ECU in the second type of ECU; wherein each sub-category corresponds to its own power distribution strategy; and a second control module 503, specifically configured to: perform power distribution operations on the ECUs under each sub-category according to the power distribution strategy corresponding to each sub-category in the second type of ECU, so as to control the working state of the ECUs under each sub-category in the second type of ECU.

[0152] In one possible implementation, the subclasses include: a first subclass, a second subclass, a third subclass, and a fourth subclass; the ECUs under the first subclass are powered by IG or VC+, and begin communication when the power switch is turned on, and stop communication when the power switch is turned off; the ECUs under the second subclass are powered by B+ or VB+, and begin communication when the ignition switch is turned on, and stop communication when the ignition switch is turned off; the ECUs under the third subclass are powered by VC+, and begin communication when the ignition switch is turned on, and stop communication after the ignition switch is turned off or after a power-down handshake; the ECUs under the fourth subclass are powered by VC+, and begin communication when the power switch is turned on, and stop communication after a power-down handshake.

[0153] In one possible implementation, the power distribution strategy corresponding to the first subclass is a power-down delay strategy; the second control module 503 is specifically used to: if the ignition switch is detected to switch from the on state to the off state, then after a preset power-down delay time, perform a power-down operation on the ECU under the first subclass.

[0154] In one possible implementation, the power distribution strategy corresponding to the third subclass and the fourth subclass is a power-down handshake strategy; the second control module 503 is specifically used to: determine whether the target ECU needs to enter the power-down process; wherein, the target ECU is an ECU under the third subclass or the fourth subclass; if it is determined that it needs to enter the power-down process, a power-down request message is sent to the target ECU; if a power-down response message is received from the target ECU, a power-down operation is performed on the target ECU; wherein, the power-down response message is sent by the target ECU when it determines that the power-down conditions are met after receiving the power-down request message.

[0155] In one possible implementation, the second control module 503 is further configured to, after sending the power-down request message to the target ECU, start timing from the moment the power-down request message is sent to obtain a first timing duration; if the first timing duration exceeds a first preset duration and no power-down response message is received from the target ECU, then a power-down operation is performed on the target ECU.

[0156] In one possible implementation, the second control module 503 is specifically configured to: if a power-down response message is received from the target ECU, start timing to obtain a second timing duration; or, if the first timing duration exceeds a first preset duration and a power-down response message is still not received from the target ECU, start timing to obtain a second timing duration; if the second timing duration exceeds a second preset duration, perform a power-down operation on the target ECU.

[0157] In one possible implementation, the second control module 503 is further configured to: after the second timing duration is obtained from the start timing, if the conditions for stopping the power-down process are detected that the second timing duration has not exceeded the second preset duration, send a power-down cancellation request message to the target ECU to instruct the target ECU to enter normal working state and reply with a power-down cancellation response message; if the power-down cancellation response message is received from the target ECU before the second timing duration exceeds the second preset duration, cancel the timing of the second timing duration; if the power-down cancellation response message is not received from the target ECU when the second timing duration exceeds the second preset duration, stop sending the power-down cancellation request message and continue to supply power to the target ECU.

[0158] Figure 6 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application.

[0159] For example, such as Figure 6As shown, the vehicle 600 includes a memory 601 and a processor 602. The memory 601 stores executable program code 6011, and the processor 602 is used to call and execute the executable program code 6011 to perform a network management method for the vehicle.

[0160] Furthermore, embodiments of this application also protect an apparatus that may include a memory and a processor, wherein the memory stores executable program code, and the processor is used to call and execute the executable program code to perform a vehicle network management method provided in embodiments of this application.

[0161] This embodiment can divide the device into functional modules based on the above method example. For example, each module can correspond to a separate function, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0162] When each functional module is divided according to its corresponding function, the device may further include a determining module, a first control module, and a second control module. It should be noted that all relevant content regarding the steps involved in the above method embodiments can be referenced from the functional descriptions of the corresponding functional modules, and will not be repeated here.

[0163] It should be understood that the apparatus provided in this embodiment is used to execute the above-described vehicle network management method, and therefore can achieve the same effect as the above-described implementation method.

[0164] When using an integrated unit, the device may include a processing module and a storage module. When the device is applied to a vehicle, the processing module can be used to control and manage the vehicle's movements. The storage module can be used to support the vehicle in executing relevant program code.

[0165] The processing module may be a processor or a controller, which can implement or execute various exemplary logic blocks, modules, and circuits shown in conjunction with the disclosure of this application. The processor may also be a combination of functions that implement computing capabilities, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and a microprocessor, etc., and the storage module may be a memory.

[0166] In addition, the device provided in the embodiments of this application may specifically be a chip, component or module. The chip may include a connected processor and a memory. The memory is used to store instructions. When the processor calls and executes the instructions, the chip can execute a vehicle network management method provided in the above embodiments.

[0167] This embodiment also provides a computer-readable storage medium storing computer program code. When the computer program code is run on a computer, the computer executes the above-described related method steps to implement the vehicle network management method provided in the above embodiment.

[0168] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned related steps to implement a vehicle network management method provided in the above embodiment.

[0169] In this embodiment, the device, computer-readable storage medium, computer program product, or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0170] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

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

[0172] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A network management method for vehicles, characterized in that, The method includes: Among the various ECUs in the vehicle, a first type of ECU and a second type of ECU are identified; wherein, the first type of ECU supports the network management protocol, while the second type of ECU does not support the network management protocol; The operating state of the first type of ECU is controlled according to the network management message associated with the network management protocol; According to the power distribution strategy corresponding to the functional requirements of the second type of ECU, power distribution operation is performed on the second type of ECU to control the working state of the second type of ECU; wherein, the power distribution strategy is used to enable the second type of ECU to realize the functional requirements when the ignition switch is off.

2. The method according to claim 1, characterized in that, After determining the first type of ECU and the second type of ECU, the method further includes: Based on the functional requirements of each ECU in the second type of ECU, the second type of ECU is divided into several sub-categories; wherein each sub-category corresponds to its own power distribution strategy; The step of performing power distribution operations on the second type of ECU according to the power distribution strategy corresponding to the functional requirements of the second type of ECU, in order to control the working state of the second type of ECU, includes: According to the power distribution strategy corresponding to each subclass in the second type of ECU, power distribution operation is performed on the ECU under each subclass to control the working state of the ECU under each subclass in the second type of ECU.

3. The method according to claim 2, characterized in that, The subclasses include: a first subclass, a second subclass, a third subclass, and a fourth subclass; The ECUs in the first subclass are powered by IG or VC+, and communication begins when the power switch is turned on and stops when the power switch is turned off. The ECU in the second subclass is powered by B+ or VB+, and begins communication when the ignition switch is turned on and stops communication when the ignition switch is turned off. The ECU in the third subclass is powered by VC+, and begins communication when the ignition switch is turned on, and stops communication after the ignition switch is turned off or after a power-down handshake. The ECUs under the fourth subclass are powered by VC+, and begin communication when the power supply switch is turned on, and stop communication after a power-down handshake.

4. The method according to claim 3, characterized in that, The power distribution strategy corresponding to the first subclass is: power-off delay strategy; The step of performing power distribution operations on the ECUs under each subclass according to the power distribution strategy corresponding to each subclass in the second type of ECU, in order to control the working state of the ECUs under each subclass in the second type of ECU, includes: If the ignition switch is detected to switch from the on state to the off state, a power-down operation is performed on the ECU under the first subclass after a preset power-down delay time.

5. The method according to claim 3, characterized in that, The power distribution strategy corresponding to the third subclass and the fourth subclass is the power-down handshake strategy. The step of performing power distribution operations on the ECUs under each subclass according to the power distribution strategy corresponding to each subclass in the second type of ECU, in order to control the working state of the ECUs under each subclass in the second type of ECU, includes: Determine whether the target ECU needs to enter the power-down process; wherein, the target ECU is an ECU under the third subclass or the fourth subclass; If it is determined that a power-down process is required, a power-down request message is sent to the target ECU. If a power-down response message is received from the target ECU, a power-down operation is performed on the target ECU; wherein, the power-down response message is sent by the target ECU after receiving the power-down request message and determining that the power-down conditions are met.

6. The method according to claim 5, characterized in that, After sending a power-down request message to the target ECU, the method further includes: The first timing duration is obtained by starting the time when the power-down request message is sent; If the first timing duration exceeds the first preset duration and no power-down response message is received from the target ECU, then a power-down operation is performed on the target ECU.

7. The method according to claim 5 or 6, characterized in that, The step of powering down the target ECU includes: If a power-down response message is received from the target ECU, a second timing period is started; or, if the first timing period exceeds the first preset time and a power-down response message is still not received from the target ECU, a second timing period is started. If the second timing duration exceeds the second preset duration, then a power-down operation is performed on the target ECU.

8. The method according to claim 7, characterized in that, After obtaining the second timing duration upon starting the timing, the method further includes: If the second timing duration does not exceed the second preset duration, and the condition for stopping the power-down process is detected, a power-down cancellation request message is sent to the target ECU to instruct the target ECU to enter the normal working state and reply with a power-down cancellation response message. If a power-off cancellation response message is received from the target ECU before the second timing duration exceeds the second preset duration, then the timing of the second timing duration is cancelled. If the target ECU has not responded with a power-off cancellation message by the second preset time period, the sending of the power-off cancellation request message will stop and the power supply to the target ECU will continue.

9. A vehicle, characterized in that, The vehicles include: Memory, used to store executable program code; A processor for calling and running the executable program code from the memory, causing the vehicle to perform the method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, implements the method as described in any one of claims 1 to 8.

Images