Abnormal monitoring method and device of network node, vehicle, equipment and medium

Abstract

The application provides an abnormality monitoring method and device of a network node, a vehicle, equipment and a medium, and relates to the technical field of vehicles. The method uses a hardware-based non-maskable interrupt to trigger communication abnormality monitoring of a local node at a fixed time, avoiding the monitoring process from being invalid when the software system level is stuck or blocked. When communication abnormality is monitored, channel state information and program running state information are obtained from a hardware register, and the information is recorded in communication abnormality information together with vehicle network state information and a timestamp determined based on a hardware clock. After communication is restored, the recorded information is sent to a network abnormality processing device, which provides multi-dimensional abnormality information at the hardware level and the software level, and provides data support for rapid positioning of a problem node and software layer exception troubleshooting. The method realizes independent monitoring of the node, which is not limited by the vehicle network state and is not affected by the program running state at the software system level.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a method, device, vehicle, equipment and medium for anomaly monitoring of network nodes. Background Technology

[0002] The vehicle's battery provides power for onboard electrical equipment and engine starting. As the vehicle's technology evolves, the number of Electronic Control Unit (ECU) nodes also increases. When the vehicle is powered off, problems such as one or more nodes failing to hibernate or experiencing abnormal wake-ups can cause the battery to drain too quickly, preventing the vehicle from starting. Furthermore, with the increasing number of ECU nodes, issues like abnormal disconnections and congestion during normal network operation become difficult to troubleshoot. The intermittent nature of these problems further complicates troubleshooting and analysis, making it difficult for after-sales maintenance personnel to quickly locate the problematic node.

[0003] Existing methods include recording the node's non-sleep time or the number of times the node wakes up to count whether the node is abnormal; or collecting the battery voltage and recording and uploading the node information when the battery voltage reaches the power supply threshold; or monitoring the network status and uploading the node information.

[0004] The existing methods upload data and record nodes only after power is triggered, making it impossible to obtain data information before power is supplied. Furthermore, the uploaded data information is limited, making it impossible to further locate problematic nodes. Currently, the anomaly monitoring strategy and information upload are only performed when the node itself is working normally, the network is working normally, and the software program is executing normally. This cannot cover the monitoring of software problems such as software freezes, process deadlocks, and network congestion. Summary of the Invention

[0005] Therefore, it is necessary to provide a method, device, vehicle, electronic device, and storage medium for monitoring network node anomalies to address the aforementioned technical issues, so as to achieve independent monitoring of node anomalies, record multi-dimensional anomaly information, and provide assurance for rapid location of problem nodes and troubleshooting of software-level anomalies.

[0006] A method for monitoring network node anomalies includes: periodically triggering communication anomaly monitoring of a local node in a hardware-based non-maskable interrupt; if a communication anomaly is detected in the local node, recording communication anomaly information, including channel status information, vehicle network status information, program execution information on the local node, and a current timestamp; if the local node resumes normal communication, sending the recorded anomaly information to a network anomaly handling device, the recorded anomaly information including the communication anomaly information.

[0007] In this embodiment of the application, communication anomaly monitoring of the local node is performed in the following manner: 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; determining whether there is a link with an update count of zero, and if so, determining that the local node has a communication anomaly; wherein, the first preset time period when the vehicle network is in a dormant state is greater than the first preset time period when the vehicle network is in an operating state.

[0008] In this embodiment of the application, the recorded abnormal information also includes reset abnormal information, and the method further 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 the local node has a reset abnormality, and recording the reset abnormal information.

