CAN network communication diagnostic methods, devices and vehicles

Abstract

This application discloses a CAN network communication diagnostic method, apparatus, and vehicle, belonging to the field of vehicle technology. The method includes: determining a first diagnostic window based on the target message period of CAN node messages sent by the target CAN node; opening a second diagnostic window (smaller than the first window) if no CAN node message is received from the target CAN node within the first diagnostic window; updating the target node timeout information based on the reception status of CAN node messages within the second diagnostic window; and reporting a communication anomaly to the target CAN node if the target node timeout information meets the reporting conditions. The technical solution provided by this application can improve the accuracy of CAN network communication diagnostics by reducing the false alarm rate.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a CAN (Controller Area Network) network communication diagnostic method, device, and vehicle. Background Technology

[0002] CAN networks are used to enable communication in automotive electronic devices. With increasing demands for communication security, automotive electronic devices require communication diagnostics of CAN networks.

[0003] In related technologies, network communication is monitored by periodically receiving network packets, and a network fault is determined when a reception timeout occurs.

[0004] However, in the event of a timeout in the reception of a single network message, the CAN controller may receive the message after the timeout, but still determine that the message reception failed, resulting in a communication diagnostic error. Summary of the Invention

[0005] This application provides a CAN network communication diagnostic method, apparatus, and vehicle. The technical solution is as follows:

[0006] On one hand, embodiments of this application provide a CAN network communication diagnostic method, the method comprising:

[0007] The first diagnostic window is determined based on the target message period of the CAN node messages sent by the target CAN node.

[0008] If no CAN node message is received from the target CAN node within the first diagnostic window, a second diagnostic window is opened, which is smaller than the first diagnostic window.

[0009] Based on the reception status of the CAN node messages in the second diagnostic window, update the target node timeout information corresponding to the target CAN node;

[0010] If the target node timeout information meets the reporting conditions, a communication anomaly report is made for the target CAN node.

[0011] On the other hand, embodiments of this application provide a CAN network communication diagnostic device, the device comprising:

[0012] The determination module is used to determine the first diagnostic window based on the target message period of the CAN node message sent by the target CAN node.

[0013] The module is configured to open a second diagnostic window if no CAN node message is received from the target CAN node within the first diagnostic window. The second diagnostic window is smaller than the first diagnostic window.

[0014] The update module is used to update the target node timeout information corresponding to the target CAN node based on the reception status of the CAN node messages in the second diagnostic window.

[0015] The reporting module is used to report communication anomalies to the target CAN node when the target node timeout information meets the reporting conditions.

[0016] On the other hand, embodiments of this application provide a vehicle that includes a CAN bus, a CAN node, and a CAN controller. The CAN node is connected to the CAN controller via the CAN bus, and the CAN bus is used to implement the CAN network communication diagnostic method as described above.

[0017] In related technologies, if the CAN node message sent by the target CAN node is not received in the diagnostic window, the CAN controller will no longer wait to receive the CAN node message, but will open a new diagnostic window to receive subsequent messages, which may lead to misjudgment of the CAN node message.

[0018] In this embodiment, if no CAN node message is received from the target CAN node in the first diagnostic window, the CAN controller opens a second diagnostic window to continue waiting to receive the CAN node message. This extends the diagnostic time for the CAN node message, avoiding discrepancies between the actual message reception and the reception in the diagnostic window due to a short diagnostic time, which could lead to false alarms about communication anomalies. This improves the accuracy of the target node timeout information and thus enhances the accuracy of network communication diagnostics. Attached Figure Description

[0019] Figure 1 This is a diagram illustrating CAN node message misjudgment.

[0020] Figure 2 This is a flowchart of a CAN network communication diagnostic method provided in an exemplary embodiment of this application;

[0021] Figure 3 This is a schematic diagram illustrating the window reception situation provided in an exemplary embodiment of this application;

[0022] Figure 4 This is a flowchart of a CAN network communication diagnostic method provided in another exemplary embodiment of this application;

[0023] Figure 5A flowchart illustrating the process of determining the window duration of the second diagnostic window is shown.

[0024] Figure 6 This is a flowchart of a CAN network communication diagnostic process provided in an exemplary embodiment of this application;

[0025] Figure 7 This is a structural block diagram of a CAN network communication diagnostic device provided in an exemplary embodiment of this application;

[0026] Figure 8 This is a structural block diagram of a vehicle provided in an exemplary embodiment of this application. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0028] The following is an explanation of the terms used in this application.

[0029] CAN Nodes: Used to receive, send, and process CAN information. Different CAN nodes send their respective CAN node messages to the CAN bus and determine which CAN node message should be received based on the message ID (Identifier). CAN nodes send CAN node messages according to their respective transmission cycles.

[0030] CAN controller: Controls the reception of CAN node messages sent by CAN nodes by triggering interrupts, and performs communication diagnosis and reports communication anomalies based on the reception of CAN node messages.

[0031] In this system, the sending and receiving of CAN node messages are asynchronous. The CAN node notifies the CAN controller of the CAN node message sending cycle, and the CAN controller determines the window duration for diagnostics based on this cycle. Subsequently, the CAN node sends CAN node messages according to the sending cycle, and the CAN controller diagnoses the message reception status according to the diagnostic window.

[0032] However, the CAN bus may be affected by factors such as network environment, load rate, and node priority, which may cause interference and fluctuations in the signal cycle, resulting in deviations in the arrival time of CAN node messages, which do not match the diagnostic window of the CAN controller.

[0033] In an exemplary example, Figure 1This is a diagram illustrating a CAN node message misjudgment scenario. The CAN node sends CAN node message 1 and CAN node message 2 at a fixed interval. The CAN controller determines that CAN node message 1 was successfully received within diagnostic window 1. CAN node message 2 arrives later, and the CAN controller, based on the absence of CAN node message 2 within diagnostic window 2, determines that CAN node message 2 was not received. Even if CAN node message 2 is received after diagnostic window 2 ends, the CAN controller still determines that CAN node message 2 was not received.

[0034] See Figure 2 , Figure 2 This is a flowchart illustrating a CAN network communication diagnostic method provided in an exemplary embodiment of this application. This embodiment uses the application of this method to a CAN controller as an example. The method includes the following steps.

[0035] Step 201: Determine the first diagnostic window based on the target message period of the CAN node message sent by the target CAN node.

[0036] In some embodiments, different CAN nodes send their respective CAN node messages on the CAN bus according to their respective message cycles. The target CAN node is the single CAN node for which the CAN controller performs network communication diagnostics. The CAN controller diagnoses the communication status based on the reception of the CAN node messages sent by that CAN node.

[0037] In some embodiments, the target message period refers to the transmission period followed by the target CAN node when sending CAN node messages. Optionally, the target CAN node may notify the CAN controller of the target message period before sending CAN node messages, so that the CAN controller can determine the first diagnostic window.

[0038] In some embodiments, the diagnostic window is used to characterize the duration for which the CAN controller monitors the reception of CAN node messages. A single diagnostic window is used to determine the reception status of a single CAN node message.

[0039] In one possible implementation, the CAN controller repeatedly opens the first diagnostic window to monitor the reception of each CAN node message sent by the target CAN node according to the target message cycle.

[0040] Optionally, the diagnostic duration of the first diagnostic window can be consistent with the duration of the target message cycle.

[0041] Step 202: If no CAN node message is received from the target CAN node in the first diagnostic window, open the second diagnostic window, which is smaller than the first diagnostic window.

[0042] In some embodiments, the first diagnostic window is used to initially confirm the reception status of CAN node messages. If a CAN node message sent by the target CAN node is received within the first diagnostic window, the CAN controller determines that the CAN node message has been successfully received.

[0043] Although the target CAN node sends CAN node messages according to the target message cycle, the CAN node messages on the CAN bus are prone to time deviations due to network environment influences, resulting in no CAN node messages being received within the first diagnostic window. The CAN controller will then determine that a single CAN node message reception has failed.

[0044] To avoid the above problems, if no CAN node message is received from the target CAN node in the first diagnostic window, the CAN controller opens a second diagnostic window to continuously monitor the CAN node messages sent by the target CAN node in order to confirm the reception of the delayed CAN node messages.

[0045] In some embodiments, the second diagnostic window allows for time discrepancies in the arrival of CAN node messages. It should be noted that the existence of the second diagnostic window does not affect the CAN node's ability to open the first diagnostic window and monitor subsequent CAN node messages sent by the target CAN node. To prevent the CAN controller from receiving subsequent CAN node messages from the target CAN node within the second diagnostic window, which could lead to misinterpreting earlier CAN node messages as successfully received, the second diagnostic window needs to be smaller than the first diagnostic window.

[0046] Step 203: Based on the reception status of CAN node messages in the second diagnostic window, update the target node timeout information corresponding to the target CAN node.

[0047] In some embodiments, target node timeout information is used to characterize the timeout status of the target CAN node.

