Network node anomaly monitoring method and device, vehicle, equipment and medium

Abstract

The invention provides an abnormity monitoring method and device of a network node, a vehicle, equipment and a medium, and relates to the technical field of vehicles, the method utilizes hardware-based non-maskable interruption to trigger communication abnormity monitoring of a local node in a timed manner, and the monitoring process is prevented from losing efficacy when the conditions of jamming, blocking and the like occur on a software system level. When communication abnormity is monitored, channel state information and program operation state information are obtained from a hardware register, the information, whole vehicle network state information and a timestamp determined based on a hardware clock are recorded in communication abnormity information, and the recorded information is sent to a network abnormity processing device after communication is recovered. Multi-dimensional exception information of a hardware level and a software level is provided for a network exception handling device, and data guarantee is provided for rapid positioning of problem nodes and exception investigation of the software level. According to the method, independent monitoring which is not limited by a whole vehicle network state and not influenced by a program running state of a software system level is realized on nodes.

Description

Technical Field

[0001] The present application relates to the field of vehicle technology, and in particular to a method, device, vehicle, equipment and medium for monitoring abnormalities of network nodes. Background Art

[0002] The battery of the vehicle can provide power for on-board electrical equipment and engine starting. As the technical functions of the vehicle are iterated, the number of nodes in the electronic processing unit ECU also increases. When the vehicle is powered off, the battery power is consumed too quickly and cannot be started because one or several nodes cannot sleep or have abnormal wake-up problems. At the same time, as the number of ECU nodes increases and the network works normally, it is difficult to troubleshoot problems such as abnormal disconnection and blockage of nodes. In addition, the troubleshooting of problems is sporadic, which makes it inconvenient to troubleshoot and analyze the problems, and after-sales maintenance personnel cannot quickly locate the problem nodes.

[0003] The existing method is to record the non-sleep time of the node or the number of node wake-up times to count whether there is an abnormality in the node; or to collect the battery voltage, and when the battery voltage reaches the feeding threshold, record and upload the node information; or to monitor the network status and upload the node information;

[0004] The data upload and node recording of the existing methods are all performed after the power supply is triggered. It is impossible to obtain the data information before the power supply, and the uploaded data information is limited, and it is impossible to further locate the problem node; at present, the abnormal monitoring strategy and information upload are all performed when the node itself can work normally, the network can work normally, and the software program can be executed normally. It cannot cover the monitoring of software problems such as software freezing, process deadlock, network congestion, etc. Summary of the invention

[0005] Based on this, it is necessary to provide a network node abnormality monitoring method, device, vehicle, electronic device and storage medium to address the above-mentioned technical problems, so as to achieve independent monitoring of node abnormalities, record multi-dimensional abnormal information, and provide guarantees for the rapid positioning of problem nodes and software-level abnormality troubleshooting.

[0006] A method for monitoring abnormalities of network nodes, comprising: regularly triggering communication abnormality monitoring of a local node in a non-maskable interrupt based on hardware implementation; if communication abnormality is detected in the local node, recording communication abnormality information, the communication abnormality information including channel status information, vehicle network status information, program running information on the local node and a current timestamp; if normal communication is detected in the local node, sending the recorded abnormality information to a network abnormality processing device, the recorded abnormality information including the communication abnormality information.

[0007] In an embodiment of the present application, communication anomalies of the local node are monitored in the following manner: determine whether the communication interruption count of the local node on each communication link is updated, and record the number of updates of each communication interruption count within a first preset time period; determine whether there is a link with a zero update number, and if so, determine that there is a communication anomaly in the local node; wherein the first preset time period when the entire vehicle network is in a dormant state is greater than the first preset time period when the entire vehicle network is in an operating state.

[0008] In an embodiment of the present application, the recorded exception information also includes reset exception information, and the method also includes: after the local node is powered on, monitoring whether the reset operation of the local node is an operation triggered by a reset request; if not, determining that a reset exception exists in the local node, and recording the reset exception information.

[0009] In an embodiment of the present application, the monitoring of whether the reset operation of the local node is an operation triggered by a reset request includes: obtaining a current timestamp and a timestamp of a reset request most recently received by the local node; if the current timestamp is greater than the timestamp of the most recent reset request, and the difference between the current timestamp and the timestamp of the most recent reset request is greater than a second preset time length, confirming that the reset operation is not an operation triggered by a reset request; the reset exception information includes the current timestamp, the type of the most recently received reset request, the timestamp of the most recently received reset request, and the reset reason obtained from the reset register.

[0010] In an embodiment of the present application, the recorded exception information also includes wake-up exception information, and the method also includes: after the local node is awakened from hibernation, determining whether the wake-up reason of the local node is power-on wake-up, and if not, increasing the number of non-power-on wake-up times by one; if the wake-up reason of the local node is network wake-up, clearing the number of non-power-on wake-up times to zero; if the number of non-power-on wake-up times exceeds a preset threshold, confirming that there is a wake-up exception in the local node, and recording the wake-up exception information, wherein the wake-up exception information includes the current timestamp, the wake-up reason obtained from the wake-up register, and the reset reason obtained from the reset register.

[0011] In an embodiment of the present application, the channel status information includes an abnormal channel mask, an abnormal channel status mask, and current channel status register information; the vehicle network status information includes whether the vehicle network is currently in a sleep state or whether the vehicle network is currently in a running state; the running information of the program on the local node includes the current program counter pointer value, the current R group register information, and the current stack pointer register information.

[0012] A network node abnormality monitoring device comprises: an abnormality monitoring module, which is used to periodically trigger communication abnormality monitoring of a local node in a non-maskable interrupt based on hardware implementation; an information recording module, which is used to record communication abnormality information if a communication abnormality is detected in the local node, the communication abnormality information including channel status information, vehicle network status information, program running information on the local node and a current timestamp; a sending module, which is used to send the recorded abnormality information to a network abnormality processing device if the local node is detected to have restored normal communication, the recorded abnormality information including the communication abnormality information.

[0013] In an embodiment of the present application, communication anomalies of the local node are monitored in the following manner: determine whether the communication interruption count of the local node on each communication link is updated, and record the number of updates of each communication interruption count within a first preset time period; determine whether there is a link with a zero update number, and if so, determine that there is a communication anomaly in the local node; wherein the first preset time period when the entire vehicle network is in a dormant state is greater than the first preset time period when the entire vehicle network is in an operating state.

[0014] In an embodiment of the present application, the recorded exception information also includes reset exception information, and the device is also used to: after the local node is powered on, monitor whether the reset operation of the local node is an operation triggered by a reset request; if not, determine that there is a reset exception in the local node, and record the reset exception information.

[0015] In an embodiment of the present application, the device is also used to: obtain a current timestamp and a timestamp of a reset request most recently received by the local node; if the current timestamp is greater than the timestamp of the most recent reset request, and the difference between the current timestamp and the timestamp of the most recent reset request is greater than a second preset time length, confirming that the reset operation is not an operation triggered by a reset request; the reset exception information includes the current timestamp, the type of reset request most recently received, the timestamp of the most recently received reset request, and the reset reason obtained from the reset register.

[0016] In an embodiment of the present application, the recorded exception information also includes wake-up exception information, and the device is also used to: after the local node is awakened from hibernation, determine whether the wake-up reason of the local node is power-on wake-up, if not, increase the number of non-power-on wake-up times by one; if the wake-up reason of the local node is network wake-up, clear the number of non-power-on wake-up times to zero; if the number of non-power-on wake-up times exceeds a preset threshold, confirm that there is a wake-up exception in the local node, and record the wake-up exception information, wherein the wake-up exception information includes the current timestamp, the wake-up reason obtained from the wake-up register, and the reset reason obtained from the reset register.

[0017] In an embodiment of the present application, the channel status information includes an abnormal channel mask, an abnormal channel status mask, and current channel status register information; the vehicle network status information includes whether the vehicle network is currently in a sleep state or whether the vehicle network is currently in a running state; the running information of the program on the local node includes the current program counter pointer value, the current R group register information, and the current stack pointer register information.

[0018] A vehicle comprises an electronic processing unit at a network node of the entire vehicle and an abnormality monitoring device for the network node as described in the above embodiment.

[0019] An electronic device comprises a memory, a processor and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the steps of the method for abnormal monitoring of network nodes as described in any of the above embodiments are implemented.

[0020] A computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the method for monitoring abnormalities of a network node as described in the above embodiment.

[0021] In summary, the abnormal monitoring method of network nodes proposed in this application can be applied to each node in the vehicle network. At each node, a hardware-based non-maskable interrupt is used to regularly trigger the communication abnormality monitoring of the local node, so as to avoid the failure of the monitoring process when the software system level is stuck, blocked, etc. When the communication abnormality is detected, the channel status information and the program running status information are obtained from the hardware register, and these information are recorded in the communication abnormality information together with the vehicle network status information and the timestamp determined based on the hardware clock. After the local node communication is restored, the information recorded by the local node is sent to the network abnormality processing device, and the network abnormality processing device is provided with multi-dimensional abnormal information at the hardware level and the software level, and data guarantee is provided for the rapid positioning of the problem node and the abnormality troubleshooting at the software level. The method realizes independent monitoring on the node that is not restricted by the vehicle network status and is not affected by the program running status at the software system level, and can still monitor and record the abnormality of the local node under the working conditions of network dormancy, software abnormality, software stuck, blocking, etc. The abnormal events that occur at the node at different times are captured, and the corresponding abnormal information is recorded, so as to provide data guarantee for timely abnormal warning, for example, a warning can be issued before the vehicle has abnormal consumption of the vehicle power. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for use in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the accompanying drawings in the following description are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative labor.

[0023] Figure 1 is a flowchart of a method for monitoring abnormality of a network node according to an exemplary embodiment of the present application;

[0024] Figure 2 is a flow chart of a method for monitoring abnormality of a network node according to another exemplary embodiment of the present application;

[0025] Figure 3 is a flow chart of a method for monitoring abnormality of a network node according to another exemplary embodiment of the present application;

[0026] Figure 4 is a flow chart of a method for monitoring abnormality of a network node according to another exemplary embodiment of the present application;

[0027] Figure 5 is a schematic block diagram of an abnormality monitoring device for a network node according to another exemplary embodiment of the present application;

[0028] Figure 6 is a schematic block diagram of a vehicle according to an exemplary embodiment of the present application;

[0029] Figure 7 It is a schematic block diagram of an electronic device according to an exemplary embodiment of the present application. DETAILED DESCRIPTION

[0030] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. The embodiments described by reference to the drawings are exemplary and are intended to be used to explain the present application, and cannot be understood as limiting the present application. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0031] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, integers, steps, operations, but does not exclude the presence or addition of one or more other features, integers, steps, operations and / or groups thereof.

[0032] It should also be understood that the term "and / or" used in the present description and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.

[0033] As used in the present specification and the appended claims, the term "if" may be interpreted as "when" or "upon" or "in response to determining" or "in response to detecting", depending on the context. Similarly, the phrase "if it is determined" or "if [described condition or event] is detected" may be interpreted as meaning "upon determination" or "in response to determining" or "upon detection of [described condition or event]" or "in response to detecting [described condition or event]", depending on the context.

[0034] In addition, in the description of the present specification and the appended claims, the terms "first", "second", "third", etc. are only used to distinguish the descriptions and cannot be understood as indicating or implying relative importance.

[0035] References to "one embodiment" or "some embodiments" etc. described in the present specification mean that one or more embodiments of the present invention include specific features, structures or characteristics described in conjunction with the embodiment. Therefore, the phrases "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. appearing in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0036] A network node can be understood as a device or module connected to the vehicle network. Each node can be provided with an independent electronic control unit ECU, and different nodes communicate with each other through the vehicle network. The abnormality monitoring method of network nodes proposed in this application can be applied to different nodes in the vehicle network to perform independent abnormality monitoring on the node and record relevant abnormality information. The abnormal information recorded by different nodes can be uniformly reported to an abnormality handling device, such as a processing device set in the cloud background, so that the abnormality handling device can analyze or display the abnormal information recorded by different nodes to the user to realize the troubleshooting of problem nodes.

[0037] Figure 1 is a flowchart of a method for monitoring abnormality of a network node according to an exemplary embodiment of the present application. Figure 1 As shown, the method comprises the following steps:

[0038] S101, periodically triggering communication abnormality monitoring of a local node in a non-maskable interrupt based on hardware implementation.

[0039] Interrupts can include maskable interrupts and non-maskable interrupts. Non-maskable interrupts cannot be masked by software programs. Non-maskable interrupts can be divided into external non-maskable interrupts and internal non-maskable interrupts. Internal non-maskable interrupt requests are spontaneously generated inside the CPU, and external non-maskable interrupt requests notify the CPU via a dedicated CPU pin.

[0040] The present application can start the communication anomaly monitoring of the local node at a preset interval, for example, it can judge whether there is a communication anomaly in the local node every 5ms; the 5ms period can be placed in a non-maskable interrupt for processing to avoid failure in the case of stuck or blocked at the software system level. The embodiment of the present application relies on hardware non-maskable timed interrupts to start the communication anomaly monitoring of the local node, and can achieve anomaly monitoring even if the software is stuck.

[0041] The monitoring of communication anomalies may include monitoring whether there are anomalies in the local node at both the sending and receiving levels, so as to determine whether the local node can communicate normally with the vehicle network.

[0042] S102, if it is detected that the local node has communication anomalies, the communication anomaly information is recorded, and the communication anomaly information includes channel status information, vehicle network status information, program running information on the local node and current timestamp.

[0043] After the local node detects a communication anomaly, it obtains channel status information from the hardware register so that the exception handling device can determine the channel status of the communication link when the communication anomaly occurs based on the channel status information reported by the local node. The channel status may include channel sending anomaly, channel receiving anomaly or channel busy, etc.

[0044] When the local node cannot continue to communicate normally with the vehicle network, the communication anomaly of the local node may be caused by the local node's own fault or by the vehicle network's fault. This application records the vehicle network status information in the communication anomaly information so that the anomaly handling device can check whether the vehicle network has an anomaly and accurately locate the source of the anomaly.

[0045] Furthermore, the running information of the program on the local node can be obtained from the hardware register, so that the exception handling device can analyze whether the program is stuck when the communication exception occurs, analyze the communication link occupied by the running program, etc., based on the running information of the program reported by the local node, so as to determine whether the communication exception is caused by the software level. In this way, problems such as software system stuck and blocked can be found.

[0046] The current timestamp can be further determined based on the hardware RTC (real-time clock). The current timestamp can be used to locate the moment of communication anomaly. For example, the current timestamp can be the current timestamp corresponding to when the communication anomaly is determined, or the latest timestamp obtained when obtaining the timestamp. This application does not limit this.

[0047] S103: If it is monitored that the local node resumes normal communication, the recorded abnormal information is sent to a network abnormality processing device, wherein the recorded abnormal information includes the communication abnormality information.

[0048] If the local node is detected to have restored normal communication, that is, the local node can communicate with other nodes through the vehicle network, the local node will send the recorded abnormal information to the network abnormality processing device so that the network abnormality processing device can troubleshoot the problem node based on the abnormal information uploaded by each node.

[0049] For example, after the abnormal information is recorded, when the local node communicates normally, that is, the entire vehicle network can operate normally to realize information transmission, the local node sends the recorded abnormal information to the on-board T-BOX, which is forwarded to the cloud background by T-BOX and then displayed to the user, so that the user can check the recorded abnormal information, check the problem points, and issue abnormal warnings, or directly perform intelligent analysis of the abnormal information in the cloud background to determine the problem points.

[0050] Furthermore, when the local node is able to send data to the network link normally, the abnormal information recorded by the local node is sent to the network abnormality handling device, so that the network abnormality handling device can analyze the cause of the abnormality based on the relevant information recorded by the network node when the abnormality occurs, and determine whether the cause of the abnormality is an abnormality in the node itself or an abnormality in the entire vehicle network.

[0051] Optionally, the network anomaly processing device can analyze the abnormal link channel based on the channel status information reported by the local node, determine whether the current network is in a dormant state or a running state based on the vehicle network status information, check whether the program is stuck or blocked based on the program running information on the local node, and search for events close to the time when the communication anomaly occurred based on the recorded "current timestamp". Combined with the above information, it is determined whether the communication anomaly in the local node is caused by any of the following events: node disconnection, network disconnection, software program freeze, etc. Then determine the problem point where the anomaly exists.

[0052] In summary, the abnormal monitoring method of network nodes proposed in this application can be applied to each node in the vehicle network. At each node, a hardware-based non-maskable interrupt is used to regularly trigger the communication abnormality monitoring of the local node, so as to avoid the failure of the monitoring process when the software system level is stuck, blocked, etc. When the communication abnormality is detected, the channel status information and the program running status information are obtained from the hardware register, and these information are recorded in the communication abnormality information together with the vehicle network status information and the timestamp determined based on the hardware clock. After the local node communication is restored, the information recorded by the local node is sent to the network abnormality processing device, and the network abnormality processing device is provided with multi-dimensional abnormal information at the hardware level and the software level, and data guarantee is provided for the rapid positioning of the problem node and the abnormality troubleshooting at the software level. The method realizes independent monitoring on the node that is not restricted by the vehicle network status and is not affected by the program running status at the software system level, and can still monitor and record the abnormality of the local node under the working conditions of network dormancy, software abnormality, software stuck, blocking, etc. The abnormal events that occur at the node at different times are captured, and the corresponding abnormal information is recorded, so as to provide data guarantee for timely abnormal warning, for example, a warning can be issued before the vehicle has abnormal consumption of the vehicle power.

[0053] Based on the above embodiment, the channel status information may include but is not limited to abnormal channel mask, abnormal channel status mask and current channel status register information;

[0054] Based on the channel register status information, it can be determined whether the current network connection status has an error, whether the bus is off, etc.

[0055] The mask definition of the abnormal channel and the abnormal channel status mask can be distinguished by bit, as shown in the following Table 1-2:

[0056] Bit0 Bit1 Bit2 …… CAN Channel LIN Channel ETH Channel ……

[0057] Table 1 Example table of abnormal channel mask definition

[0058] Bit0 Bit1 Bit2 …… The corresponding channel sends an exception The corresponding channel receives abnormal The corresponding channel is busy ……

[0059] Table 2 Example table of abnormal channel status mask definition

[0060] The vehicle network status information may include that the vehicle network is currently in a dormant state or the vehicle network is currently in a running state;

[0061] The running information of the program on the local node may include the current program counter pointer value (ie, PC pointer value), the current R group register information, and the current stack pointer register information (ie, SP stack information).

[0062] Among them, the current PC pointer indicates the location where the current software / program is running, which can be used to determine whether there is a software-level freeze or blockage;

[0063] The current R group register information contains function parameter passing, return value, and return address information, which can be used to determine the function call passing parameter information;

[0064] The SP stack information is used to trace the function call chain. By using the function call relationship, it is possible to determine which link was used when the communication exception occurred.

[0065] In the embodiment of the present application, the above information provided can be used to effectively troubleshoot problems such as occasional node disconnection, abnormal vehicle network disconnection, irregular vehicle network restart, node loss, etc.

[0066] Based on the above embodiments, Figure 2 As shown, the local node is monitored for communication anomalies in the following ways:

[0067] S201, determining whether the communication interruption count of the local node on each communication link is updated, and recording the number of updates of each communication interruption count within a first preset time period;

[0068] S202, determining whether there is the link with the update number of zero, and if so, determining that there is a communication anomaly in the local node;

[0069] Among them, the first preset time length when the whole vehicle network is in a dormant state is greater than the first preset time length when the whole vehicle network is in a running state.

[0070] The communication interruption count may include a reception interruption count and / or a transmission interruption count.

[0071] For example, when the network is in normal working state, the local node monitors the hardware interrupts received and sent by each CAN, LIN, ETH and other communication links. When it is detected that the receive interrupt count and send interrupt count of any communication link have not been updated for more than 30 seconds, it determines that the communication is abnormal and records the communication abnormality information;

[0072] When the network is in sleep mode, monitor the hardware interrupts of receiving and sending of various CAN, LIN, ETH, etc. If the sending interrupt count and receiving interrupt count are not updated for more than 30 minutes, it is determined that the communication is abnormal and the communication abnormality information is recorded.

[0073] In some embodiments, during network operation, the sending interrupt count and receiving interrupt count of each CAN, LIN, ETH and other communication links can be compared every 5 ms. When it is found that the sending interrupt count or receiving interrupt count of one channel has not been updated for more than 30 seconds, the current timestamp, abnormal channel mask, abnormal channel status mask, current network status, current channel status register information, current PC pointer value, current R group register value, and current SP stack information are recorded in the communication exception information; when the network is dormant, the sending interrupt count and receiving interrupt count of each CAN, LIN, ETH and other communication links are compared every 5 ms. When it is found that the sending interrupt count or receiving interrupt count of one channel has not been updated for more than 30 minutes, the communication exception information is recorded.

[0074] Based on the abnormal information recorded in this application, when the whole vehicle has abnormal power consumption but the network is dormant, it is possible to monitor which nodes are still consuming abnormally, expose the abnormal nodes in advance, and avoid power feeding of the whole vehicle.

[0075] Based on the above embodiments, the present application can also monitor whether the reset operation of the local node is an operation triggered by a reset request after the local node is powered on; if not, it is determined that a reset abnormality exists in the local node, and the reset abnormality information is recorded.

[0076] The reset reason can be determined by hardware registers, and the reset reasons may include: power-on reset, software watchdog reset, hardware watchdog reset, reset pin reset, software reset, etc.

[0077] Based on the above embodiments, Figure 3 As shown, the above-mentioned “monitoring whether the reset operation of the local node is an operation triggered by a reset request” may include the following steps:

[0078] S301, obtaining a current timestamp and a timestamp of a reset request most recently received by the local node;

[0079] S302: If the current timestamp is greater than the timestamp of the most recent reset request, and the difference between the current timestamp and the timestamp of the most recent reset request is greater than a second preset duration, confirming that the reset operation is not an operation triggered by a reset request.

[0080] For example, after the node itself is powered on, it starts to determine the reset reason. When the time difference between the most recent reset request and the current time exceeds 10s and the current time is greater than the reset request time, it is considered to be an abnormal reset, that is, the reset operation is not triggered by the reset request, and the reset abnormality information is recorded.

[0081] Correspondingly, the reset exception information may include, but is not limited to, the current timestamp, the type of the reset request received last, the timestamp of the reset request received last, and the reset reason obtained from the reset register. Among them, the reset request type (i.e., the type of the reset request received last) may include software reset, power-on reset, hardware watchdog reset, and other types.

[0082] In this way, by monitoring the abnormal reset of the local node, information about the active reset except the software reset is recorded, so that the network abnormality processing device can troubleshoot the fault of the local node itself based on the reset abnormality information.

[0083] Based on the above embodiments, Figure 4 As shown, the recorded abnormal information may also include wake-up abnormal information. The abnormality monitoring method of the network node proposed in the present application may also include the following steps of monitoring the wake-up abnormality:

[0084] S401, after the local node is awakened from sleep, determine whether the awakening reason of the local node is a power-on awakening, if not, increase the number of non-power-on awakening times by one;

[0085] S402, if the wake-up reason of the local node is network wake-up, clearing the non-power-on wake-up times;

[0086] S403, if the number of non-power-on wake-up times exceeds a preset threshold, confirm that the local node has a wake-up exception, and record the wake-up exception information, where the wake-up exception information includes a current timestamp, a wake-up reason obtained from a wake-up register, and a reset reason obtained from a reset register.

[0087] For example, after the node enters the running state, the wake-up reason is determined. If the wake-up reason is not power-on wake-up, the wake-up count is increased by 1. If network wake-up occurs, the count is cleared. When the count exceeds 30 times, the wake-up exception information is recorded (which may include the current timestamp, wake-up reason, and reset reason).

[0088] The wake-up reasons generally include: the node itself has a network request, receives a network management message, IO level changes, reset occurs, etc.

[0089] The purpose of clearing the count when a network wakeup occurs is to filter out the frequent node wakeups in network anomaly scenarios, thereby identifying the frequent wakeups of the node itself. The reason for the reset is recorded to facilitate the network anomaly handling device to determine whether the abnormal wakeup is caused by the reset.

[0090] This application monitors local reset anomalies and wake-up anomalies at each node and reports related anomaly information to facilitate the network anomaly handling device to determine whether the vehicle has problems with network non-sleep and repeated network wake-up, and expose abnormal power consumption before causing battery power supply. By monitoring communication anomalies and reporting communication anomaly information, it is convenient for the network anomaly handling device to determine whether the vehicle has problems with network interruption, occasional node disconnection, and network signal stuck. Based on the record information provided by each network node, the nodes in the vehicle that frequently request the network can be located.

[0091] The network node abnormality monitoring method proposed in this application can work when the network is not working normally, and can record abnormalities caused by its own reasons; it can record relevant information under software-level system freezes, abnormal resets, blockages and other working conditions, so that the network abnormality handling device can quickly locate the fault point.

[0092] In general, this application can trace back the abnormal information of its own node when the network is in dormant state, or trace back the abnormal information of its own node being offline when the network is normal; and it can cover the reasons at the software level, the abnormal operation of the local node when the network is in dormant state, and other problems, which helps to provide early warning for occasional problems and provide a data basis for the rapid troubleshooting of vehicle network problems and power supply problems.

[0093] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0094] Figure 5 is a schematic block diagram of an abnormality monitoring device for a network node according to another exemplary embodiment of the present application. Figure 5 As shown, the device 500 includes an abnormality monitoring module 501 , an information recording module 502 and a sending module 503 .

[0095] The abnormality monitoring module 501 is used to periodically trigger the communication abnormality monitoring of the local node in the non-maskable interrupt based on the hardware implementation;

[0096] An information recording module 502 is used to record communication abnormality information if a communication abnormality is detected in the local node, wherein the communication abnormality information includes channel status information, vehicle network status information, program running information on the local node, and a current timestamp;

[0097] The sending module 503 is used to send the recorded abnormal information to the network abnormality processing device if it is monitored that the local node resumes normal communication, and the recorded abnormal information includes the communication abnormality information.

[0098] In an embodiment of the present application, communication anomalies of the local node are monitored in the following manner: determine whether the communication interruption count of the local node on each communication link is updated, and record the number of updates of each communication interruption count within a first preset time period; determine whether there is a link with a zero update number, and if so, determine that there is a communication anomaly in the local node; wherein the first preset time period when the entire vehicle network is in a dormant state is greater than the first preset time period when the entire vehicle network is in an operating state.

[0099] In an embodiment of the present application, the recorded exception information also includes reset exception information, and the device is also used to: after the local node is powered on, monitor whether the reset operation of the local node is an operation triggered by a reset request; if not, determine that there is a reset exception in the local node, and record the reset exception information.

[0100] In an embodiment of the present application, the device is also used to: obtain a current timestamp and a timestamp of a reset request most recently received by the local node; if the current timestamp is greater than the timestamp of the most recent reset request, and the difference between the current timestamp and the timestamp of the most recent reset request is greater than a second preset time length, confirming that the reset operation is not an operation triggered by a reset request; the reset exception information includes the current timestamp, the type of the most recently received reset request, the timestamp of the most recently received reset request, and the reset reason obtained from the reset register.

[0101] In an embodiment of the present application, the recorded exception information also includes wake-up exception information, and the device is also used to: after the local node is awakened from hibernation, determine whether the wake-up reason of the local node is power-on wake-up, if not, increase the number of non-power-on wake-up times by one; if the wake-up reason of the local node is network wake-up, clear the number of non-power-on wake-up times to zero; if the number of non-power-on wake-up times exceeds a preset threshold, confirm that there is a wake-up exception in the local node, and record the wake-up exception information, wherein the wake-up exception information includes the current timestamp, the wake-up reason obtained from the wake-up register, and the reset reason obtained from the reset register.

[0102] In an embodiment of the present application, the channel status information includes an abnormal channel mask, an abnormal channel status mask, and current channel status register information; the vehicle network status information includes whether the vehicle network is currently in a sleep state or whether the vehicle network is currently in a running state; the running information of the program on the local node includes the current program counter pointer value, the current R group register information, and the current stack pointer register information.

[0103] In summary, the abnormal monitoring device of the network node proposed in this application can be applied to each node in the vehicle network. At each node, the communication abnormality monitoring of the local node is triggered regularly by using the hardware-based non-maskable interrupt, so as to avoid the failure of the monitoring process when the software system level is stuck, blocked, etc. When the communication abnormality is detected, the channel status information and the program running status information are obtained from the hardware register, and these information are recorded in the communication abnormality information together with the vehicle network status information and the timestamp determined based on the hardware clock. After the communication of the local node is restored, the information recorded by the local node is sent to the network abnormality processing device, and the network abnormality processing device is provided with multi-dimensional abnormal information at the hardware level and the software level, and data guarantee is provided for the rapid location of the problem node and the abnormality troubleshooting at the software level. The method realizes independent monitoring on the node that is not restricted by the vehicle network status and is not affected by the program running status at the software system level, and can still monitor and record the abnormality of the local node under the working conditions of network dormancy, software abnormality, software stuck, blocking, etc. The abnormal events that occur at the node at different times are captured, and the corresponding abnormal information is recorded, so as to provide data guarantee for timely abnormal warning, such as issuing a warning before the vehicle has abnormal consumption of the vehicle power.