[0009] In this embodiment, monitoring whether the reset operation of the local node is triggered by a reset request includes: obtaining the current timestamp and the timestamp of the most recently received reset request; if the current timestamp is greater than the timestamp of the most recently received reset request, and the difference between the current timestamp and the timestamp of the most recently received reset request is greater than a second preset duration, then it is confirmed that the reset operation is not 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 this embodiment of the application, the recorded abnormal information further includes wake-up abnormal information, and the method further includes: after the local node wakes up from hibernation, determining whether the wake-up reason of the local node is power-on wake-up; if not, incrementing the non-power-on wake-up count by one; if the wake-up reason of the local node is network wake-up, resetting the non-power-on wake-up count to zero; if the non-power-on wake-up count exceeds a preset threshold, confirming that the local node has a wake-up abnormality, and recording the wake-up abnormal information, the wake-up abnormal information including the current timestamp, the wake-up reason obtained from the wake-up register, and the reset reason obtained from the reset register.

[0011] In this embodiment, 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 dormant state or the vehicle network is currently in a running state; the program execution information 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] An anomaly monitoring device for a network node includes: an anomaly monitoring module, used to periodically trigger communication anomaly monitoring of a local node in a hardware-based non-maskable interrupt; an information recording module, used to record communication anomaly information if a communication anomaly is detected in the local node, the communication anomaly information including channel status information, vehicle network status information, program running information on the local node, and a current timestamp; and a sending module, used to send the recorded anomaly information to a network anomaly handling device if the local node resumes normal communication, the recorded anomaly information including the communication anomaly information.

[0013] In this embodiment of the application, communication anomaly monitoring of the local node is performed in the following manner: 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; determining whether there is a link with an update count of zero, and if so, determining that the local node has a communication anomaly; wherein, the first preset time period when the vehicle network is in a dormant state is greater than the first preset time period when the vehicle network is in an operating state.

[0014] In this embodiment of the application, the recorded abnormal information also includes reset abnormal information, and the device is further configured 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 the local node has a reset abnormality, and record the reset abnormal information.

[0015] In this embodiment of the application, the device is further configured to: obtain the current timestamp and the timestamp of the most recently received reset request of the local node; if the current timestamp is greater than the timestamp of the most recently received reset request, and the difference between the current timestamp and the timestamp of the most recently received reset request is greater than a second preset duration, then confirm 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.

[0016] In this embodiment of the application, the recorded abnormal information further includes wake-up abnormal information. The device is further configured to: after the local node wakes up from hibernation, determine whether the wake-up reason of the local node is power-on wake-up; if not, increment the non-power-on wake-up count by one; if the wake-up reason of the local node is network wake-up, clear the non-power-on wake-up count to zero; if the non-power-on wake-up count exceeds a preset threshold, confirm that the local node has a wake-up abnormality, and record the wake-up abnormal information, which 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 this embodiment, 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 dormant state or the vehicle network is currently in a running state; the program execution information 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 includes an electronic processing unit at a network node of the vehicle and an anomaly monitoring device for the network node as described in the above embodiments.

[0019] An electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, when the processor executes the computer program, it implements the steps of the network node anomaly monitoring method as described in any of the above embodiments.

[0020] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the anomaly monitoring method for network nodes as described in the above embodiments.

[0021] In summary, the network node anomaly monitoring method proposed in this application can be applied to various nodes in the vehicle network. At each node, a hardware-based non-maskable interrupt is used to periodically trigger communication anomaly monitoring, preventing the monitoring process from failing when software system-level issues such as freezing or blocking occur. When a communication anomaly is detected, channel status information and program runtime information are retrieved from hardware registers. This information, along with vehicle network status information and a timestamp determined by a hardware clock, is recorded in the communication anomaly information. After communication at the local node is restored, the information recorded by the local node is sent to the network anomaly handling device, providing the device with multi-dimensional anomaly information at both the hardware and software levels. This provides data assurance for rapid node localization and software-level anomaly troubleshooting. This method enables independent monitoring at the node, unaffected by the vehicle network status or the program runtime at the software system level. It can still monitor and record anomalies at the local node under conditions such as network hibernation, software anomalies, software freezing, and blocking. It captures anomaly events occurring at different times and records the corresponding anomaly information, providing data assurance for timely anomaly warnings, such as issuing a warning before abnormal vehicle battery consumption occurs. Attached Figure Description

[0022] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is a flowchart illustrating an anomaly monitoring method for a network node according to an exemplary embodiment of this application;

[0024] Figure 2 This is a flowchart illustrating an anomaly monitoring method for a network node according to another exemplary embodiment of this application;

[0025] Figure 3 This is a flowchart illustrating an anomaly monitoring method for a network node according to another exemplary embodiment of this application;

[0026] Figure 4 This is a flowchart illustrating an anomaly monitoring method for a network node according to another exemplary embodiment of this application;

[0027] Figure 5 This is a schematic block diagram illustrating an anomaly monitoring device for a network node according to another exemplary embodiment of this application;

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

[0029] Figure 7 This is a schematic block diagram of an electronic device according to an exemplary embodiment of this application. Detailed Implementation

[0030] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. The embodiments described with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0031] It should be understood that, when used in the specification and appended claims of this invention, the term "comprising" indicates the presence of the described feature, integral, step, or operation, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, and / or a collection thereof.

[0032] It should also be understood that the term “and / or” as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

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

[0034] Furthermore, in the description of this invention and the appended claims, the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0035] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of the invention include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, phrases such as "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0036] A network node can be understood as a device or module connected to the vehicle network. Each node can be equipped with an independent Electronic Control Unit (ECU), and different nodes communicate with each other through the vehicle network. The network node anomaly monitoring method proposed in this application can be applied to different nodes in the vehicle network to independently monitor the anomalies of each node and record relevant anomaly information. The anomaly information recorded by different nodes can be uniformly reported to an anomaly handling device, such as a processing device set up in the cloud background, so that the anomaly handling device can analyze the anomaly information recorded by different nodes or display it to the user, thereby enabling the troubleshooting of problematic nodes.

[0037] Figure 1 This is a flowchart illustrating an anomaly monitoring method for network nodes according to an exemplary embodiment of this application, such as... Figure 1 As shown, the method includes the following steps:

[0038] S101 periodically triggers communication anomaly monitoring of the local node in a hardware-based non-maskable interrupt.

[0039] Interrupts can be classified into maskable interrupts and non-maskable interrupts. Non-maskable interrupts cannot be masked by software. Non-maskable interrupts can be further divided into external non-maskable interrupts and internal non-maskable interrupts. Internal non-maskable interrupt requests are generated spontaneously by the CPU, while external non-maskable interrupt requests are notified to the CPU via a dedicated CPU pin.

[0040] This application can periodically activate communication anomaly monitoring of local nodes after a preset time interval, for example, checking for communication anomalies every 5ms. The 5ms period can be handled within a non-maskable interrupt to avoid failure due to software system freezes or blockages. This embodiment relies on a hardware non-maskable timed interrupt to enable communication anomaly monitoring of local nodes, ensuring anomaly detection even if the software freezes.

[0041] Monitoring communication anomalies can include monitoring for anomalies at both the sending and receiving levels of the local node. This determines whether the local node can communicate normally with the vehicle network.

[0042] S102, if a communication anomaly is detected in the local node, the communication anomaly information is recorded. The communication anomaly information includes channel status information, vehicle network status information, program running information on the local node, and current timestamp.

[0043] After a communication anomaly is detected by the local node, the channel status information is obtained from the hardware register so that the anomaly 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 transmission anomaly, channel reception anomaly, or channel busy.

[0044] When a local node is unable to communicate normally with the vehicle network, the communication anomaly may be caused by a fault in the local node itself or by a fault in the vehicle network. This application records the vehicle network status information in the communication anomaly information so that the anomaly handling device can investigate whether there is an anomaly in the vehicle network and accurately locate the source of the anomaly.

[0045] Furthermore, the runtime information of the program on the local node can be obtained from the hardware registers. This allows the exception handling device to analyze whether the program freezes when a communication exception occurs, analyze the communication links occupied by the running program, and thus determine whether the communication exception is caused by the software layer. This helps to identify problems such as software system freezes and blockages.

[0046] Furthermore, the current timestamp can be determined based on a hardware RTC (Real-Time Clock). This current timestamp can be used to locate the moment of communication failure; for example, the current timestamp could be the timestamp corresponding to the moment the communication failure was determined, or the latest timestamp obtained when acquiring the timestamp. This application does not impose any limitations.

[0047] S103, if the local node is detected to have resumed normal communication, the recorded abnormal information is sent to the network abnormality handling device, and the recorded abnormal information includes the communication abnormality information.

[0048] If the local node is detected to have resumed normal communication, meaning it can communicate with other nodes through the vehicle network, the local node will send the recorded anomaly information to the network anomaly handling device. This device will then use the anomaly information uploaded by each node to identify the problematic node.

[0049] For example, after the abnormal information is recorded, when the local node communication is normal, that is, when the vehicle network can operate normally and realize information transmission, the local node sends the recorded abnormal information to the vehicle T-BOX, which forwards it to the cloud backend and then displays it to the user. This allows the user to check the recorded abnormal information, investigate the problem, receive abnormal warnings, or directly perform intelligent analysis of the abnormal information in the cloud backend to determine the problem.

[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 abnormality is caused by an abnormality in the node itself or by an abnormality in the entire vehicle network.

[0051] Optionally, the network anomaly handling 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 or running state based on the vehicle network status information, check whether the program is stuck or blocked based on the program's running information on the local node, and search for events close to the time of the communication anomaly based on the recorded "current timestamp". Combining the above information, it determines whether the communication anomaly at the local node is caused by a node disconnection, network disconnection, or software program freeze. This identifies the problematic area where the anomaly occurs.

[0052] In summary, the network node anomaly monitoring method proposed in this application can be applied to various nodes in the vehicle network. At each node, a hardware-based non-maskable interrupt is used to periodically trigger communication anomaly monitoring, preventing the monitoring process from failing when software system-level issues such as freezing or blocking occur. When a communication anomaly is detected, channel status information and program runtime information are retrieved from hardware registers. This information, along with vehicle network status information and a timestamp determined by a hardware clock, is recorded in the communication anomaly information. After communication at the local node is restored, the information recorded by the local node is sent to the network anomaly handling device, providing the device with multi-dimensional anomaly information at both the hardware and software levels. This provides data assurance for rapid node localization and software-level anomaly troubleshooting. This method enables independent monitoring at the node, unaffected by the vehicle network status or the program runtime at the software system level. It can still monitor and record anomalies at the local node under conditions such as network hibernation, software anomalies, software freezing, and blocking. It captures anomaly events occurring at different times and records the corresponding anomaly information, providing data assurance for timely anomaly warnings, such as issuing a warning before abnormal vehicle battery consumption occurs.

[0053] Based on the above embodiments, 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 determine whether the current network connection status has encountered an error, whether a bus off has occurred, and other similar situations.

[0055] The mask definition and abnormal channel status mask can be distinguished by bits, as shown in Table 1-2 below:

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

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

[0058] Bit0 Bit1 Bit2 …… Corresponding channel transmission error Corresponding channel reception error The corresponding channel is busy. ……

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

[0060] The vehicle network status information may include whether the vehicle network is currently in a dormant state or the vehicle network is currently in an operating state.

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

[0062] The current PC pointer indicates the current position of the software / program and can be used to determine whether a software-level freeze or blockage has occurred.

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

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

[0065] In this embodiment of the application, the above information can be used to effectively troubleshoot problems such as occasional node disconnections, abnormal disconnections of the vehicle network, irregular restarts of the vehicle network, and node loss.

[0066] Based on the above embodiments, such as Figure 2 As shown, communication anomalies on the local node are monitored using the following methods:

[0067] S201, determine whether the communication interruption count of the local node on each communication link has been updated, and record the number of times each communication interruption count has been updated within a first preset time period;

[0068] S202, determine whether there is a link with an update count of zero; if so, determine that the local node has a communication anomaly.

[0069] The first preset duration when the vehicle network is in a dormant state is longer than the first preset duration when the vehicle network is in an operating state.

[0070] Communication interruption counts may include receive interruption counts and / or transmit interruption counts.

[0071] For example, when the network is in normal working condition, the local node monitors the hardware interrupts of each communication link such as CAN, LIN, ETH, etc. If it detects that the interrupt count of any communication link has 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 for receiving and sending via CAN, LIN, ETH, etc. If the transmit interrupt count and receive interrupt count have not been updated for more than 30 minutes, a communication abnormality is determined and the communication abnormality information is recorded.

[0073] In some embodiments, during network operation, the transmit interrupt count and receive interrupt count of each CAN, LIN, ETH, and other communication links are compared every 5ms. If it is found that the transmit interrupt count or receive interrupt count of one link has not been updated for more than 30s, 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 error information. When the network is in sleep mode, the transmit interrupt count and receive interrupt count of each CAN, LIN, ETH, and other communication links are compared every 5ms. If it is found that the transmit interrupt count or receive interrupt count of one link has not been updated for more than 30 minutes, the communication error information is recorded.

[0074] Based on the abnormal information recorded in this application, when the vehicle experiences abnormal power consumption but the network is in sleep mode, it is possible to monitor which nodes are still consuming power abnormally, expose abnormal nodes in advance, and avoid vehicle power depletion.

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

[0076] The cause of a reset can be determined through hardware registers. Reset causes may include: power-on reset, software watchdog reset, hardware watchdog reset, reset pin reset, software reset, etc.

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

[0078] S301, Obtain the current timestamp and the timestamp of the most recent reset request 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 the second preset duration, then it is confirmed that the reset operation is not an operation triggered by a reset request.

[0080] For example, after a node powers on, it begins to determine the cause of a reset. If the time difference between the most recent reset request and the current time exceeds 10 seconds and the current time is greater than the reset request time, it is considered an abnormal reset, meaning that the reset operation was not triggered by the reset request, and the reset abnormal information is recorded.

[0081] Correspondingly, the reset exception information may include, but is not limited to, 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. The reset request type (i.e., the type of the most recently received reset request) may include various types such as software reset, power-on reset, and hardware watchdog reset.

[0082] In this way, by monitoring abnormal resets of local nodes, information on active resets other than software resets is recorded, so that the network anomaly handling device can troubleshoot the faults of the local nodes themselves based on the reset anomaly information.

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

[0084] S401, after the local node wakes up from sleep, determine whether the reason for the wake-up of the local node is power-on wake-up. If not, increment the number of non-power-on wake-up attempts by one.

[0085] S402, if the reason for the wake-up of the local node is network wake-up, then the number of non-power-on wake-up counts is cleared to zero;

[0086] S403, if the number of non-power-on wake-up attempts exceeds a preset threshold, then it is confirmed that there is a wake-up abnormality in the local node, and the wake-up abnormality information is recorded. The wake-up abnormality information includes the current timestamp, the wake-up reason obtained from the wake-up register, and the reset reason obtained from the reset register.

[0087] For example, after a 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 incremented by 1. If a network wake-up occurs, the count is reset to zero. When the count exceeds 30, wake-up exception information is recorded (which may include the current timestamp, wake-up reason, and reset reason).

[0088] Reasons for wake-up typically include: the node itself has a network request, receives a network management message, I / O level changes, a reset occurs, etc.

[0089] This application resets the count to zero when a Wake-on-LAN event occurs to filter out frequent node wake-ups under network anomaly scenarios, thereby identifying frequent wake-ups occurring within the node itself. Recording the reason for the reset helps the network anomaly handling device determine whether the abnormal wake-up was caused by a reset.

[0090] This application monitors local reset and wake-up anomalies at each node and reports relevant anomaly information. This facilitates the network anomaly handling device in determining whether the vehicle has issues with network non-sleep or repeated network wake-ups, exposing abnormal power consumption problems before battery depletion occurs. By monitoring and reporting communication anomalies, the network anomaly handling device can determine whether the vehicle has network interruptions, intermittent node disconnections, or network signal freezes. Based on the recorded information provided by each network node, nodes in the vehicle that frequently request the network can be located.

[0091] The network node anomaly monitoring method proposed in this application can operate when the network is not working properly, and can record anomalies caused by its own reasons; it can also record relevant information under operating conditions such as system freeze, abnormal reset, and blockage at the software level, so that the network anomaly handling device can quickly locate the fault point.

[0092] In summary, this application can trace abnormal information of its own node when the network is in a dormant state, or trace abnormal information of its own node going offline when the network is in a normal state; and it can cover software-level causes, abnormal operation of local nodes when the network is in a dormant state, etc., which helps to provide early warning of intermittent problems and provides a data foundation for the rapid investigation of vehicle network problems and power supply problems.

[0093] It should be understood that the sequence number of each step in the above embodiments does not imply 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 this application.

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

[0095] The anomaly monitoring module 501 is used to periodically trigger communication anomaly monitoring of the local node in a hardware-based non-maskable interrupt.

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

[0097] The sending module 503 is used to send the recorded abnormal information to the network abnormality handling device if the local node is detected to have resumed normal communication. The recorded abnormal information includes the communication abnormality information.

[0098] In this embodiment of the application, communication anomaly monitoring of the local node is performed in the following manner: 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; determining whether there is a link with an update count of zero, and if so, determining that the local node has a communication anomaly; wherein, the first preset time period when the vehicle network is in a dormant state is greater than the first preset time period when the vehicle network is in an operating state.

[0099] In this embodiment of the application, the recorded abnormal information also includes reset abnormal information, and the device is further configured 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 the local node has a reset abnormality, and record the reset abnormal information.

[0100] In this embodiment of the application, the device is further configured to: obtain the current timestamp and the timestamp of the most recently received reset request of the local node; if the current timestamp is greater than the timestamp of the most recently received reset request, and the difference between the current timestamp and the timestamp of the most recently received reset request is greater than a second preset duration, then confirm 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 this embodiment of the application, the recorded abnormal information further includes wake-up abnormal information. The device is further configured to: after the local node wakes up from hibernation, determine whether the wake-up reason of the local node is power-on wake-up; if not, increment the non-power-on wake-up count by one; if the wake-up reason of the local node is network wake-up, clear the non-power-on wake-up count to zero; if the non-power-on wake-up count exceeds a preset threshold, confirm that the local node has a wake-up abnormality, and record the wake-up abnormal information, which 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 this embodiment, 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 dormant state or the vehicle network is currently in a running state; the program execution information 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 network node anomaly monitoring device proposed in this application can be applied to various nodes in the vehicle network. At each node, a hardware-based non-maskable interrupt is used to periodically trigger communication anomaly monitoring, preventing the monitoring process from failing when software system-level issues such as freezing or blocking occur. When a communication anomaly is detected, channel status information and program runtime information are retrieved from hardware registers. This information, along with vehicle network status information and a timestamp determined by a hardware clock, is recorded in the communication anomaly information. After communication at the local node is restored, the information recorded by the local node is sent to the network anomaly handling device, providing the device with multi-dimensional anomaly information at both the hardware and software levels. This provides data assurance for rapid node localization and software-level anomaly troubleshooting. This method enables independent monitoring at the node, unaffected by the vehicle network status or the program runtime at the software system level. It can still monitor and record anomalies at the local node under conditions such as network hibernation, software anomalies, software freezing, and blocking. It captures anomaly events occurring at different times and records the corresponding anomaly information, providing data assurance for timely anomaly warnings, such as issuing warnings before abnormal vehicle battery consumption occurs.

[0104] To achieve the above embodiments, this application also proposes a vehicle 600, such as... Figure 6 As shown, it includes an electronic processing unit 601 at the vehicle network node and an anomaly monitoring device 500 for the network node as described in the above embodiment.

[0105] To implement the above embodiments, this application 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 on the memory 701 and executable on the processor 702. When the processor 702 executes the program, it implements the steps of the abnormal monitoring method for network nodes as described in the above embodiments.

[0106] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, 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. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.

[0107] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to 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 above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for monitoring anomalies in network nodes, characterized in that, include: The communication anomaly monitoring of the local node is periodically triggered in the non-maskable interrupt implemented in hardware. If a communication anomaly is detected at the local node, the communication anomaly information is recorded. The communication anomaly information includes channel status information, vehicle network status information, program running information on the local node, and the current timestamp. If the local node is detected to have resumed normal communication, the recorded abnormal information will be sent to the network abnormality handling device, including the communication abnormality information. The following methods can be used to monitor communication anomalies on local nodes: Determine whether the communication interruption count of the local node on each communication link has been updated, and record the number of times each communication interruption count has been updated within a first preset time period; Determine whether there is a link with an update count of zero; if so, determine that the local node has a communication anomaly. The first preset duration when the vehicle network is in a dormant state is longer than the first preset duration when the vehicle network is in an operating state.

2. The method as described in claim 1, characterized in that, The recorded exception information also includes reset exception information, and the method further includes: After the local node is powered on, monitor whether the reset operation of the local node is triggered by a reset request; If not, then it is determined that the local node has a reset anomaly, and the reset anomaly information is recorded.

3. The method as described in claim 2, characterized in that, The monitoring of whether the reset operation of the local node is triggered by a reset request includes: Obtain the current timestamp and the timestamp of the most recent reset request 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 the second preset duration, then it is confirmed that the reset operation is not triggered by a reset request. The reset error 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.

4. The method as described in claim 1, characterized in that, The recorded abnormal information also includes wake-up abnormal information, and the method further includes: After the local node wakes up from sleep, it is determined whether the reason for the local node's wake-up is power-on wake-up. If not, the number of non-power-on wake-up counts is incremented by one. If the reason for waking up the local node is network wake-up, then the number of non-power-on wake-up counts will be reset to zero. If the number of non-power-on wake-up attempts exceeds a preset threshold, it is confirmed that there is a wake-up anomaly in the local node, and the wake-up anomaly information is recorded. The wake-up anomaly information includes the current timestamp, the wake-up reason obtained from the wake-up register, and the reset reason obtained from the reset register.

5. The method as described in claim 1, characterized in that, 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 dormant state or is currently in an operating state; The program execution information on the local node includes the current program counter pointer value, the current R group register information, and the current stack pointer register information.

6. An anomaly monitoring device for network nodes, characterized in that, include: The anomaly monitoring module is used to periodically trigger communication anomaly monitoring of the local node in a hardware-based non-maskable interrupt. The information recording module is used to record communication abnormality information if a communication abnormality is detected at the local node. The communication abnormality information includes channel status information, vehicle network status information, program running information on the local node, and current timestamp. The sending module is used to send the recorded abnormal information to the network abnormality handling device if the local node is detected to have resumed normal communication. The recorded abnormal information includes the communication abnormality information. The following methods can be used to monitor communication anomalies on local nodes: Determine whether the communication interruption count of the local node on each communication link has been updated, and record the number of times each communication interruption count has been updated within a first preset time period; Determine whether there is a link with an update count of zero; if so, determine that the local node has a communication anomaly. The first preset duration when the vehicle network is in a dormant state is longer than the first preset duration when the vehicle network is in an operating state.

7. A vehicle, characterized in that, It includes an electronic processing unit at the network node and an anomaly monitoring device for the network node as described in claim 6.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the abnormal monitoring method for network nodes as described in any one of claims 1-5.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by the processor, the program implements the steps of the abnormal monitoring method for network nodes as described in any one of claims 1-5.

Images