[0048] Optionally, if a CAN node message is received within the second diagnostic window, the CAN controller determines that the reception was successful; if no CAN node message is received within the second diagnostic window, the CAN controller determines that a network anomaly caused a reception timeout.

[0049] In an exemplary example, such as Figure 3 As shown, the CAN controller performs a cyclic diagnostic task. If no CAN node message is received within the first diagnostic window 301, the CAN controller opens a second diagnostic window 302. This second diagnostic window 302 partially overlaps with the first diagnostic window 303, which is used to receive subsequent CAN node messages. If a CAN node message 304 is received within the second diagnostic window 302, the CAN controller determines that the reception was successful.

[0050] Step 204: If the target node timeout information meets the reporting conditions, report the communication anomaly to the target CAN node.

[0051] In one possible implementation, if the timeout period of the target CAN node reaches a time threshold, the CAN controller reports a communication anomaly to the target CAN node.

[0052] In another possible implementation, if the number of consecutive failures to receive CAN node messages by the target CAN node reaches a threshold, the CAN controller reports a communication anomaly to the CAN node.

[0053] In this embodiment, if no CAN node message is received from the target CAN node in the first diagnostic window, the CAN controller opens a second diagnostic window to continue waiting to receive the CAN node message. This extends the diagnostic time for the CAN node message, avoiding discrepancies between the actual message reception and the reception in the diagnostic window due to a short diagnostic time, which could lead to false alarms about communication anomalies. This improves the accuracy of the target node timeout information and thus enhances the accuracy of network communication diagnostics.

[0054] See Figure 4 , Figure 4 This is a flowchart of a CAN network communication diagnostic method provided in another exemplary embodiment of this application. The method includes the following steps.

[0055] Step 401: Determine the first diagnostic window based on the target message period of the CAN node message sent by the target CAN node.

[0056] Step 402: If no CAN node message is received from the target CAN node in the first diagnostic window, open the second diagnostic window, which is smaller than the first diagnostic window.

[0057] For a detailed description of steps 401 and 402, please refer to steps 201 and 202. The specific details of these steps will not be repeated in this embodiment.

[0058] Step 403: Based on the reception status of CAN node messages in the second diagnostic window, update the reception success flag and timeout count value corresponding to the target CAN node. The reception success flag is used to characterize the message reception status, and the timeout count value is used to characterize the number of message timeouts.

[0059] In some embodiments, the success flag and timeout count value are received as target node timeout information corresponding to the target CAN node.

[0060] Optionally, when the CAN controller performs network communication diagnostics on different CAN nodes on the CAN bus, the CAN controller can maintain a state machine for each different CAN node. This state machine is used to store the reception success flag so that the CAN controller can mark the reception status of the CAN node messages sent by each CAN node.

[0061] Optionally, the successful reception flag can indicate the real-time reception status of CAN node messages sent by the CAN node. In one possible implementation, the CAN controller updates the successful reception flag based on the message reception status within the first diagnostic window (including the first diagnostic window and the second diagnostic window), and then updates the successful reception flag again based on the message reception status within the first diagnostic window, and so on.

[0062] In some embodiments, different values ​​of the success flag are used to characterize different message reception statuses. This step may include the following sub-steps.

[0063] Step 403A: If a CAN node message is received in the second diagnostic window, set the successful reception flag bit corresponding to the target CAN node to the first value and update the timeout count value corresponding to the target CAN node.

[0064] In some embodiments, a success flag is associated with a target CAN node. Different target CAN nodes have their own success flags. For example, the CAN controller sets the success flag corresponding to the target CAN node to 1 to indicate successful reception.

[0065] Optionally, when a CAN node message is received within the first diagnostic window, the CAN controller can also set the successful reception flag corresponding to the target CAN node to the first value and update the timeout count value corresponding to the target CAN node, which helps to ensure the accuracy of the timeout count value.

[0066] In some embodiments, different CAN nodes have different node priorities. Higher-priority CAN nodes have priority in sending CAN node messages on the CAN bus, while lower-priority CAN nodes send their messages later, resulting in a time lag in CAN node message transmission.

[0067] Furthermore, the load rate of the CAN bus can also cause time deviations in CAN node messages. When the load rate is too high, the CAN bus transmission rate decreases, resulting in delays in CAN node messages.

[0068] Optionally, the timeout count value can be updated in two ways, taking into account node priority and load rate:

