CN115474227B - Abnormality detection method and device and vehicle - Google Patents
Abnormality detection method and device and vehicle Download PDFInfo
- Publication number
- CN115474227B CN115474227B CN202210964182.9A CN202210964182A CN115474227B CN 115474227 B CN115474227 B CN 115474227B CN 202210964182 A CN202210964182 A CN 202210964182A CN 115474227 B CN115474227 B CN 115474227B
- Authority
- CN
- China
- Prior art keywords
- network
- node
- vehicle
- state
- sub
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000001514 detection method Methods 0.000 title claims abstract description 40
- 230000005856 abnormality Effects 0.000 title claims abstract description 38
- 238000000034 method Methods 0.000 claims abstract description 32
- 230000002159 abnormal effect Effects 0.000 claims abstract description 27
- 230000006870 function Effects 0.000 claims description 39
- 230000005059 dormancy Effects 0.000 claims description 20
- 230000007958 sleep Effects 0.000 claims description 19
- 230000004044 response Effects 0.000 claims description 6
- 238000012545 processing Methods 0.000 abstract description 17
- 238000010586 diagram Methods 0.000 description 8
- 101000667209 Homo sapiens Vacuolar protein sorting-associated protein 72 homolog Proteins 0.000 description 3
- 101150102320 SWC3 gene Proteins 0.000 description 3
- 101100478997 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) SWC3 gene Proteins 0.000 description 3
- 102100039098 Vacuolar protein sorting-associated protein 72 homolog Human genes 0.000 description 3
- 238000013459 approach Methods 0.000 description 2
- 238000004891 communication Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000005611 electricity Effects 0.000 description 1
- 238000005265 energy consumption Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000011835 investigation Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000009877 rendering Methods 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W24/00—Supervisory, monitoring or testing arrangements
- H04W24/08—Testing, supervising or monitoring using real traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0677—Localisation of faults
Abstract
The embodiment of the application discloses an abnormality detection method and device and a vehicle. The method comprises the following steps: acquiring network request variables corresponding to a plurality of network sub-nodes of the vehicle under the condition that the vehicle is in an unused state; obtaining a target network sub-node based on network request variables corresponding to the network sub-nodes respectively; and carrying out exception handling on the vehicle based on the network request variable of the target network child node. By the method, when the vehicle is in the unused state, network request variables corresponding to the network sub-nodes of the vehicle can be obtained, and the target network sub-node, namely the abnormal node, is obtained based on the network request variables corresponding to the network sub-nodes, so that the accurate positioning of the abnormal network sub-node can be realized, the accuracy of abnormality detection can be improved, and the vehicle can rapidly perform abnormality processing on the abnormal network sub-node.
Description
Technical Field
The present application relates to the field of automotive technologies, and in particular, to an anomaly detection method and apparatus, and a vehicle.
Background
With the development of science and technology, more network nodes of vehicles are increased, various problems caused by network abnormality of vehicles are also increased frequently, and abnormality detection on the network nodes of vehicles begins to become a research hotspot. Vehicles are generally managed by adopting a standard AUTOSAR (Automotive Open Systems Architecture, automobile open system architecture) network, and in a related mode, standard network management messages can be collected to detect whether network nodes are abnormal. However, the related method has the problem of lower detection accuracy, such as a certain difficulty in acquiring sporadic or instantaneous fault data, lower acquired data accuracy, and the like.
Disclosure of Invention
In view of the above, the present application proposes an abnormality detection method, apparatus, and vehicle to achieve improvement of the above problems.
In a first aspect, the present application provides an anomaly detection method, the method comprising: acquiring network request variables corresponding to a plurality of network sub-nodes of a vehicle when the vehicle is in an unused state, wherein the network request variables represent whether the corresponding network sub-nodes are in an awake state or not; obtaining a target network sub-node based on network request variables corresponding to the network sub-nodes, wherein the target network sub-node is an abnormally awakened network sub-node; and carrying out exception handling on the vehicle based on the network request variable of the target network child node.
In a second aspect, the present application provides an abnormality detection apparatus, the apparatus including: a network request variable obtaining unit, configured to obtain, when a vehicle is in an unused state, network request variables corresponding to a plurality of network sub-nodes of the vehicle, where the network request variables represent whether the corresponding network sub-nodes are in an awake state; a target network sub-node obtaining unit, configured to obtain a target network sub-node based on network request variables corresponding to the plurality of network sub-nodes, where the target network sub-node is an abnormally awakened network sub-node; and the exception handling unit is used for carrying out exception handling on the vehicle based on the network request variable of the target network sub-node.
In a third aspect, the present application provides a vehicle comprising a plurality of network nodes; one or more programs stored in any of the plurality of network nodes, the one or more programs configured to perform the method of claim.
In a fourth aspect, the present application provides a vehicle comprising a processor and a memory; one or more programs are stored in the memory and configured to be executed by the processor, the one or more programs configured to perform the methods described above.
In a fifth aspect, the present application provides a computer readable storage medium having program code stored therein, wherein the method described above is performed when the program code is run.
According to the anomaly detection method, the anomaly detection device, the vehicle and the storage medium, when the vehicle is in an unused state, network request variables representing whether the corresponding network sub-node is in an awake state or not corresponding to each of a plurality of network sub-nodes of the vehicle are obtained, an abnormally-awakened target network sub-node is obtained based on the network request variables corresponding to each of the plurality of network sub-nodes, and anomaly processing is carried out on the vehicle based on the network request variables of the target network sub-node. By the method, when the vehicle is in the unused state, network request variables corresponding to the network sub-nodes of the vehicle can be obtained, and the target network sub-node, namely the abnormal node, is obtained based on the network request variables corresponding to the network sub-nodes, so that the accurate positioning of the abnormal network sub-node can be realized, the accuracy of abnormality detection can be improved, and the vehicle can rapidly perform abnormality processing on the abnormal network sub-node.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the description of the embodiments will be briefly introduced below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a schematic diagram of a network architecture of a vehicle as set forth in the present application;
FIG. 2 is a schematic diagram of a network sub-node structure of a vehicle according to the present application;
FIG. 3 is a flowchart of an anomaly detection method according to an embodiment of the present application;
FIG. 4 is a schematic diagram of a network child node acquiring a network request variable according to the present application;
FIG. 5 is a flowchart of an anomaly detection method according to another embodiment of the present application;
fig. 6 shows a schematic diagram of data transmission in a network sub-node according to the present application;
FIG. 7 shows a flow chart of a preferred embodiment presented herein;
fig. 8 is a block diagram showing a configuration of an abnormality detection apparatus according to an embodiment of the present application;
FIG. 9 shows a block diagram of a vehicle proposed by the present application;
FIG. 10 shows a block diagram of another vehicle proposed by the present application;
fig. 11 is a storage unit for storing or carrying program code implementing the abnormality detection method according to the embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. All other embodiments, which can be made by one of ordinary skill in the art based on the embodiments herein without making any inventive effort, are intended to be within the scope of the present application.
In an embodiment of the present application, the present inventors provide an anomaly detection method, an anomaly detection device, and a vehicle, where when the vehicle is in an unused state, network request variables corresponding to a plurality of network sub-nodes of the vehicle and representing whether the corresponding network sub-nodes are in an awake state are obtained, and based on the network request variables corresponding to the plurality of network sub-nodes, an anomaly-awakened target network sub-node is obtained, and based on the network request variables of the target network sub-node, anomaly processing is performed on the vehicle. By the method, when the vehicle is in the unused state, network request variables corresponding to the network sub-nodes of the vehicle can be obtained, and the target network sub-node, namely the abnormal node, is obtained based on the network request variables corresponding to the network sub-nodes, so that the accurate positioning of the abnormal network sub-node can be realized, the accuracy of abnormality detection can be improved, and the vehicle can rapidly perform abnormality processing on the abnormal network sub-node.
In order to better understand the schemes of the embodiments of the present application, the technical terms used in the embodiments of the present application are explained below.
AUTOSAR network management: one network management policy by default may be referred to as the AUTOSAR software architecture. The AUTOSAR network management may be a distributed direct network management, and each node may independently control its own network state according to the state of the network management frame.
Sleep state (Standby): the method can be that after the engine is in a flameout state for a period of time, the whole vehicle automatically enters a state with very small electricity consumption, so that the method is also called as a low-energy consumption mode.
In order to better understand the solution of the embodiment of the present application, the following describes the network structure of the vehicle of the present application.
Referring to fig. 1, a line and a plurality of network nodes may be included in a network structure of a vehicle, and the plurality of network nodes may include a network main node and a plurality of network sub-nodes, and each network node may be an ECU (Electronic Control Unit ) network node.
The network master node may have a data acquisition master module, and the data acquisition master module may be used to acquire data of other network child nodes.
As shown in fig. 2, the network sub-node may include a plurality of functional modules, a network anomaly data acquisition module, and a network management module. Wherein each functional module can implement a specific function, and a plurality of functional modules can be divided into network-related functional modules and network-independent functional modules according to whether or not a network is required.
The network abnormal data acquisition module can be used for acquiring the data of all the function modules related to the network in the network sub-nodes, and analyzing and judging whether the acquired data are abnormal data. The network anomaly data acquisition module may also generate corresponding instructions based on the acquired data that may be used to confirm which network-related functional modules are allowed to acquire the network.
The network management module may be configured to obtain data of all network related function modules in the network sub-node and obtain an instruction of the network abnormal data acquisition module, and control the network of the network sub-node based on the obtained data and the instruction.
It should be noted that the number of nodes shown in fig. 1 is merely exemplary, and the number of nodes included in the network of the vehicle may be greater or lesser. The number of functional modules shown in fig. 2 is only exemplary, and the number of functional modules included in the network sub-node may be greater or lesser.
In addition, for simplicity of description, the functional modules according to the embodiments of the present application refer to functional modules related to a network.
Embodiments of the present application will now be described with reference to the accompanying drawings.
Referring to fig. 3, the method for detecting an abnormality provided in the present application includes:
s110: and under the condition that the vehicle is in an unused state, acquiring network request variables corresponding to a plurality of network sub-nodes of the vehicle, wherein the network request variables represent whether the corresponding network sub-nodes are in an awake state or not.
Each network sub-node may include a plurality of functional modules, the network request variable may refer to a variable that characterizes a state of a functional module in the corresponding network sub-node, the network request variable may include a plurality of network request flags corresponding to the plurality of functional modules one to one, and the plurality of network request flags may characterize whether the respective corresponding functional module is in a wake state. The network request flag may be a boolean value, and when the network request flag is 0, it may indicate that the corresponding functional module does not currently use the network, that is, the functional module is in a dormant state; when the network request flag is 1, it may indicate that the corresponding functional module currently has a need to use the network, that is, the functional module is in an awake state.
Illustratively, as shown in table 1, the network request variable may be denoted as RequstNetworkFlag, requstNetworkFlag and may have a plurality of bits (Bit), one Bit may represent a network request flag of a corresponding functional module, and the network request flag may be denoted as swcx_requst network flag, where x is an integer and may identify the functional module.
TABLE 1
| Functional module | Functional module network request sign | RequstNetworkFlag |
| SWC0 | SWC0_RequstNetworkFlag | Bit0 |
| SWC1 | SWC1_RequstNetworkFlag | Bit1 |
| SWC2 | SWC2_RequstNetworkFlag | Bit2 |
| SWC3 | SWC3_RequstNetworkFlag | Bit3 |
| ... | ... | ... |
| SWCn | SWCn_RequstNetworkFlag | Bitn |
As a way, in the case that the vehicle is in an unused state, as shown in fig. 4, the plurality of functional modules of each network sub-node may send respective corresponding network request flags to the network anomaly data acquisition modules of the corresponding network sub-nodes, so that the network anomaly data acquisition modules of each network sub-node may obtain the network request variables of the corresponding network sub-nodes, thereby obtaining the network request variables corresponding to the plurality of network sub-nodes of the vehicle.
Optionally, after each network sub-node obtains the corresponding network request variable, the network request variable may also be sent to a designated network node, where the network node may be any network sub-node or a network master node, so as to obtain the network request variable corresponding to each of the plurality of network sub-nodes of the vehicle.
As another mode, when a vehicle is in an unused state and all of a plurality of network sub-nodes of the vehicle are in a dormant state, network request variables corresponding to the plurality of network sub-nodes of the vehicle are acquired.
In the embodiment of the application, the unused state of the vehicle may refer to a state in which the vehicle is in when the user does not have a vehicle intention.
Alternatively, the running state of the vehicle and the distance between the user and the vehicle can be obtained; if the running state of the vehicle is dormant (Standby) and the user leaves the vehicle, the vehicle is confirmed to be in an unused state.
Optionally, when the vehicle is in an unused state, it may be detected whether there is an abnormally non-dormant network node, and the abnormally non-dormant network node is controlled to force sleep, so that all the multiple network sub-nodes of the vehicle are in a dormant state.
In the embodiment of the application, after waiting for the second preset time, the network request variables corresponding to the network sub-nodes of the vehicle are acquired, so that more buffer time for switching states of each functional module in the vehicle can be given, the accuracy of the acquired network request variables is improved, and the accuracy of abnormality detection is further improved.
S120: and obtaining a target network sub-node based on the network request variables corresponding to the network sub-nodes, wherein the target network sub-node is an abnormally awakened network sub-node.
As a way, the function module in the wake-up state may be obtained based on the network request flags corresponding to the plurality of function modules in each network sub-node; and obtaining the target network child node based on the functional module in the wake-up state.
S130: and carrying out exception handling on the vehicle based on the network request variable of the target network child node.
As one approach, the target network sub-node may be controlled to enter a dormant state in response to a forced dormant instruction by the network master node of the vehicle.
Optionally, after the target network sub-node is obtained based on step S120, the network request variable of the target network sub-node may be sent to the network master node, so that the network master node sends a forced dormancy instruction to the target network sub-node.
Optionally, after receiving the network request variable of the target network sub-node, the network master node may further send the network request variable of the target network sub-node to the cloud, so that the cloud may locate the target network sub-node based on the network request variable of the target network sub-node, and analyze a cause of abnormal wake-up of the target network sub-node, so as to reduce a risk of vehicle power loss caused by abnormal non-dormancy of the network sub-node.
According to the anomaly detection method provided by the embodiment, when a vehicle is in an unused state, network request variables which are corresponding to a plurality of network sub-nodes of the vehicle and represent whether the corresponding network sub-nodes are in an awake state are obtained, an abnormally-awakened target network sub-node is obtained based on the network request variables corresponding to the network sub-nodes, and the vehicle is subjected to anomaly processing based on the network request variables of the target network sub-node. By the method, when the vehicle is in the unused state, network request variables corresponding to the network sub-nodes of the vehicle can be obtained, and the target network sub-node, namely the abnormal node, is obtained based on the network request variables corresponding to the network sub-nodes, so that the accurate positioning of the abnormal network sub-node can be realized, the accuracy of abnormality detection can be improved, and the vehicle can rapidly perform abnormality processing on the abnormal network sub-node.
Referring to fig. 5, the method for detecting an abnormality provided in the present application includes:
s210: and under the condition that the vehicle is in an unused state, acquiring network request variables corresponding to a plurality of network sub-nodes of the vehicle, wherein the network request variables represent whether the corresponding network sub-nodes are in an awake state or not.
S220: and obtaining the functional module in the awakening state based on the network request mark corresponding to each of the functional modules in each network sub-node.
S230: and obtaining the target network child node based on the functional module in the wake-up state.
As a way, the network sub-node corresponding to the functional module in the awake state may be directly used as the target network sub-node.
As another way, the number of wake-up times of the functional module in the wake-up state may be obtained; if the awakening times exceed the preset times, confirming that the functional module in the awakening state is an abnormally non-dormant functional module, and taking the network sub-node corresponding to the abnormally non-dormant functional module as a target network sub-node.
Optionally, as shown in table 2, each of the plurality of functional modules corresponding to each network sub-node may be respectively corresponding to a counter (connector), and the counter may be used to record the number of times that the corresponding functional module is in the awake state. The counter may record the number of times the corresponding function module is in the awake state by recording the number of times the network request flag of the corresponding function module is 1.
TABLE 2
| Functional module | Network request sign for functional module | Network request sign counter |
| SWC0 | SWC0_RequstNetworkFlag | SWC1_RequstNetworkConuter0 |
| SWC1 | SWC1_RequstNetworkFlag | SWC1_RequstNetworkConuter1 |
| SWC2 | SWC2_RequstNetworkFlag | SWC1_RequstNetworkConuter2 |
| SWC3 | SWC3_RequstNetworkFlag | SWC1_RequstNetworkConuter3 |
| ... | ... | ... |
| SWCn | SWCn_RequstNetworkFlag | SWC1_RequstNetworkConutern |
Alternatively, the running state of the vehicle may be acquired in real time; and if the vehicle is not in the sleep mode based on the running state, acquiring the wake-up times of the functional module in the wake-up state again.
As a further way, the total number of wake-up times of all the function modules in the network sub-node having the function module in the wake-up state may be obtained, and if the total number of wake-up times of the network sub-node exceeds the preset total number of times, the network sub-node is taken as the target network sub-node.
In the first mode, the network sub-node corresponding to the functional module in the wake-up state can be directly used as the target network sub-node, and the mode can rapidly detect the abnormally-wake-up network sub-node in the vehicle network. In the second mode, the network sub-node corresponding to the functional module with the awakening frequency exceeding the preset frequency is used as the target network sub-node, so that more accurate abnormality detection can be provided, the abnormal awakening functional module can be directly subjected to fault detection in the follow-up, and therefore the fault cause can be quickly found out, the fault is eliminated, and the electric quantity can be saved in the second mode. In the third mode, the network sub-node with the awakening total times exceeding the preset total times is used as the target network sub-node, so that the detection speed can be improved to a certain extent and the electric quantity can be saved.
Thus, as yet another way, the target network child node may be obtained by selecting one of the above ways based on actual requirements. When the electric quantity saving requirement of the scene where the vehicle is located is higher than other requirements, a first mode can be selected; when the accuracy requirement of the scene where the vehicle is located for anomaly detection is higher than other requirements, a second mode can be selected; the third approach may be selected when the scene in which the vehicle is located is balanced in terms of various aspects.
S240: and obtaining a target functional module based on the network request variable of the target network sub-node, wherein the target functional module is a functional module in an awakening state in the target network sub-node.
As one way, the network request flags corresponding to the plurality of functional modules of the target network sub-node may be obtained based on the network request variables of the target network sub-node, and the target functional module may be obtained based on the network request flags.
S250: and responding to the forced dormancy instruction of the network main node, and controlling the target functional module to enter a dormancy state so as to enable the target network sub-node to enter the dormancy state.
Each network sub-node may include a plurality of functional modules, each functional module may correspond to a network request validity flag, and the network request validity flag may indicate whether the corresponding functional module is allowed to be in an awake state. The network request validity flag may be a boolean value, and when the network request validity flag is 0, it may indicate that the corresponding functional module is not allowed to be in the awake state; when the network request flag is 1, it may indicate that the corresponding functional module is allowed to be in an awake state. The plurality of network request validity flags of each network sub-node may constitute a network request validity variable of a plurality of bits, one bit may represent the network request validity flag of a corresponding functional module.
Illustratively, as shown in Table 3, the network request flag validity flag for each functional module may be denoted as SWCx_Requst NetworkVaill, where x is an integer, which may identify the functional module.
TABLE 3 Table 3
| Functional module | Functional module network request sign | Network request flag validity flag |
| SWC0 | SWC0_RequstNetworkFlag | SWC0_RequstNetworkVaild |
| SWC1 | SWC1_RequstNetworkFlag | SWC1_RequstNetworkVaild |
| SWC2 | SWC2_RequstNetworkFlag | SWC2_RequstNetworkVaild |
| SWC3 | SWC3_RequstNetworkFlag | SWC3_RequstNetworkVaild |
| … | … | … |
| SWCn | SWCn_RequstNetworkFlag | SWCn_RequstNetworkVaild |
As one way, as shown in fig. 6, the network management module may respond to the forced dormancy instruction of the network master node, obtain the network request validity flag corresponding to the target function module, and control the target function module to enter the dormancy state based on the network request validity flag, so as to make the target network sub-node enter the dormancy state.
As one way, in response to the forced sleep instruction of the network master node, the network management module of the target network sub-node may control the target functional module to enter the sleep state based on the network request variable of the target network sub-node, so as to cause the target network sub-node to enter the sleep state.
In the embodiment of the application, after receiving the network request validity flag, the network management module can confirm whether the corresponding function module is allowed to be in the wake-up state, so that the situation that the whole vehicle cannot sleep due to frequent network requests of the function module after the vehicle is in the sleep state can be avoided.
According to the abnormality detection method, when the vehicle is in the unused state, network request variables corresponding to the network sub-nodes of the vehicle can be obtained, and the target network sub-node, namely the node with the abnormality, is obtained based on the network request variables corresponding to the network sub-nodes, so that the accurate positioning of the network sub-node with the abnormality can be realized, the accuracy of abnormality detection can be improved, and the vehicle can rapidly conduct abnormality processing on the network sub-node with the abnormality. In addition, in this embodiment, the network request variable of the plurality of network sub-nodes of the vehicle may be obtained, so as to obtain the network request flags corresponding to the plurality of functional modules in each network sub-node, so as to obtain the wake-up times of each functional module based on the network request flags, so that the wake-up times and the preset times may be compared, and the abnormally wake-up functional module may be obtained, further, the position where the abnormally wake-up fault occurs may be more accurately located, the time of the post fault investigation may be reduced, further, the fault cause may be more rapidly analyzed, and the fault may be timely cleared, so as to reduce the risk of vehicle power shortage.
For a better understanding of the aspects of the examples of the present application, a flow of a preferred embodiment is described below.
Referring to fig. 7, the running state of the vehicle and the distance between the user and the vehicle may be obtained based on step S1; when the vehicle is confirmed to be in the unused state based on the step S2, the step S3 may be executed to perform abnormal non-dormancy detection on the plurality of network sub-nodes of the vehicle, so that after all the plurality of network sub-nodes of the vehicle are in the sleep state, the step S4 is executed to acquire network request variables of the plurality of network sub-nodes of the vehicle and acquire the running state of the vehicle in real time; when it is confirmed that the vehicle is in the used state based on step S2, step S1 may be continued until it is confirmed that the vehicle is in the unused state based on step S2.
After step S4 is executed, and when it is determined that the vehicle is always in the sleep state based on step S5, a function module in the wake state may be obtained based on step S6, and the number of wake times of the function module in the wake state may be obtained based on step S7; if the number of wake-up times of the functional module in the wake-up state is confirmed to exceed the preset number based on the step S8, the steps S9 and S11 may be sequentially executed; if the number of wake-up times of the functional module in the wake-up state is not greater than the preset number of wake-up times based on the step S8, the step S10 may be executed. If it is confirmed that the vehicle is switched from the sleep state to the other state based on step S5, step S1 may be re-executed until it is confirmed that the vehicle is in the unused state based on step S2.
Referring to fig. 8, an abnormality detection apparatus 600 provided in the present application, the apparatus 600 includes:
the network request variable obtaining unit 610 is configured to obtain, when the vehicle is in an unused state, network request variables corresponding to a plurality of network sub-nodes of the vehicle, where the network request variables characterize whether the corresponding network sub-nodes are in an awake state.
The target network sub-node obtaining unit 620 is configured to obtain a target network sub-node based on the network request variables corresponding to the plurality of network sub-nodes, where the target network sub-node is an abnormally awakened network sub-node.
An exception handling unit 630, configured to perform exception handling on the vehicle based on the network request variable of the target network child node.
As one way, the network request variable obtaining unit 610 is specifically configured to obtain, when a vehicle is in an unused state and all of a plurality of network sub-nodes of the vehicle are in a dormant state, network request variables corresponding to the plurality of network sub-nodes of the vehicle.
As one way, the network request variable obtaining unit 610 is specifically configured to obtain an operation state of the vehicle, a distance between a user and the vehicle; and if the running state is dormant and the user leaves the vehicle, confirming that the vehicle is in an unused state.
As a way, each of the network sub-nodes includes a plurality of function modules, each of the network request variables includes a plurality of network request flags corresponding to the plurality of function modules one by one, the plurality of network request flags characterize whether the respective corresponding function module is in an awake state, and the target network sub-node obtaining unit 620 is specifically configured to obtain the function module in the awake state based on the respective corresponding network request flag of the plurality of function modules in each of the network sub-nodes; and obtaining the target network child node based on the functional module in the wake-up state.
The target network sub-node obtaining unit 620 is specifically configured to obtain the wake-up times of the functional module in the wake-up state; and if the awakening times exceed the preset times, confirming that the functional module in the awakening state is an abnormal non-dormant functional module, and taking a network sub-node corresponding to the abnormal non-dormant functional module as a target network sub-node.
As another way, the target network sub-node obtaining unit 620 is specifically configured to take, as the target network sub-node, the network sub-node corresponding to the functional module in the awake state.
As one way, the exception handling unit 630 is specifically configured to control the target network sub-node to enter a sleep state in response to a forced sleep instruction of the network master node of the vehicle.
Wherein, optionally, the exception processing unit 630 is specifically configured to obtain a target functional module based on a network request variable of the target network sub-node, where the target functional module is a functional module in an awake state in the target network sub-node; and responding to the forced dormancy instruction of the network main node, and controlling the target functional module to enter a dormancy state so as to enable the target network sub-node to enter the dormancy state.
Optionally, each network sub-node includes a plurality of functional modules, each functional module corresponds to a network request validity flag, where the network request validity flag indicates whether the corresponding functional module is allowed to be in an awake state, and the exception handling unit 630 is specifically configured to obtain, in response to a forced sleep instruction of the network master node, the network request validity flag corresponding to the target functional module, and control, based on the network request validity flag, the target functional module to enter a sleep state, so that the target network sub-node enters the sleep state.
A vehicle provided in the present application will be described with reference to fig. 9.
Referring to fig. 9, based on the foregoing abnormality detection method and apparatus, another vehicle 100 capable of executing the foregoing abnormality detection method is further provided in the embodiments of the present application. Vehicle 100 includes a plurality of network nodes, which may include a network master node 102 and network child nodes 104, and network child nodes 104 may refer to a plurality of network child nodes. A program that can be stored in any one of the plurality of network nodes to perform the contents of the foregoing embodiments is stored in any one of the plurality of network nodes.
A vehicle provided in the present application will be described with reference to fig. 10.
Referring to fig. 10, based on the foregoing abnormality detection method and apparatus, another vehicle 200 capable of executing the foregoing abnormality detection method is further provided in the embodiments of the present application. The vehicle 200 includes one or more (only one shown) processors 202, memory 204 coupled to one another. The memory 204 stores therein a program capable of executing the contents of the foregoing embodiments, and the processor 202 can execute the program stored in the memory 204.
Wherein the processor 202 may include one or more processing cores. The processor 202 utilizes various interfaces and lines to connect various portions of the overall vehicle 200, perform various functions of the electronic device 100 and process data by executing or executing instructions, programs, code sets, or instruction sets stored in the memory 204, and invoking data stored in the memory 204. Alternatively, the processor 202 may be implemented in hardware in at least one of digital signal processing (Digital Signal Processing, DSP), field programmable gate array (Field-Programmable Gate Array, FPGA), programmable logic array (Programmable Logic Array, PLA). The processor 202 may integrate one or a combination of several of a central processing unit (Central Processing Unit, CPU), an image processor (Graphics Processing Unit, GPU), and a modem, etc. The CPU mainly processes an operating system, a user interface, an application program and the like; the GPU is used for being responsible for rendering and drawing of display content; the modem is used to handle wireless communications. It will be appreciated that the modem may not be integrated into the processor 202 and may be implemented solely by a single communication chip.
The Memory 204 may include a random access Memory (Random Access Memory, RAM) or a Read-Only Memory (Read-Only Memory). Memory 204 may be used to store instructions, programs, code sets, or instruction sets. The memory 204 may include a stored program area and a stored data area, wherein the stored program area may store instructions for implementing an operating system, instructions for implementing at least one function (e.g., a touch function, a sound playing function, an image playing function, etc.), instructions for implementing the various method embodiments described below, etc. The storage data area may also store data created by the terminal 200 in use (such as phonebook, audio-video data, chat-record data), etc.
Referring to fig. 11, a block diagram of a computer readable storage medium according to an embodiment of the present application is shown. The computer readable storage medium 800 has stored therein program code that can be invoked by a processor to perform the methods described in the method embodiments described above.
The computer readable storage medium 800 may be an electronic memory such as a flash memory, an EEPROM (electrically erasable programmable read only memory), an EPROM, a hard disk, or a ROM. Optionally, the computer readable storage medium 800 comprises a non-volatile computer readable storage medium (non-transitory computer-readable storage medium). The computer readable storage medium 800 has storage space for program code 810 that performs any of the method steps described above. The program code can be read from or written to one or more computer program products. Program code 810 may be compressed, for example, in a suitable form.
In summary, in the case that the vehicle is in an unused state, the abnormality detection method, the abnormality detection device and the vehicle provided by the application acquire network request variables representing whether the corresponding network sub-node is in an awake state, which correspond to each of a plurality of network sub-nodes of the vehicle, and obtain an abnormally-awakened target network sub-node based on the network request variables corresponding to each of the plurality of network sub-nodes, and perform abnormality processing on the vehicle based on the network request variables of the target network sub-node. By the method, when the vehicle is in the unused state, network request variables corresponding to the network sub-nodes of the vehicle can be obtained, and the target network sub-node, namely the abnormal node, is obtained based on the network request variables corresponding to the network sub-nodes, so that the accurate positioning of the abnormal network sub-node can be realized, the accuracy of abnormality detection can be improved, and the vehicle can rapidly perform abnormality processing on the abnormal network sub-node.
Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present application, and are not limiting thereof; although the present application has been described in detail with reference to the foregoing embodiments, one of ordinary skill in the art will appreciate that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not drive the essence of the corresponding technical solutions to depart from the spirit and scope of the technical solutions of the embodiments of the present application.
Claims (12)
1. An anomaly detection method, the method comprising:
under the condition that a vehicle is in an unused state, acquiring network request variables corresponding to a plurality of network sub-nodes of the vehicle, wherein the network request variables represent whether the corresponding network sub-nodes are in an awake state, each network sub-node comprises a plurality of functional modules, each network request variable comprises a plurality of network request marks corresponding to the functional modules one by one, the network request marks represent whether the corresponding functional modules are in the awake state, and the unused state is a state when a user does not use the vehicle;
obtaining a function module in an awakening state based on network request marks corresponding to a plurality of function modules in each network sub-node;
obtaining a target network sub-node based on the functional module in the awakening state, wherein the target network sub-node is an abnormally awakened network sub-node;
and carrying out exception handling on the vehicle based on the network request variable of the target network child node.
2. The method of claim 1, wherein the obtaining the target network child node based on the functional module in the awake state comprises:
acquiring the awakening times of the functional module in the awakening state;
and if the awakening times exceed the preset times, confirming that the functional module in the awakening state is an abnormal non-dormant functional module, and taking a network sub-node corresponding to the abnormal non-dormant functional module as a target network sub-node.
3. The method of claim 1, wherein the obtaining the target network child node based on the functional module in the awake state comprises:
and taking the network sub-node corresponding to the functional module in the awakening state as a target network sub-node.
4. The method of claim 1, wherein the obtaining network request variables corresponding to each of a plurality of network child nodes of the vehicle when the vehicle is in an unused state comprises:
and under the condition that the vehicle is in an unused state and all the plurality of network sub-nodes of the vehicle are in a dormant state, acquiring network request variables corresponding to the plurality of network sub-nodes of the vehicle.
5. The method of claim 1, wherein the exception handling of the vehicle based on the network request variable of the target network child node comprises:
and responding to the forced dormancy instruction of the network main node, and controlling the target network sub-node to enter a dormancy state.
6. The method of claim 5, wherein controlling the target network child node to enter a dormant state in response to the forced dormant instruction of the network master node comprises:
obtaining a target functional module based on a network request variable of the target network sub-node, wherein the target functional module is a functional module in an awakening state in the target network sub-node;
and responding to the forced dormancy instruction of the network main node, and controlling the target functional module to enter a dormancy state so as to enable the target network sub-node to enter the dormancy state.
7. The method of claim 6, wherein each of the network sub-nodes includes a plurality of function modules, each of the function modules having a network request validity flag, the network request validity flag indicating whether the corresponding function module is permitted to be in an awake state, wherein controlling the target function module to enter a sleep state in response to the forced sleep instruction of the network master node to cause the target network sub-node to enter the sleep state comprises:
and responding to the forced dormancy instruction of the network master node, acquiring a network request validity mark corresponding to the target function module, and controlling the target function module to enter a dormancy state based on the network request validity mark so as to enable the target network sub-node to enter the dormancy state.
8. The method according to any one of claims 1 to 7, wherein before acquiring the network request variables corresponding to each of the plurality of network child nodes of the vehicle in a case where the vehicle is in an unused state, further comprises:
acquiring the running state of the vehicle and the distance between a user and the vehicle;
and if the running state is dormant and the user leaves the vehicle, confirming that the vehicle is in an unused state.
9. An abnormality detection apparatus, characterized by comprising:
a network request variable obtaining unit, configured to obtain, when a vehicle is in an unused state, network request variables corresponding to a plurality of network sub-nodes of the vehicle, where the network request variables represent whether the corresponding network sub-nodes are in an awake state, each network sub-node includes a plurality of function modules, each network request variable includes a plurality of network request flags corresponding to the plurality of function modules one to one, the plurality of network request flags represent whether the corresponding function modules are in the awake state, and the unused state is a state when a user does not use the vehicle;
a target network sub-node obtaining unit, configured to obtain a function module in an awake state based on network request flags corresponding to a plurality of function modules in each network sub-node, and obtain a target network sub-node based on the function module in the awake state, where the target network sub-node is an abnormally awake network sub-node;
and the exception handling unit is used for carrying out exception handling on the vehicle based on the network request variable of the target network sub-node.
10. A vehicle comprising a plurality of network nodes;
one or more programs stored in any one of the plurality of network nodes, the one or more programs configured to perform the method of any one of claims 1-8.
11. A vehicle comprising a processor and a memory;
one or more programs stored in the memory and configured to be executed by the processor, the one or more programs configured to perform the method of any of claims 1-8.
12. A computer readable storage medium, characterized in that the computer readable storage medium has stored therein a program code, wherein the method of any of claims 1-8 is performed when the program code is run.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210964182.9A CN115474227B (en) | 2022-08-11 | 2022-08-11 | Abnormality detection method and device and vehicle |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210964182.9A CN115474227B (en) | 2022-08-11 | 2022-08-11 | Abnormality detection method and device and vehicle |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115474227A CN115474227A (en) | 2022-12-13 |
| CN115474227B true CN115474227B (en) | 2024-01-12 |
Family
ID=84368145
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210964182.9A Active CN115474227B (en) | 2022-08-11 | 2022-08-11 | Abnormality detection method and device and vehicle |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115474227B (en) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112436977A (en) * | 2020-10-15 | 2021-03-02 | 东风汽车集团有限公司 | Controller dormancy judgment method and device based on OSEK network management |
| CN112491671A (en) * | 2019-09-11 | 2021-03-12 | 广州汽车集团股份有限公司 | Method and system for monitoring whole vehicle feed problem and vehicle CAN network gateway |
| CN112558590A (en) * | 2020-12-08 | 2021-03-26 | 广州橙行智动汽车科技有限公司 | Network management abnormity monitoring method, system, vehicle and readable storage medium |
| CN113691396A (en) * | 2021-08-09 | 2021-11-23 | 浙江吉利控股集团有限公司 | Whole vehicle network abnormal dormancy awakening monitoring method and device and storage medium |
-
2022
- 2022-08-11 CN CN202210964182.9A patent/CN115474227B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112491671A (en) * | 2019-09-11 | 2021-03-12 | 广州汽车集团股份有限公司 | Method and system for monitoring whole vehicle feed problem and vehicle CAN network gateway |
| CN112436977A (en) * | 2020-10-15 | 2021-03-02 | 东风汽车集团有限公司 | Controller dormancy judgment method and device based on OSEK network management |
| CN112558590A (en) * | 2020-12-08 | 2021-03-26 | 广州橙行智动汽车科技有限公司 | Network management abnormity monitoring method, system, vehicle and readable storage medium |
| CN113691396A (en) * | 2021-08-09 | 2021-11-23 | 浙江吉利控股集团有限公司 | Whole vehicle network abnormal dormancy awakening monitoring method and device and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115474227A (en) | 2022-12-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112241164B (en) | Automobile network dormancy testing method, device, equipment and storage medium | |
| WO2019205017A1 (en) | Method, system, device, and computer readable storage medium for diagnosing vehicle | |
| CN108665239B (en) | Workflow processing method, workflow processing device, computer equipment and storage medium | |
| CN111091813B (en) | Voice wakeup model updating and wakeup method, system, device, equipment and medium | |
| CN112269371B (en) | Vehicle network dormancy abnormal event monitoring method | |
| CN111475213B (en) | Power consumption reduction method and device for solid state disk with multi-core structure and computer equipment | |
| CN108806679B (en) | Voice wake-up method and device | |
| CN112148538A (en) | Complete vehicle fault identification method, device and system, vehicle and computer readable storage medium | |
| CN115396860A (en) | NFC chip intelligent regulation method, device, equipment and storage medium | |
| CN115474227B (en) | Abnormality detection method and device and vehicle | |
| CN113326191A (en) | Current consumption testing method and device and storage medium | |
| CN108962235B (en) | Voice interaction method and device | |
| CN111953569B (en) | State information reporting method, device, equipment and medium | |
| CN115474226B (en) | Abnormality detection method and device and vehicle | |
| CN109932972B (en) | Control method and device for whole vehicle electronic controller | |
| US8738939B2 (en) | System and method for testing WOL function of computers | |
| CN112929194A (en) | Vehicle information processing method and system and computer readable medium | |
| CN115416596A (en) | Vehicle wake-up method, vehicle wake-up device, vehicle and storage medium | |
| CN114328080A (en) | Firmware state detection method and device and electronic equipment | |
| CN110099132B (en) | Data synchronization method, device, system, equipment and storage medium | |
| CN113923695A (en) | Awakening fault detection method and device and message sending method and device | |
| CN116600262B (en) | Method and device for determining sleep wakeup abnormality, electronic equipment and storage medium | |
| CN113129464B (en) | Office equipment automatic control method, office equipment automatic control device, office equipment automatic control server and storage medium | |
| CN111078714B (en) | Data processing method and device | |
| CN117609881B (en) | Metal overlap detection method and system based on artificial intelligence |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |