Vehicle-mounted network management method and device, vehicle and computer readable storage medium
By managing the vehicle network through a distributed architecture master node, receiving messages from slave nodes and determining their validity, the problem of power depletion caused by the complexity of vehicle electronic and electrical functions is solved, ensuring normal vehicle startup.
Patent Information
- Application Number
- CN202510014998.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-01-03
- Publication Date
- 2026-07-03
AI Technical Summary
Vehicles have complex electronic and electrical functions, and the wake-up/maintenance sources are distributed on different nodes, making it difficult to control the node software. During abnormal wake-up or maintenance, the vehicle may run out of power and fail to start normally.
The vehicular network adopts a distributed architecture. The master node receives network management messages from the slave nodes, judges the validity of the messages based on the number of messages sent in the past, and manages the vehicular network in a reasonable manner to avoid abnormal wake-ups or maintenance.
It effectively avoids vehicle battery drain caused by slave node anomalies, ensuring that the vehicle has enough power to start up. It combines the advantages of distributed and master-slave architectures, ensuring that node functions are implemented normally.
Smart Images
Figure CN122339927A_ABST
Abstract
Description
Technical Field
[0001] This application relates to vehicle technology, and more particularly to an in-vehicle network management method, apparatus, vehicle, computer-readable storage medium, and computer program product. Background Technology
[0002] As vehicles become increasingly intelligent and connected, their electronic and electrical functions are becoming more complex, and there are many wake-up / maintenance sources for the in-vehicle network (such as seat adjustment, door lock switch, scheduled charging, remote control, etc.). In terms of design, it is impossible to deploy all these wake-up / maintenance sources on the same node. Therefore, it is not possible to manage them uniformly through a single node. In practical applications, wake-up / maintenance sources are usually distributed on different nodes, which gives each node the right to directly wake up / maintain the in-vehicle network.
[0003] However, node software development is difficult to control, and it is impossible to ensure that the software of all nodes in the vehicle will not have problems. When the vehicle is in power-off mode (the vehicle power is in the OFF position), if a node has an abnormal wake-up source / maintenance source detection or network management function, the vehicle network will be abnormally woken up or maintained. This may lead to the vehicle losing power and prevent the vehicle from starting normally. Summary of the Invention
[0004] This application provides a vehicle network management method, device, vehicle, computer-readable storage medium, and computer program product that can effectively prevent vehicle battery drain.
[0005] The technical solution of this application is implemented as follows:
[0006] This application provides a vehicle network management method, characterized in that it is applied to a vehicle network employing a distributed architecture, wherein the multiple nodes in the vehicle network include a master node and at least one slave node, wherein the master node is configured to manage the vehicle network; the method includes:
[0007] The master node receives the network management message currently initiated by the target slave node; wherein, the target slave node refers to any one of the at least one slave node;
[0008] The master node determines whether the network management message currently initiated by the target slave node is valid based on the number of network management messages historically initiated by the target slave node.
[0009] When the network management message currently initiated by the target slave node is valid, the master node manages the vehicular network according to the network management message currently initiated by the target slave node.
[0010] This application provides a vehicle network management device, characterized in that it is applied to a vehicle network employing a distributed architecture, wherein the multiple nodes in the vehicle network include a master node and at least one slave node, wherein the master node is configured to manage the vehicle network; the device includes:
[0011] A receiving module is used by the master node to receive network management messages currently initiated by the target slave node; wherein the target slave node refers to any one of the at least one slave node;
[0012] The judgment module is used by the master node to determine whether the network management message currently initiated by the target slave node is valid based on the number of network management messages historically initiated by the target slave node.
[0013] The management module is used to manage the vehicular network according to the network management message currently initiated by the target slave node when the target slave node is valid.
[0014] This application provides a vehicle, including:
[0015] Memory, used to store executable instructions;
[0016] The processor is used to implement the vehicle network management method provided in this application when executing executable instructions stored in the memory.
[0017] This application provides a computer-readable storage medium storing executable instructions, which, when executed by a processor, implement the vehicle network management method provided in this application.
[0018] This application provides a computer program product including executable instructions for implementing the vehicle network management method provided in this application when executed by a processor.
[0019] This application has the following beneficial effects:
[0020] In this application, the master node receives network management messages currently initiated by the target slave node; wherein, the target slave node refers to any one of at least one slave node; the master node determines whether the network management message currently initiated by the target slave node is valid based on the number of network management messages previously initiated by the target slave node; when the network management message currently initiated by the target slave node is valid, the master node manages the vehicle network according to the network management message currently initiated by the target slave node. This application combines the advantages of distributed architecture and master-slave architecture. Slave nodes cannot directly manage the vehicle network, but need to request the master node to manage the vehicle network, which can avoid vehicle power loss due to slave node failure and ensure that the vehicle has sufficient power to support subsequent startup. Attached Figure Description
[0021] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0022] Figure 1 This is a schematic diagram of the architecture of a vehicle provided in an embodiment of this application;
[0023] Figure 2 This is a structural schematic diagram of a vehicle provided in an embodiment of this application;
[0024] Figure 3A This is a first flowchart illustrating the vehicle network management method provided in this application embodiment;
[0025] Figure 3B This is a second flowchart illustrating the vehicle network management method provided in this application embodiment;
[0026] Figure 3C This is a schematic diagram of the third process of the vehicle network management method provided in the embodiments of this application;
[0027] Figure 4 This is a schematic diagram of the fourth process of the vehicle network management method provided in the embodiments of this application;
[0028] Figure 5 This is a schematic diagram of the distribution of vehicle network wake-up sources and node connections provided in an embodiment of this application. Detailed Implementation
[0029] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0030] In the following description, references to "some embodiments" describe a subset of all possible embodiments; however, it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict. In the following description, the term "a plurality of" means at least two.
[0031] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.
[0032] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.
[0033] This application provides an in-vehicle network management method, device, vehicle, computer-readable storage medium, and computer program product that can effectively prevent vehicle battery drain.
[0034] See Figure 1 , Figure 1 This is a schematic diagram of the architecture of a vehicle 100 provided in an embodiment of this application. The vehicle 100's in-vehicle network includes multiple nodes, namely node 1, node 2, node 3, ... Among them, node 1 is configured to manage the in-vehicle network, that is, node 1 is the master node, and the other nodes are slave nodes.
[0035] In some embodiments, node 1 receives a network management message currently initiated by a target slave node, where the target slave node represents any slave node, and node 2 is used as an example of the target slave node; node 1 determines whether the network management message currently initiated by node 2 is valid based on the number of network management messages initiated by node 2 in the past; when the network management message currently initiated by node 2 is valid, node 1 manages the vehicle network based on the network management message currently initiated by node 2.
[0036] See Figure 2 , Figure 2 This is a structural schematic diagram of the vehicle 100 provided in the embodiments of this application. Figure 2 The vehicle 100 shown includes at least one processor 110, a memory 150, at least one network interface 120, and a user interface 130. The various components in the vehicle 100 are coupled together via a bus system 140. It is understood that the bus system 140 is used to enable communication between these components.
[0037] The processor 110 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.
[0038] User interface 130 includes one or more output devices 131 that enable the presentation of media content, including one or more speakers and / or one or more visual displays. User interface 130 also includes one or more input devices 132, including user interface components that facilitate user input, such as a microphone, a touch screen display, other input buttons and controls.
[0039] The memory 150 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 150 may optionally include one or more storage devices physically located away from the processor 110.
[0040] The memory 150 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 150 described in this application embodiment is intended to include any suitable type of memory.
[0041] In some embodiments, memory 150 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.
[0042] Operating system 151 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks;
[0043] The network communication module 152 is used to reach other electronic devices via one or more (wired or wireless) network interfaces 120, exemplary network interfaces 120 including: Bluetooth, WiFi, and Universal Serial Bus (USB), etc.
[0044] Presentation module 153 is configured to enable the presentation of information (e.g., a user interface for operating peripheral devices and displaying content and information) via one or more output devices 131 (e.g., a display screen, a speaker, etc.) associated with user interface 130;
[0045] The input processing module 154 is used to detect and translate one or more user inputs or interactions from one or more input devices 132.
[0046] In some embodiments, the vehicle network management device provided in this application can be implemented in software. Figure 2 A vehicle network management device 155 stored in memory 150 is shown. This device can be software in the form of programs and plug-ins, and includes the following software modules: a receiving module 1551, a judging module 1552, and a management module 1553. These modules are logically connected and can therefore be arbitrarily combined or further separated according to their implemented functions. The functions of each module will be described below.
[0047] See Figure 3A , Figure 3A This is a flowchart illustrating a vehicle network management method provided in an embodiment of this application, which will be combined with... Figure 3A The steps shown are explained.
[0048] In step 101, the master node receives the network management message currently initiated by the target slave node; wherein, the target slave node represents any one of at least one slave node.
[0049] In the solutions provided by related technologies, the architecture of in-vehicle networks typically includes two types: master-slave networks and distributed networks. Master-slave networks are generally used in vehicles with fewer electrical functions. A master-slave network consists of one master node and multiple slave nodes. The master node is configured to manage the in-vehicle network, while slave nodes cannot request to manage the in-vehicle network, which limits the implementation of functions actively triggered by slave nodes. At the same time, master-slave networks require all wake-up sources / maintenance sources in the vehicle to be deployed on the master node, which is difficult to achieve in terms of design (when the master node resources are insufficient, some wake-up source logic can only be completed by specific controllers, such as thermal runaway monitoring). Distributed networks are generally used in vehicles with rich electrical functions. In a distributed network, all nodes have equal status and can directly manage the in-vehicle network, fully meeting the functional requirements of each node in the vehicle. However, if even one node malfunctions (wake-up source / maintenance source detection or network management function malfunction), it will cause the in-vehicle network to be abnormal for a long time, which will lead to the vehicle losing power.
[0050] To address this, the embodiments of this application integrate master-slave networks and distributed networks, achieving the goal that all nodes can request to manage the in-vehicle network, but only a few nodes can directly manage the in-vehicle network. This solves the problem that slave nodes cannot request to manage the in-vehicle network in a master-slave network, and the problem that in a distributed network, all nodes can directly manage the in-vehicle network, leading to any node malfunction causing in-vehicle network malfunctions. A detailed explanation will follow.
[0051] The vehicular network in this embodiment includes multiple nodes, where one node (hereinafter referred to as the master node) is configured to manage the vehicular network, and the remaining nodes are slave nodes. Based on this, the master node receives a network management message initiated by a target slave node, where the target slave node represents any slave node in the vehicular network, and the network management message is used to request management of the vehicular network. It is worth noting that the node involved in this embodiment can refer to an Electronic Control Unit (ECU).
[0052] In some embodiments, the network management message includes a network management message ID to identify the corresponding node. For example, different network management message IDs can be pre-configured for multiple nodes in the vehicular network. In this way, when the master node receives a network management message, it can identify which node sent the network management message based on the network management message ID in the message.
[0053] In some embodiments, network management messages can be broadcast within the vehicular network. This improves the efficiency and reliability of sending network management messages, ensuring that the master node can successfully receive the network management messages currently initiated by the target slave node.
[0054] In step 102, the master node determines whether the network management message currently initiated by the target slave node is valid based on the number of network management messages historically initiated by the target slave node.
[0055] Here, the master node determines the validity of the network management messages currently initiated by the target slave node based on the number of network management messages historically initiated by the target slave node recorded locally. For example, if the number of network management messages historically initiated by the target slave node is less than the threshold, it proves that the target slave node does not constitute frequent requests, therefore the target slave node is considered normal and the network management messages currently initiated by the target slave node are valid; if the number of network management messages historically initiated by the target slave node is greater than or equal to the threshold, it proves that the target slave node constitutes frequent requests, therefore the target slave node is considered abnormal and the network management messages currently initiated by the target slave node are invalid.
[0056] In some embodiments, before the master node receives the network management message currently initiated by the target slave node, the vehicular network management method further includes: when the network management message previously initiated by the target slave node is valid, the master node performs a counting process on the network management messages previously initiated by the target slave node.
[0057] Here, when a network management message initiated by the target slave node in a certain historical period is valid, the master node counts the network management message initiated by the target slave node in that period. This ensures that the master node records locally the number of network management messages initiated by the target slave node in the past that are determined to be valid, thus avoiding the waste of resources caused by counting invalid network management messages.
[0058] In some embodiments, before the master node receives the network management message currently initiated by the target slave node, the vehicular network management method further includes: when the number of network management messages previously initiated by the target slave node reaches a threshold, the master node stops counting the network management messages previously initiated by the target slave node. Here, when the number of network management messages previously initiated by the target slave node reaches the threshold, all subsequent network management messages initiated by the target slave node will be considered invalid. Therefore, there is no need to continue counting the network management messages previously initiated by the target slave node, meaning the number of network management messages previously initiated by the target slave node will always be equal to the threshold, thus avoiding resource waste.
[0059] In step 103, when the network management message currently initiated by the target slave node is valid, the master node manages the vehicle network according to the network management message currently initiated by the target slave node.
[0060] Here, when the network management message initiated by the target slave node is valid, the master node manages the vehicle network according to the network management message initiated by the target slave node. In this way, the target slave node can request the master node to manage the vehicle network, ensuring the normal implementation of the target slave node's own functions.
[0061] It is worth noting that steps 101 to 103 can be performed when the vehicle is in power-off mode (i.e., the vehicle power switch is in the OFF position), thereby effectively preventing the vehicle from losing power during the power-off process.
[0062] In some embodiments, the master node can manage the vehicular network based on the network management message currently initiated by the target slave node in the following manner: when the network management message currently initiated by the target slave node is a network wake-up message, the master node controls the vehicular network to enter the wake-up state; when the network management message currently initiated by the target slave node is a network sustain message, the master node controls the vehicular network to maintain the wake-up state.
[0063] Here, when the target slave node initiates a network management message that is a Wake-up message, the master node controls the vehicular network to enter a wake-up state. The Wake-up message is initiated by the vehicular network when it is in a dormant state. When the target slave node initiates a network maintenance message, the master node controls the vehicular network to maintain a wake-up state. The network maintenance message is initiated by the vehicular network when it is in a wake-up state. Thus, two methods for managing the vehicular network are provided: this embodiment supports requesting to wake up the vehicular network when it is in a dormant state, and also supports requesting to maintain the wake-up state when the vehicular network is in a wake-up state, meeting the different functional requirements of the target slave node.
[0064] In some embodiments, between any steps, the vehicular network management method further includes: when all nodes in the vehicular network are not currently initiating network management messages, or when all currently initiated network management messages are invalid, the master node controls the vehicular network to enter a sleep state.
[0065] Here, when none of the nodes in the vehicle network are currently initiating network management messages, or when all currently initiated network management messages are invalid, the master node controls the vehicle network to enter a sleep state, thereby saving vehicle power and effectively preventing the vehicle from running out of power.
[0066] In some embodiments, between any steps, the vehicular network management method further includes: when the usage conditions of the vehicular network are met, the master node clears the number of network management messages historically initiated by all nodes in the vehicular network to zero.
[0067] Here, when the conditions for using the in-vehicle network are met, it proves that the in-vehicle network needs to be put into use. Therefore, the master node clears the number of network management messages initiated by all nodes in the in-vehicle network in the past, so that the number of network management messages initiated by all nodes in the past can be re-accumulated when managing the in-vehicle network again (e.g., when the vehicle is powered off for the next time). The conditions for using the in-vehicle network include the driver's side door being opened or the vehicle being powered on.
[0068] In some embodiments, between any steps, the vehicular network management method further includes: when the master node initiates a network management message, the master node manages the vehicular network according to the network management message initiated by the master node.
[0069] Here, since the master node is configured to manage the vehicular network, it essentially has the highest privileges. Therefore, when the master node initiates a network management message, there is no need to determine whether the message is valid; instead, the vehicular network is managed directly based on the message. This embodiment requires the master node to be in a normal state, so the validity of the network management message initiated by the master node can be assumed, eliminating the need to waste resources determining its validity.
[0070] like Figure 3A As shown in this embodiment, the master node receives the network management message currently initiated by the target slave node; wherein, the target slave node represents any one of at least one slave node; the master node determines whether the network management message currently initiated by the target slave node is valid based on the number of network management messages previously initiated by the target slave node; when the network management message currently initiated by the target slave node is valid, the master node manages the vehicle network according to the network management message currently initiated by the target slave node. This embodiment combines the advantages of distributed architecture and master-slave architecture. The slave node cannot directly manage the vehicle network, but needs to request the master node to manage the vehicle network, which can avoid vehicle power loss due to slave node abnormalities and ensure that the vehicle has sufficient power to support subsequent startup.
[0071] In some embodiments, see Figure 3B , Figure 3B This is a flowchart illustrating a vehicle network management method provided in an embodiment of this application. Figure 3A Step 102 shown can be implemented through steps 201 to 202, or through steps 203 to 204, and will be explained in conjunction with each step.
[0072] In step 201, when the network management message currently initiated by the target slave node is a Wake-up message, the master node determines whether the Wake-up message currently initiated by the target slave node is valid based on the number of Wake-up messages initiated by the target slave node in the past.
[0073] Here, network management messages include two types: Wake-up messages and network sustain messages. When the target slave node initiates a Wake-up message, the master node determines the validity of the Wake-up message based on the number of Wake-up messages initiated by the target slave node in the past, which is recorded locally. The number of Wake-up messages initiated by the target slave node in the past is counted independently from the number of network sustain messages initiated by the target slave node in the past.
[0074] In some embodiments, the above-mentioned method can be used to determine whether the network wake-up message currently initiated by the target slave node is valid based on the number of network wake-up messages previously initiated by the target slave node: when the number of network wake-up messages previously initiated by the target slave node is less than the number threshold, the master node determines that the network wake-up message currently initiated by the target slave node is valid; when the number of network wake-up messages previously initiated by the target slave node is greater than or equal to the number threshold, the master node determines that the network wake-up message currently initiated by the target slave node is invalid.
[0075] Here, a threshold number can be preset. When the number of Wake-up packets historically initiated by the target slave node is less than the threshold, it proves that the target slave node has not frequently woken up the vehicle network. Therefore, the master node considers the target slave node to be normal and the Wake-up packets currently initiated by the target slave node to be valid. When the number of Wake-up packets historically initiated by the target slave node is greater than or equal to the threshold, it proves that the target slave node has frequently woken up the vehicle network. Therefore, the master node considers the target slave node to be abnormal and the Wake-up packets currently initiated by the target slave node to be invalid. The above method uses the threshold number as a judgment condition, which can accurately determine whether the target slave node has frequently woken up the vehicle network, and thus accurately determine whether the Wake-up packets currently initiated by the target slave node are valid.
[0076] In step 202, when the network wake-up message currently initiated by the target slave node is valid, the master node controls the vehicle network to enter the wake-up state.
[0077] Here, when the network wake-up message initiated by the target node is valid, the master node controls the vehicle network to enter the wake-up state (from the dormant state to the wake-up state).
[0078] In step 203, when the network management message currently initiated by the target slave node is a network maintenance message, the master node determines whether the network maintenance message currently initiated by the target slave node is valid based on the number of network maintenance messages previously initiated by the target slave node.
[0079] Here, when the network management message currently initiated by the target slave node is a network maintenance message, the master node determines whether the network maintenance message currently initiated by the target slave node is valid based on the number of network maintenance messages historically initiated by the target slave node recorded locally.
[0080] In some embodiments, the above-mentioned method of the master node determining the validity of the network maintenance message currently initiated by the target slave node based on the number of network maintenance messages historically initiated by the target slave node can be implemented in the following way: the master node determines the historical maintenance duration corresponding to the target slave node based on the number of network maintenance messages historically initiated by the target slave node and the functional requirement duration corresponding to the target slave node; when the historical maintenance duration corresponding to the target slave node is less than the duration threshold, the master node determines that the network maintenance message currently initiated by the target slave node is valid; when the historical maintenance duration corresponding to the target slave node is greater than or equal to the duration threshold, the master node determines that the network maintenance message currently initiated by the target slave node is invalid.
[0081] Here, the purpose of the target slave node initiating network maintenance messages is to maintain the vehicular network for a period of time, thereby ensuring the successful implementation of the target slave node's own functions. Therefore, the historical maintenance duration corresponding to the target slave node can be obtained by multiplying the number of network maintenance messages historically initiated by the target slave node by the functional requirement duration corresponding to the target slave node. The functional requirement duration corresponding to the target slave node refers to the duration required to successfully implement the target slave node's own functions, and can be preset. When the historical maintenance duration corresponding to the target slave node is less than the duration threshold, it proves that the target slave node has maintained the vehicular network for a relatively short period, therefore the master node considers the target slave node to be normal and the network maintenance message currently initiated by the target slave node to be valid. When the historical maintenance duration corresponding to the target slave node is greater than or equal to the duration threshold, it proves that the target slave node has maintained the vehicular network for a relatively long period, therefore the master node considers the target slave node to be abnormal and the network maintenance message currently initiated by the target slave node to be invalid. The above method takes into account that the purpose of the network maintenance message initiated by the target slave node is to maintain the vehicular network for a period of time. Therefore, it calculates the historical maintenance duration corresponding to the target slave node and accurately determines whether the network maintenance message currently initiated by the target slave node is valid based on the historical maintenance duration. In some embodiments, the historical maintenance duration corresponding to the target slave node can be directly timed, and the validity of the network maintenance message currently initiated by the target slave node can be determined based on the historical maintenance duration.
[0082] In step 204, when the network maintenance message currently initiated by the target slave node is valid, the master node controls the vehicle network to maintain the wake-up state.
[0083] Here, when the target node's current network maintenance message is valid, the master node controls the vehicle network to maintain a wake-up state.
[0084] like Figure 3BAs shown in the embodiments of this application, considering that network management messages include two types, network wake-up messages and network maintenance messages, the network wake-up messages and network maintenance messages initiated by the target slave node in the past are counted independently in order to accurately determine the validity of the network wake-up messages or network maintenance messages currently initiated by the target slave node.
[0085] In some embodiments, see Figure 3C , Figure 3C This is a flowchart illustrating a vehicle network management method provided in an embodiment of this application. Figure 3A Following step 102, in step 301, when the network management message currently initiated by the target slave node is invalid, the master node performs at least one of the following actions: performs alarm processing based on the target slave node; or performs power-off processing on the target slave node.
[0086] Here, when the network management message initiated by the target slave node is invalid, the target slave node has already malfunctioned. Therefore, the master node performs at least one of the following actions: handle an alarm based on the target slave node; or power off the target slave node. Handling an alarm based on the target slave node allows relevant users to understand the abnormal situation of the target slave node so that timely repairs can be made; powering off the target slave node stops it from initiating meaningless network management messages, effectively saving resources.
[0087] Among them, alarm processing based on the target node can refer to outputting an alarm prompt when the vehicle is powered on. The alarm prompt can be displayed on the vehicle's display screen or instrument panel, or it can be output via voice. Alternatively, it can refer to sending the alarm prompt to a server or a specific terminal device (such as the owner's mobile phone) to achieve remote alarm.
[0088] The master node can request the intelligent power distribution module to cut off the power to the target slave node.
[0089] In some embodiments, after powering down the target slave node, the vehicular network management method further includes: when the usage conditions of the vehicular network are met, the master node restores power to the target slave node.
[0090] Here, when the conditions for using the in-vehicle network are met, the master node restores power to the target slave node to avoid affecting the normal operation of the target slave node itself and ensure the availability of vehicle functions. These conditions include the driver's side door being open or the vehicle being powered on.
[0091] like Figure 3CAs shown in the embodiment of this application, when the network management message currently initiated by the target slave node is invalid, an alarm can be triggered based on the target slave node, so that relevant users can be informed of the abnormal situation of the target slave node and repair it in a timely manner; alternatively, the target slave node can be powered off to avoid wasting resources.
[0092] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario. As an example, the embodiments of this application provide, for instance... Figure 4 The diagram shown is a flowchart of an in-vehicle network management method, which will combine... Figure 4 The explanation is presented step by step.
[0093] Step 1: Nodes requiring network communication request the network management and coordination module to wake up / maintain the vehicle network.
[0094] Here, such as Figure 5 The diagram showing the distribution of wake-up sources and node connections in the vehicle network illustrates that, in this embodiment of the application, each node in the vehicle network needs to be assigned an independent network management message ID in advance, as shown in Table 1.
[0095] Table 1 Network Management Message ID Table
[0096] Node Name Node 1 Node 2 Node 3 …… Node N Network Management Message ID 0x501 0x502 0x503 …… 0x50n
[0097] At the same time, all nodes are configured to initiate network management messages. However, only the node with the network management coordination module deployed (i.e., the master node, assuming it is node 1) is configured to be awakened / maintained by other nodes (node 2 to node N). Other nodes are configured to be awakened / maintained only by the node with the network management coordination module deployed.
[0098] Step 2: The network management coordination module determines the validity of the received network management message. If valid, proceed to step 3; if invalid, perform alarm processing according to the corresponding node and simultaneously power off the corresponding node.
[0099] Here, the network management and coordination module independently sets a wake-up counter and a sustain timer for each node (except for nodes where the network management and coordination module is deployed).
[0100] For example, Counter_n represents the wake-up counter corresponding to node N. When a node sends a network wake-up message to the network management and coordination module, and the network wake-up message is determined to be valid, the wake-up counter corresponding to that node is incremented by 1. When the value of the wake-up counter corresponding to a node reaches the upper limit Cmax_n (corresponding to the quantity threshold mentioned above), it stops incrementing, and the network management and coordination module stops responding to network wake-up messages initiated by that node, thereby limiting the node from repeatedly waking up the vehicle network. When the driver's side door of the vehicle is opened or the vehicle is powered on, the wake-up counters corresponding to all nodes are reset to zero.
[0101] For example, Timer_n represents the maintenance timer corresponding to node N. When a node sends a network maintenance message to the network management and coordination module, and the message is deemed valid, the maintenance timer for that node is incremented by the required functional duration. When the value of the maintenance timer for a node reaches the upper limit Tmax_n (corresponding to the duration threshold mentioned above), it stops accumulating, and the network management and coordination module stops responding to network maintenance messages initiated by that node, thereby limiting the time that node requests to maintain the in-vehicle network. When the driver's side door of the vehicle is opened or the vehicle is powered on, the maintenance timers for all nodes are reset to zero.
[0102] Step 3: The network management and coordination module wakes up / maintains the vehicle network. If the vehicle network is being woken up, the wake-up counter Counter_n corresponding to node N that initiated the request is incremented by 1; if the vehicle network is being maintained, the maintenance timer Timer_n corresponding to node N that initiated the request is added to the functional requirement duration corresponding to node N.
[0103] Step 4: The network management and coordination module determines whether the condition "driver's door is open or vehicle is powered on" is met. If it is met, proceed to step 5; otherwise, jump back to step 2.
[0104] Step 5: Clear the wake-up counters and sustain timers for all nodes simultaneously, and jump back to step 2.
[0105] The purpose of simultaneously resetting the wake-up counters and maintenance timers for all nodes is to prevent the values from remaining at the upper limit, which could lead to failed requests or vehicle malfunctions.
[0106] Step 6: If there are no network management messages or all network management messages are invalid, control the vehicle network to enter a sleep state, and the current process ends.
[0107] The embodiments of this application can achieve at least the following technical effects:
[0108] 1) Deploy a network management coordination module on top of the node network management protocol to uniformly control vehicular network requests.
[0109] 2) By using the network management coordination module, combined with the independent network management message ID allocation and specific network configuration of each node, the goal is to allow all nodes to request to wake up / maintain the vehicle network while ensuring that only nodes with the network management coordination module deployed can wake up / maintain the vehicle network. This solves the problem that slave nodes cannot request to wake up / maintain the vehicle network in a master-slave network, and the problem that all nodes in a distributed network can directly wake up / maintain the vehicle network, causing any node to malfunction and triggering a vehicle network malfunction.
[0110] 3) Identify abnormal nodes through the network management and coordination module, and manage abnormal nodes in a closed loop by reporting abnormalities and requesting power outages.
[0111] The following continues to describe the exemplary structure of the vehicle network management device 155 provided in the embodiments of this application as a software module. In some embodiments, such as Figure 2 As shown, the software modules stored in the vehicle network management device 155 in the memory 150 may include: a receiving module 1551, used by the master node to receive the network management message currently initiated by the target slave node; wherein, the target slave node represents any one of at least one slave node; a judging module 1552, used by the master node to judge whether the network management message currently initiated by the target slave node is valid based on the number of network management messages previously initiated by the target slave node; and a management module 1553, used by the master node to manage the vehicle network according to the network management message currently initiated by the target slave node when the network management message currently initiated by the target slave node is valid.
[0112] In some embodiments, the judgment module 1552 is further configured to: when the network management message currently initiated by the target slave node is a network wake-up message, the master node determines whether the network wake-up message currently initiated by the target slave node is valid based on the number of network wake-up messages previously initiated by the target slave node; when the network management message currently initiated by the target slave node is a network maintenance message, the master node determines whether the network maintenance message currently initiated by the target slave node is valid based on the number of network maintenance messages previously initiated by the target slave node.
[0113] In some embodiments, the judgment module 1552 is further configured to: when the number of network wake-up messages initiated by the target slave node in the past is less than the number threshold, the master node determines that the network wake-up message initiated by the target slave node is valid; when the number of network wake-up messages initiated by the target slave node in the past is greater than or equal to the number threshold, the master node determines that the network wake-up message initiated by the target slave node is invalid.
[0114] In some embodiments, the determination module 1552 is further configured to: the master node determine the historical maintenance duration corresponding to the target slave node based on the number of network maintenance messages historically initiated by the target slave node and the functional requirement duration corresponding to the target slave node; when the historical maintenance duration corresponding to the target slave node is less than the duration threshold, the master node determines that the network maintenance message currently initiated by the target slave node is valid; when the historical maintenance duration corresponding to the target slave node is greater than or equal to the duration threshold, the master node determines that the network maintenance message currently initiated by the target slave node is invalid.
[0115] In some embodiments, the management module 1553 is further configured to: when the network management message currently initiated by the target slave node is a network wake-up message, the master node controls the vehicle network to enter the wake-up state; when the network management message currently initiated by the target slave node is a network sustain message, the master node controls the vehicle network to maintain the wake-up state.
[0116] In some embodiments, the management module 1553 is further configured to: when all nodes in the vehicle network have not initiated network management messages or all currently initiated network management messages are invalid, the master node controls the vehicle network to enter a sleep state.
[0117] In some embodiments, the vehicle network management device 155 further includes a counting module, used to: when a network management message initiated by the target slave node in the past is valid, the master node performs counting processing on the network management message initiated by the target slave node in the past.
[0118] In some embodiments, the vehicle network management device 155 further includes an exception handling module, configured to: when the network management message currently initiated by the target slave node is invalid, the master node performs at least one of the following processes: performs alarm processing based on the target slave node; or performs power-off processing on the target slave node.
[0119] In some embodiments, the exception handling module is further configured to: when the usage conditions of the vehicular network are met, the master node restores power to the target slave node.
[0120] In some embodiments, the vehicle network management device 155 further includes a clearing module, used to: when the usage conditions of the vehicle network are met, the master node clears the number of network management messages historically initiated by all nodes in the vehicle network.
[0121] In some embodiments, the management module 1553 is further configured to: when the master node initiates a network management message, the master node manages the vehicle network according to the network management message initiated by the master node.
[0122] This application provides a computer program product or computer program, which includes executable instructions stored in a computer-readable storage medium. The vehicle's processor reads the executable instructions from the computer-readable storage medium and executes the executable instructions, causing the vehicle to implement the in-vehicle network management method described in this application.
[0123] This application provides a computer-readable storage medium storing executable instructions, wherein the executable instructions are stored and, when executed by a processor, will cause the processor to implement the vehicle network management method provided in this application.
[0124] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.
[0125] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.
[0126] As an example, executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple collaborating files (e.g., a file that stores one or more modules, subroutines, or code sections).
[0127] The above are merely embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.
Claims
1. A method of managing an in-vehicle network, characterized by, An application is made to a distributed vehicular network, wherein multiple nodes in the vehicular network include a master node and at least one slave node, wherein the master node is configured to manage the vehicular network; the method includes: The master node receives the network management message currently initiated by the target slave node; wherein, the target slave node refers to any one of the at least one slave node; The master node determines whether the network management message currently initiated by the target slave node is valid based on the number of network management messages historically initiated by the target slave node. When the network management message currently initiated by the target slave node is valid, the master node manages the vehicular network according to the network management message currently initiated by the target slave node.
2. The method of claim 1, wherein, The master node determines the validity of the network management message currently initiated by the target slave node based on the number of network management messages historically initiated by the target slave node, including: When the network management message currently initiated by the target slave node is a Wake-up message, the master node determines whether the Wake-up message currently initiated by the target slave node is valid based on the number of Wake-up messages initiated by the target slave node in the past. When the network management message currently initiated by the target slave node is a network maintenance message, the master node determines whether the network maintenance message currently initiated by the target slave node is valid based on the number of network maintenance messages previously initiated by the target slave node.
3. The method of claim 2, wherein, The master node determines whether the Wake-up message currently initiated by the target slave node is valid based on the number of Wake-up messages historically initiated by the target slave node, including: When the number of Wake-up packets initiated by the target slave node in the past is less than the number threshold, the master node determines that the Wake-up packet currently initiated by the target slave node is valid; When the number of Wake-up packets initiated by the target slave node in the past is greater than or equal to the number threshold, the master node determines that the Wake-up packet currently initiated by the target slave node is invalid.
4. The method of claim 2, wherein, The master node determines the validity of the network maintenance message currently initiated by the target slave node based on the number of network maintenance messages historically initiated by the target slave node, including: The master node determines the historical maintenance duration of the target slave node based on the number of network maintenance messages initiated by the target slave node in the past and the functional requirement duration corresponding to the target slave node. When the historical maintenance duration corresponding to the target slave node is less than the duration threshold, the master node determines that the network maintenance message currently initiated by the target slave node is valid; When the historical maintenance duration corresponding to the target slave node is greater than or equal to the duration threshold, the master node determines that the network maintenance message currently initiated by the target slave node is invalid.
5. The method of claim 1, wherein, The master node manages the vehicular network based on the network management message currently initiated by the target slave node, including: When the target node initiates a network management message that is a wake-up message, the master node controls the vehicle network to enter the wake-up state. When the target node initiates a network management message that is a network maintenance message, the master node controls the vehicle network to maintain a wake-up state.
6. The method of claim 1, wherein, The method further includes: When none of the nodes in the vehicle network are currently initiating network management messages, or when all currently initiated network management messages are invalid, the master node controls the vehicle network to enter a sleep state.
7. The method of claim 1, wherein, The method further includes: When the network management messages initiated by the target slave node in the past are valid, the master node performs a counting process on the network management messages initiated by the target slave node in the past.
8. The method of claim 1, wherein, After determining whether the network management message currently initiated by the target node is valid, the method further includes: When the target node's current network management message is invalid, the master node performs at least one of the following actions: Alarm processing is performed from the node according to the target; Power off the target node.
9. The method of claim 8, wherein, After powering down the target slave node, the method further includes: When the usage conditions of the vehicle network are met, the master node restores power to the target slave node.
10. The method of claim 1, wherein, The method further includes: When the usage conditions of the vehicle network are met, the master node clears the number of network management messages historically initiated by all nodes in the vehicle network to zero.
11. The method of claim 1, wherein, The method further includes: When the master node initiates a network management message, the master node manages the vehicle network according to the network management message initiated by the master node.
12. An in-vehicle network management apparatus characterized by comprising: An apparatus for use in a distributed vehicular network, wherein multiple nodes in the vehicular network include a master node and at least one slave node, wherein the master node is configured to manage the vehicular network; the apparatus includes: A receiving module is used by the master node to receive network management messages currently initiated by the target slave node; wherein the target slave node refers to any one of the at least one slave node; The judgment module is used by the master node to determine whether the network management message currently initiated by the target slave node is valid based on the number of network management messages historically initiated by the target slave node. The management module is used to manage the vehicular network according to the network management message currently initiated by the target slave node when the target slave node is valid.
13. A vehicle characterized by comprising: include: Memory, used to store executable instructions; A processor, when executing executable instructions stored in the memory, implements the method according to any one of claims 1 to 11.
14. A computer-readable storage medium, characterized in that, It stores executable instructions for implementing the method of any one of claims 1 to 11 when executed by a processor.
15. A computer program product, characterised in that, Includes executable instructions, which, when executed by a processor, implement the method of any one of claims 1 to 11.