[0069] Case 1: If the target CAN node is a high-priority node and / or the CAN bus load rate is less than the load rate threshold, decrement the timeout count value corresponding to the target CAN node by one.

[0070] In some embodiments, the timeout count is used to determine whether a CAN node meets the reporting conditions. If the timeout count of a CAN node reaches the reporting conditions, the CAN controller reports a communication error.

[0071] Among these, high-priority nodes have higher network communication requirements than low-priority nodes. When a CAN message sent by a high-priority node times out, the CAN controller decrements the timeout counter for the target CAN node to ensure timely reporting of the communication anomaly. Resetting the timeout counter for the target CAN node to zero can easily lead to delayed reporting of communication anomalies by high-priority nodes, making it difficult to meet their communication needs.

[0072] Furthermore, the load rate affects the transmission efficiency of CAN node messages. When the load rate is below the load rate threshold, the probability of CAN node messages timing out is low, while the possibility of communication anomalies causing CAN node message timeouts is high. The CAN controller can improve communication reporting efficiency by decrementing the timeout counter value corresponding to the target CAN node by one. Resetting the timeout counter corresponding to the target CAN node to zero can easily increase the number of additional timeout checks.

[0073] Case 2: If the target CAN node is not a high-priority node and the CAN bus load rate is greater than the load rate threshold, the timeout count value corresponding to the target CAN node is set to zero.

[0074] When the target CAN node is not a high-priority node and the CAN bus load rate exceeds the load rate threshold, there is no need to report communication anomalies in a timely manner. Furthermore, an excessively high load rate reduces the transmission efficiency of CAN node messages, increasing the probability of the CAN controller misjudging communication anomalies. Setting the timeout count value corresponding to the target CAN node to zero and restarting the timeout count can reduce the impact of the load rate and improve the accuracy of diagnosing communication anomalies.

[0075] Step 403B: If no CAN node message is received in the second diagnostic window, set the reception success flag corresponding to the target CAN node to the second value and update the timeout count value corresponding to the target CAN node.

[0076] In some embodiments, the receive cost flag corresponds to the target CAN node. Different target CAN nodes correspond to their own receive success flags.

[0077] For example, the CAN controller sets the reception success flag corresponding to the target CAN node to 0, indicating reception failure. If a CAN node message sent by the first CAN node is received within the second diagnostic window, the CAN controller sets the reception success flag corresponding to the first CAN node to 1; if no CAN node message sent by the second CAN node is received within the second diagnostic window, the CAN controller sets the reception success flag corresponding to the second CAN node to 0. Note that since the target message periods of different target CAN nodes are different, the second diagnostic windows corresponding to different target CAN nodes are different.

[0078] Optionally, if no CAN node message is received in the second diagnostic window, the CAN controller can increment the timeout count value corresponding to the target CAN node to accumulate the number of message timeouts.

[0079] Step 404: If the timeout count value corresponding to the target CAN node reaches the counting threshold, it is determined that the reporting conditions are met, and the target CAN node is reported as a communication anomaly. The counting threshold is negatively correlated with the importance of the target CAN node.

[0080] In one possible implementation, high-priority nodes need to report communication anomalies promptly, indicating a higher level of importance. The CAN controller sets a lower counting threshold for high-priority nodes to ensure timely reporting of communication anomalies, and sets a higher counting threshold for low-priority nodes to improve the accuracy of reporting communication anomalies.

[0081] In another possible implementation, CAN nodes with high error rates need to successfully report communication anomalies, which is of higher importance. The CAN controller sets a lower counting threshold for CAN nodes with high error rates and a higher counting threshold for CAN nodes with low error rates, thereby improving the accuracy of communication anomaly reporting.

[0082] In this embodiment, CAN diagnoses communication anomalies by updating the successful reception flag and timeout count. Different values ​​are used for the successful reception flag to record message reception status. When the timeout count reaches a threshold, a communication anomaly is reported. This timeout count can be adjusted according to the communication needs of the CAN node, which helps improve the accuracy of communication anomaly reporting.

[0083] In some embodiments, the CAN controller configures multiple first diagnostic windows of the same window duration for the same CAN node to diagnose multiple CAN node messages sent by the CAN node. A second diagnostic window is used to accommodate deviations in the arrival time of CAN node messages, avoiding misjudgments of reception. Since the deviations in CAN node messages sent by different CAN nodes may vary, the window duration of the second diagnostic window corresponding to different CAN nodes can be different.

[0084] In some embodiments, the CAN controller needs to configure the window duration of the second diagnostic window when opening the second diagnostic window. The window duration of the second diagnostic window is related to at least one of the window duration of the first diagnostic window and the CAN network status.