[0104] In order to implement the above embodiment, the present application embodiment also proposes a vehicle 600, such as Figure 6 As shown, it includes an electronic processing unit 601 at the network node of the entire vehicle and an abnormality monitoring device 500 for the network node as described in the above embodiment.

[0105] In order to implement the above embodiment, the present application embodiment also proposes an electronic device 700, such as Figure 7 As shown, the electronic device 700 may specifically include: a memory 701, a processor 702, and a computer program stored in the memory 701 and executable on the processor 702. When the processor 702 executes the program, the steps of the abnormal monitoring method for network nodes described in the above embodiment are implemented.

[0106] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0107] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0108] The embodiments described above are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A method for monitoring abnormality of a network node, characterized in that: include: In the hardware-based non-maskable interrupt, the communication anomaly monitoring of the local node is triggered regularly; If a communication anomaly is detected in the local node, the communication anomaly information is recorded, and the communication anomaly information includes channel status information, vehicle network status information, program running information on the local node, and current timestamp; If it is monitored that the local node resumes normal communication, the recorded abnormal information is sent to the network abnormality processing device, and the recorded abnormal information includes the communication abnormality information.

2. The method according to claim 1, characterized in that Monitor the local node for communication anomalies in the following ways: Determine whether the communication interruption count of the local node on each communication link is updated, and record the number of updates of each communication interruption count within a first preset time length; Determine whether there is the link whose update times is zero, and if so, determine that there is a communication abnormality in the local node; Among them, the first preset time length when the whole vehicle network is in a dormant state is greater than the first preset time length when the whole vehicle network is in a running state.

3. The method according to claim 1, characterized in that The recorded abnormal information also includes reset abnormal information, and the method further includes: After the local node is powered on, monitoring whether a reset operation of the local node is an operation triggered by a reset request; If not, it is determined that a reset abnormality exists in the local node, and the reset abnormality information is recorded.

4. The method according to claim 3, characterized in that The monitoring of whether the reset operation of the local node is an operation triggered by a reset request includes: Obtaining a current timestamp and a timestamp of a reset request most recently received by the local node; If the current timestamp is greater than the timestamp of the most recent reset request, and the difference between the current timestamp and the timestamp of the most recent reset request is greater than a second preset duration, confirming that the reset operation is not an operation triggered by a reset request; The reset exception information includes the current timestamp, the type of the reset request received most recently, the timestamp of the reset request received most recently, and the reset reason obtained from the reset register.

5. The method according to claim 1, characterized in that The recorded abnormal information also includes wake-up abnormal information, and the method further includes: After the local node is awakened from sleep, determine whether the awakening reason of the local node is power-on awakening, and if not, increase the number of non-power-on awakening times by one; If the wake-up reason of the local node is network wake-up, the number of non-power-on wake-up times is cleared; If the number of non-power-on wake-ups exceeds a preset threshold, it is confirmed that the local node has a wake-up exception, and the wake-up exception information is recorded, where the wake-up exception information includes a current timestamp, a wake-up reason obtained from a wake-up register, and a reset reason obtained from a reset register.

6. The method according to claim 1, characterized in that The channel status information includes abnormal channel mask, abnormal channel status mask, and current channel status register information; The vehicle network status information includes whether the vehicle network is currently in a dormant state or the vehicle network is currently in a running state; The running information of the program on the local node includes the current program counter pointer value, the current R group register information and the current stack pointer register information.

7. A network node abnormality monitoring device, characterized in that: include: The abnormality monitoring module is used to periodically trigger the communication abnormality monitoring of the local node in the non-maskable interrupt based on hardware implementation; An information recording module, for recording communication abnormality information if a communication abnormality is detected in the local node, wherein the communication abnormality information includes channel status information, vehicle network status information, program running information on the local node, and a current timestamp; The sending module is used to send the recorded abnormal information to the network abnormality processing device if it is monitored that the local node resumes normal communication, and the recorded abnormal information includes the communication abnormality information.

8. A vehicle, characterized in that: The invention comprises an electronic processing unit at a network node and an abnormality monitoring device for a network node as claimed in claim 7.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the method for monitoring abnormalities of a network node according to any one of claims 1 to 6 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the steps of the abnormality monitoring method for a network node as described in any one of claims 1 to 6 are implemented.

Images