[0085] Optionally, the duration of the second diagnostic window is shorter than the duration of the first diagnostic window. The duration of the second diagnostic window is proportional to the duration of the first diagnostic window.

[0086] Optionally, when the CAN network is in good condition, the error rate of the message cycle is low, and the window duration of the second diagnostic window can be set to a smaller value; when the CAN network is in poor condition, the error rate of the message cycle is high, and the window duration of the second diagnostic window can be set to a larger value.

[0087] Optionally, the duration of the second diagnostic window can be set to a maximum duration, or the duration of the second diagnostic window can be set within the maximum duration, depending on the specific circumstances.

[0088] Method 1: The CAN controller determines the window duration of the second diagnostic window based on the window duration of the first diagnostic window and the scaling factor. The window duration of the second diagnostic window is the product of the window duration of the first diagnostic window and the scaling factor.

[0089] In some embodiments, the scaling factor is used to characterize the proportional relationship between the second diagnostic window and the first diagnostic window. Optionally, the scaling factor can be used to determine the upper limit of the duration of the second diagnostic window.

[0090] In one possible implementation, the CAN controller sets the window duration of the second diagnostic window to the upper limit of the duration specified by the communication protocol standard, based on the error range in the uniformly defined communication protocol standard.

[0091] For example, as shown in Table 1, the window duration of the first diagnostic window is the same as the message cycle time of the target CAN node. The window duration of the second diagnostic window is determined according to the error range specified in the communication protocol standard. When the window duration of the first diagnostic window is 60ms, the CAN controller determines the scaling factor to be 0.1, and the upper limit of the second diagnostic window duration is 6ms. When the window duration of the first diagnostic window is 10ms, the CAN controller determines the scaling factor to be 0.3, and the upper limit of the second diagnostic window duration is 3ms.

[0092] Table 1

[0093]

[0094] Method 2: The CAN controller determines the upper limit of the second diagnostic window's duration based on the window duration of the first diagnostic window and the scaling factor. The upper limit is the product of the first diagnostic window's duration and the scaling factor. The second diagnostic window's duration is then determined based on the CAN network status and the upper limit. The second diagnostic window's duration is less than or equal to the upper limit.

[0095] The method for determining the upper limit of duration is the same as the method for determining the window duration of the second diagnostic window in Method 1 above, and will not be repeated here in this embodiment.

[0096] Optionally, the CAN network status can be determined based on at least one of load rate and transmission rate.

[0097] In one possible implementation, the CAN controller determines the window duration of the second diagnostic window, which is less than or equal to the upper limit of duration, based on the correspondence between the CAN network status, the upper limit of duration, and the window duration of the second diagnostic window.

[0098] In another possible implementation, the CAN controller determines the duration ratio based on the CAN network status. There is a correspondence between the CAN network status and the duration ratio. The window duration of the second diagnostic window is the product of the upper duration limit and the duration ratio.

[0099] Optionally, the CAN controller can also improve the matching degree between the window duration of the second diagnostic window and the CAN network state by utilizing a state evaluation model to determine an adjustment factor that matches the CAN network state.

[0100] See Figure 5 It shows a flowchart of the process for determining the window duration of the second diagnostic window, including the following steps.

[0101] Step 501: Obtain the load rate of the CAN bus and the node timeout information corresponding to each CAN node.

[0102] In some embodiments, the load rate of the CAN bus and the node timeout information corresponding to each CAN node are used to characterize the CAN network status.

[0103] Optionally, the node timeout information may include a successful reception flag and a timeout count. The successful reception flag is determined based on the message reception status, and the timeout count is determined by counting the number of message timeouts, i.e., the number of message reception failures.

[0104] Optionally, the load rate of the CAN bus can be determined based on the uploading status of CAN node messages.

[0105] Step 502: Input the load rate of the CAN bus and the node timeout information corresponding to each CAN node into the state evaluation model to obtain the adjustment factor output by the state evaluation model. The state evaluation model is trained based on the sample load rate, the sample node timeout information corresponding to the sample CAN node and the sample adjustment factor. The sample adjustment factor is determined based on the sample window duration and the upper limit of the sample duration.

[0106] The sample load rate and the sample node timeout information corresponding to the sample CAN node can include different CAN network states. The sample adjustment factor is an adjustment factor of different sizes adapted to different network states.

[0107] Optionally, the sample adjustment factor can be the product of the sample window duration and the upper limit of the sample duration. The upper limit of the sample duration can be determined based on the error range of the message cycle time in the uniformly defined communication protocol standard.

[0108] During the training of the state assessment model, the sample adjustment factor is used to update the model parameters of the state assessment model in reverse, after the sample load rate and the sample node timeout information corresponding to the sample CAN node are input into the state assessment model, combined with the model output results.

[0109] Step 503: Based on the duration limit and adjustment factor, determine the window duration of the second diagnostic window. The window duration of the second diagnostic window is the product of the duration limit and the adjustment factor.

[0110] In one possible implementation, the CAN controller determines the upper limit of duration based on the error range in a uniformly defined communication protocol standard.

[0111] For example, as shown in Table 1, the window duration of the first diagnostic window is the same as the message cycle time of the target CAN node. The window duration of the second diagnostic window is determined according to the error range specified in the communication protocol standard. If the window duration of the first diagnostic window is 60ms, the maximum duration of the second diagnostic window is 6ms. If the window duration of the first diagnostic window is 10ms, the maximum duration of the second diagnostic window is 3ms.

[0112] In this embodiment, the CAN controller can configure the window duration of the second diagnostic window based on the window duration of the first diagnostic window and / or the CAN network status, thereby improving the rationality of the second diagnostic window's window duration. The window duration of the second diagnostic window can be configured as an upper limit to reduce the false positive rate, or it can be configured to be within the upper limit and determined in conjunction with the CAN network status, ensuring that the window duration matches the CAN network status. Furthermore, the window duration of the second diagnostic window can also utilize a state evaluation model to determine an adjustment factor adapted to the current network status, adjusting the window duration of the second diagnostic window to further improve its rationality.

[0113] See Figure 6 , Figure 6 This is a flowchart of a CAN network communication diagnostic process provided in an exemplary embodiment of this application. The process includes the following steps.

[0114] Step 601, the application runs.

[0115] The application is used to perform CAN network communication diagnostics on the target CAN node. The CAN controller performs logic control tasks upon application startup.

[0116] Step 602: The CAN controller determines whether the running time has reached 3 seconds.

[0117] If the runtime reaches 3 seconds, proceed to step 603.

[0118] If the running time is less than 3 seconds, proceed to step 601.

[0119] Step 603: The CAN controller determines whether it has received a CAN node message.

[0120] Upon receiving a CAN node message, proceed to step 604.

[0121] If no CAN node message is received, proceed to step 605.

[0122] Step 604: Successful reception flag set to 1, node timeout counter cleared to 0.

[0123] Step 605: Delay the maximum deviation time of the CAN node cycle.

[0124] If no CAN node message is received within the first diagnostic window, a second diagnostic window is opened to extend the diagnostic time. The window duration of the first diagnostic window is the same as the CAN node message period. The window duration of the second diagnostic window is determined based on the maximum allowable deviation time of the CAN node message period.

[0125] For example, with a maximum deviation time of 3ms, the CAN controller determines the window duration of the second diagnostic window to be 3ms, and delays the diagnostic time for message reception by 3ms.

[0126] Step 606: CAN node message received.

[0127] If a CAN node message is received in the second diagnostic window, proceed to step 607.

[0128] If no CAN node message is received in the second diagnostic window, proceed to step 608.

[0129] Step 607: Successful reception flag set to 1, node timeout counter cleared to 0.

[0130] Step 608: Successful reception flag position 0, node timeout counter incremented by 1.

[0131] See Figure 7 , Figure 7 This is a structural block diagram of a CAN network communication diagnostic device provided in an exemplary embodiment of this application. The device includes the following modules.

[0132] The determination module 701 is used to determine the first diagnostic window based on the target message period of the CAN node message sent by the target CAN node.

[0133] The enabling module 702 is used to enable a second diagnostic window when no CAN node message sent by the target CAN node is received in the first diagnostic window. The second diagnostic window is smaller than the first diagnostic window.

[0134] The update module 703 is used to update the target node timeout information corresponding to the target CAN node based on the reception status of the CAN node messages in the second diagnostic window.

[0135] The reporting module 704 is used to report a communication anomaly to the target CAN node when the target node timeout information meets the reporting conditions.

[0136] Optionally, the update module 703 is further configured to:

[0137] Based on the reception status of the CAN node messages in the second diagnostic window, update the reception success flag and timeout count value corresponding to the target CAN node. The reception success flag is used to characterize the message reception status, and the timeout count value is used to characterize the number of message timeouts.

[0138] Optionally, the update module 703 is further configured to:

[0139] If the CAN node message is received in the second diagnostic window, the successful reception flag bit corresponding to the target CAN node is set to the first value, and the timeout count value corresponding to the target CAN node is updated.

[0140] If no CAN node message is received within the second diagnostic window, the successful reception flag corresponding to the target CAN node is set to a second value, and the timeout count value corresponding to the target CAN node is updated.

[0141] Optionally, the update module 703 is further configured to:

[0142] Increment the timeout count value corresponding to the target CAN node by one;

[0143] If the target CAN node is a high-priority node, and / or the CAN bus load rate is less than the load rate threshold, the timeout count value corresponding to the target CAN node is decremented by one.

[0144] If the target CAN node does not belong to the high-priority node and the load rate of the CAN bus is greater than the load rate threshold, the timeout count value corresponding to the target CAN node is set to zero.

[0145] Optionally, the reporting module 704 is further configured to:

[0146] If the timeout count value corresponding to the target CAN node reaches the counting threshold, it is determined that the reporting condition is met, and the target CAN node is reported as having a communication anomaly. The counting threshold is negatively correlated with the importance of the target CAN node.

[0147] Optionally, the device further includes a configuration module for:

[0148] Configure the window duration of the second diagnostic window, which is related to at least one of the window duration of the first diagnostic window and the CAN network status.

[0149] Optionally, the configuration module is further configured to:

[0150] Based on the window duration of the first diagnostic window and the scaling factor, the window duration of the second diagnostic window is determined, and the window duration of the second diagnostic window is the product of the window duration of the first diagnostic window and the scaling factor.

[0151] or,

[0152] Based on the window duration of the first diagnostic window and the scaling factor, the upper limit of the window duration of the second diagnostic window is determined, wherein the upper limit of the duration is the product of the window duration of the first diagnostic window and the scaling factor; based on the CAN network status and the upper limit of the duration, the window duration of the second diagnostic window is determined, wherein the window duration of the second diagnostic window is less than or equal to the upper limit of the duration.

[0153] Optionally, the determining module 701 is further configured to:

[0154] Obtain the load rate of the CAN bus and the node timeout information corresponding to each CAN node;

[0155] The load rate of the CAN bus and the node timeout information corresponding to each CAN node are input into the state evaluation model to obtain the adjustment factor output by the state evaluation model. The state evaluation model is trained based on the sample load rate, the sample node timeout information corresponding to the sample CAN node, and the sample adjustment factor. The sample adjustment factor is determined based on the sample window duration and the upper limit of the sample duration.

[0156] Based on the upper limit of duration and the adjustment factor, the window duration of the second diagnostic window is determined, and the window duration of the second diagnostic window is the product of the upper limit of duration and the adjustment factor.

[0157] In summary, in this embodiment of the application, if no CAN node message sent by the target CAN node is received in the first diagnostic window, the CAN controller opens a second diagnostic window to continue waiting to receive the CAN node message. This prolongs the diagnostic time for the CAN node message, avoiding discrepancies between the actual message reception and the reception in the diagnostic window due to a short diagnostic time, which could lead to false alarms about communication anomalies. This helps improve the accuracy of the target node timeout information and thus improves the accuracy of network communication diagnosis.

[0158] See Figure 8 , Figure 8 This is a structural block diagram of a vehicle provided in an exemplary embodiment of this application. The vehicle 800 includes a CAN bus 801, a CAN node 802, and a CAN controller 803. The CAN node 802 is connected to the CAN controller 803 through the CAN bus 801. The CAN bus 801 is used to implement the CAN network communication diagnostic methods provided in the above embodiments.

[0159] In an exemplary embodiment, a computer-readable storage medium is also provided, which stores at least one piece of program code that is loaded and executed by a processor to implement the CAN network communication diagnostic method in the above embodiments.

[0160] In an exemplary embodiment, a computer program product is also provided, which stores at least one piece of program code, which is loaded and executed by a processor to implement the CAN network communication diagnostic method in the above embodiments.

[0161] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0162] The above description is only for the purpose of enabling those skilled in the art to understand the technical solution of this application, and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A CAN network communication diagnosis method characterized by, The method comprises: determining a first diagnosis window based on a target message period in which a target CAN node sends a CAN node message; starting a second diagnosis window in a case where the CAN node message sent by the target CAN node is not received within the first diagnosis window, the second diagnosis window being smaller than the first diagnosis window; in a case where the CAN node message is received within the second diagnosis window, setting a receiving success flag corresponding to the target CAN node to a first value, and in a case where the target CAN node belongs to a high priority node and / or a load rate of a CAN bus is smaller than a load rate threshold, reducing a timeout count value corresponding to the target CAN node by one, the receiving success flag being used to represent a message receiving condition, and the timeout count value being used to represent a message timeout number; in a case where the target CAN node does not belong to the high priority node and the load rate of the CAN bus is greater than the load rate threshold, setting the timeout count value corresponding to the target CAN node to zero; in a case where the CAN node message is not received within the second diagnosis window, setting the receiving success flag corresponding to the target CAN node to a second value, and increasing the timeout count value corresponding to the target CAN node by one; in a case where target node timeout information corresponding to the target CAN node meets a reporting condition, performing communication exception reporting on the target CAN node, the target node timeout information comprising the receiving success flag and the timeout count value.

2. The method of claim 1, wherein, The communication exception reporting on the target CAN node in a case where the target node timeout information corresponding to the target CAN node meets a reporting condition comprises: in a case where the timeout count value corresponding to the target CAN node reaches a count threshold, determining that the reporting condition is met, and performing communication exception reporting on the target CAN node, the count threshold being in a negative correlation with an importance degree of the target CAN node.

3. The method according to claim 1 or 2, characterized in that, Before the second diagnosis window is started, the method further comprises: configuring a window duration of the second diagnosis window, the window duration of the second diagnosis window being related to at least one of a window duration of the first diagnosis window and a CAN network state.

4. The method of claim 3, wherein, The configuration of the window duration of the second diagnosis window comprises: determining the window duration of the second diagnosis window based on the window duration of the first diagnosis window and a proportion factor, the window duration of the second diagnosis window being a product of the window duration of the first diagnosis window and the proportion factor; or, determining a duration upper limit of the window duration of the second diagnosis window based on the window duration of the first diagnosis window and a proportion factor, the duration upper limit being a product of the window duration of the first diagnosis window and the proportion factor, and determining the window duration of the second diagnosis window based on the CAN network state and the duration upper limit, the window duration of the second diagnosis window being smaller than or equal to the duration upper limit.

5. The method of claim 4, wherein, The determining the window length of the second diagnostic window based on the CAN network state and the upper limit of the time length comprises: obtaining a load rate of the CAN bus and node timeout information corresponding to each CAN node; inputting the load rate of the CAN bus and the node timeout information corresponding to each CAN node into a state evaluation model to obtain an adjustment factor output by the state evaluation model, the state evaluation model being trained based on sample load rates, sample node timeout information corresponding to sample CAN nodes, and sample adjustment factors, the sample adjustment factors being determined based on sample window lengths and a sample upper limit of the time length; determining the window length of the second diagnostic window based on the upper limit of the time length and the adjustment factor, the window length of the second diagnostic window being a product of the upper limit of the time length and the adjustment factor.

6. A CAN network communication diagnosis apparatus characterized by comprising: The device comprises: a determination module configured to determine a first diagnostic window based on a target message period of a CAN node message sent by a target CAN node; an opening module configured to open a second diagnostic window in a case where the CAN node message sent by the target CAN node is not received within the first diagnostic window, the second diagnostic window being smaller than the first diagnostic window; an updating module configured to set a receiving success flag corresponding to the target CAN node to a first value in a case where the CAN node message is received within the second diagnostic window, and to decrease a timeout count value corresponding to the target CAN node by one in a case where the target CAN node belongs to a high-priority node and / or a load rate of a CAN bus is less than a load rate threshold, the receiving success flag being used to represent a message receiving condition, and the timeout count value being used to represent a message timeout number; to set the timeout count value corresponding to the target CAN node to zero in a case where the target CAN node does not belong to the high-priority node and the load rate of the CAN bus is greater than the load rate threshold; and to set the receiving success flag corresponding to the target CAN node to a second value and increase the timeout count value corresponding to the target CAN node by one in a case where the CAN node message is not received within the second diagnostic window; a reporting module configured to report a communication exception of the target CAN node in a case where target node timeout information corresponding to the target CAN node meets a reporting condition, the target node timeout information comprising the receiving success flag and the timeout count value.

7. A vehicle characterized by comprising: The vehicle comprises a CAN bus, CAN nodes, and a CAN controller, the CAN nodes being connected to the CAN controller through the CAN bus, and the CAN bus being used to implement the CAN network communication diagnosis method according to any one of claims 1 to 5.

Images