Can communication system, method and vehicle based on autosar architecture

Abstract

The embodiment of the present application relates to the technical field of vehicle communication, and discloses a CAN communication system and method based on an AUTOSAR architecture and a vehicle, the system comprising: an event management module, encapsulating setting, waiting and clearing interfaces of AUTOSAR operating system events, and providing sending completion event interfaces, receiving completion event interfaces and timeout event interfaces; a timeout monitoring module, reading timeout threshold values output by a configuration management module, monitoring CAN communication states, and generating CAN communication timeout events and sending the events to the timeout event interfaces when detecting sending timeout or receiving timeout; the configuration management module, storing and providing timeout threshold values to the timeout monitoring module; and a diagnosis processing module, acquiring CAN communication timeout events through the timeout event interfaces, recording diagnosis information and executing communication recovery strategies. The technical scheme of the present application can improve the flexibility of CAN communication timeout judgment and the integrity of diagnosis information.

Description

Technical Field

[0001] This invention relates to the field of vehicle communication technology, and specifically to a CAN communication system, method, and vehicle based on the AUTOSAR architecture. Background Technology

[0002] In automotive electronic control systems, especially in the field of new energy vehicle controllers, CAN (Controller Area Network) communication technology serves as a core data interaction method, and its reliability and real-time performance directly affect the overall vehicle safety performance. As the electronic architecture of new energy vehicles evolves towards a domain-centralized model, the communication mode between the controller and bridging chips (such as BMS bridging chips and motor drive chips) has shifted from traditional periodic message transmission and reception to a more complex event-driven interaction mode. These chips typically require precise configuration during the initialization phase and dynamically transmit and receive single or multiple CAN messages according to functional requirements during operation, placing higher demands on communication real-time performance and fault diagnosis capabilities. Summary of the Invention

[0003] In view of the shortcomings of the prior art, the purpose of this application is to provide a CAN communication system, method and vehicle based on AUTOSAR architecture to solve the timeout diagnosis of the prior art for flexible real-time scenarios, and improve the flexibility of CAN communication timeout judgment and the completeness of diagnostic information.

[0004] In a first aspect, embodiments of this application provide a CAN communication system based on the AUTOSAR architecture, comprising:

[0005] The event management module encapsulates the settings, waiting, and clearing interfaces for AUTOSAR operating system events, and provides a send completion event interface, a receive completion event interface, and a timeout event interface. Among them, the CAN transmit / receive interrupt logic reports the message transmit / receive completion signal through the send completion event interface and the receive completion event interface, and the CAN communication timeout event generated by the timeout monitoring module is transmitted through the timeout event interface.

[0006] The timeout monitoring module reads the timeout threshold output by the configuration management module, monitors the CAN communication status, and generates a CAN communication timeout event and sends it to the timeout event interface when a send timeout or receive timeout is detected.

[0007] The configuration management module stores and provides timeout thresholds to the timeout monitoring module;

[0008] The diagnostic processing module obtains CAN communication timeout events through the timeout event interface, records diagnostic information, and executes communication recovery strategies.

[0009] In the above technical solution, a standardized event interaction mechanism is constructed by uniformly encapsulating the AUTOSAR operating system event interface through the event management module. This enables the CAN transmit and receive interrupt logic to accurately report the message transmission and reception status through the predefined transmit completion event interface and receive completion event interface. At the same time, the timeout event generated by the timeout monitoring module can also be efficiently transmitted through the dedicated timeout event interface, thereby establishing a standardized and unified event processing framework.

[0010] Specifically, this solution fully utilizes the multi-event waiting mechanism of the AUTOSAR extended task, enabling a single diagnostic processing task to simultaneously monitor the state changes of multiple communication events. This completely eliminates the traditional design of creating a separate task for each timeout monitoring event or employing an inefficient polling mechanism, significantly reducing system resource consumption and memory overhead. The immediacy of event triggering ensures rapid response capabilities for timeout judgment, effectively solving the task scheduling delay problem inherent in traditional timeout judgment mechanisms based on COM module configuration, and greatly improving the accuracy and reliability of timeout detection.

[0011] Furthermore, this event-driven unified management architecture significantly simplifies system design complexity, eliminates the scattered timeout processing logic in traditional solutions, and significantly improves real-time performance in multi-channel, multi-message concurrent communication scenarios. In application scenarios such as new energy vehicles, which have extremely high requirements for communication reliability, this solution not only provides strong technical support but also lays a clear and flexible architectural foundation for subsequent functional expansion and system maintenance.

[0012] In one embodiment, the configuration management module is further configured to dynamically adjust the timeout threshold based on the CAN bus load rate and vehicle operating status.

[0013] In the above technical solution, the dynamic correction mechanism of the timeout threshold through the configuration management module enables the system to adaptively adjust the timeout judgment criteria according to changes in the actual communication environment. When the CAN bus load rate increases, the system automatically extends the timeout threshold to avoid misjudgments caused by bus congestion. When the vehicle is in different operating states, the configuration management module can intelligently adjust the threshold parameters according to the current operating condition characteristics to ensure the accuracy and rationality of the timeout judgment. This dynamic adjustment mechanism based on real-time operating conditions completely solves the limitations of traditional static threshold configuration in complex and ever-changing application scenarios, significantly improving the adaptability and robustness of timeout diagnosis.

[0014] In one embodiment, the event management module provides a timeout threshold update event interface, which is used to receive a threshold update trigger signal sent by the configuration management module when a preset change is detected in the CAN bus load rate or vehicle operating status, and associate the timeout threshold update event interface with the extended task, so that after receiving the threshold update event, the extended task calls the configuration management module to re-obtain the corrected timeout threshold and update it to the timeout monitoring module.

[0015] In the above technical solution, when the CAN bus load rate or vehicle operating status changes according to a preset schedule, the configuration management module actively triggers the update process through the threshold update event interface. Upon receiving this event, the extended task can immediately call the configuration management module to obtain the latest corrected threshold and synchronize it to the timeout monitoring module. This event-driven update method abandons the traditional polling detection mechanism, significantly reducing system resource consumption while ensuring the timeliness and accuracy of threshold adjustment.

[0016] In one embodiment, the diagnostic information recorded by the diagnostic processing module includes context information when a timeout occurs. The context information includes at least the system operating status, the current communication load status, historical timeout pattern statistics, and diagnostic parameters for communication failure root cause analysis and system recovery decisions.

[0017] In the aforementioned technical solution, the comprehensive context information acquisition mechanism significantly improves the accuracy and efficiency of fault diagnosis. When communication anomalies occur, the diagnostic system can identify potential periodic or intermittent fault characteristics based on historical timeout patterns, determine whether the communication delay is caused by resource contention by combining the current system load status, and analyze the system operating status to determine whether the fault is related to a specific operating condition. This multi-dimensional diagnostic information can not only quickly distinguish between different fault types such as hardware failures, software anomalies, and network congestion, but also provide a scientific basis for formulating targeted communication recovery strategies, greatly shortening fault recovery time and improving the reliability and maintainability of the entire CAN communication system.

[0018] In one embodiment, the communication recovery strategy executed by the diagnostic processing module adopts a hierarchical processing mechanism, including:

[0019] Level 1 recovery strategy: When a single communication timeout is detected, retransmit the failed message or replace the message that was not received after the timeout with a preset default value;

[0020] Second-level recovery strategy: When the first-level recovery strategy fails for a preset number of consecutive times, the CAN controller is reset to restore the communication link state;

[0021] Third-level recovery strategy: When the second-level recovery strategy fails, switch to the redundant CAN communication channel or notify the upper-level application system to perform system-level fault handling and record the corresponding diagnostic fault codes.

[0022] In the aforementioned technical solution, the first-level recovery strategy targets intermittent, transient communication anomalies, employing a lightweight message retransmission or default value replacement mechanism to automatically repair within milliseconds, avoiding unnecessary system disturbances and maximizing the continuity of control signals. The second-level recovery strategy, upon detecting a persistent communication failure, uses a precise intervention method—resetting the CAN controller—to clear the abnormal state of the hardware or driver layer, restoring the basic functions of the communication link while avoiding the overhead of restarting the entire vehicle system. The third-level recovery strategy, as the ultimate safeguard, initiates redundant channel switching or system-level fault handling when the first two strategies fail, ensuring the safe degraded operation of critical functions and providing the driver with sufficient warning time and a safety buffer. This hierarchical and progressive recovery mechanism not only significantly reduces the risk of complete system failure due to a single point of failure but also significantly reduces unnecessary system restarts and functional interruptions through precise fault isolation and targeted handling. In actual operation, the solution can intelligently identify the severity and scope of the fault and automatically select the optimal recovery path. It not only ensures the real-time requirements of critical control signals, but also provides a reasonable recovery time window for non-critical functions, thereby achieving a balance between communication reliability and system stability in a complex and ever-changing vehicle environment.

[0023] In one embodiment, the event management module adopts an interrupt-driven mechanism. When the CAN controller generates a transmit completion interrupt or a receive completion interrupt, it triggers the corresponding transmit completion event or receive completion event through a callback function, and clears the corresponding interrupt flag after the event is processed.

[0024] In the above technical solution, the interrupt-driven mechanism fully utilizes the low-latency characteristics of hardware interrupts, triggering event processing within microseconds. This avoids the unavoidable periodic delays inherent in polling mechanisms, making it particularly suitable for vehicle control scenarios with extremely high real-time requirements. Through the standardized design of callback functions, the modularity and scalability of the event processing logic are achieved, enabling precise classification and differentiated processing of different types of communication events. Simultaneously, the mechanism of promptly clearing the interrupt flag after event processing effectively prevents interrupt nesting and repeated triggering, ensuring the consistency and stability of the system state. This interrupt-based event management architecture not only significantly improves CPU resource utilization efficiency, allowing the processor to focus on other critical tasks when there are no communication events, but also ensures the integrity and timeliness of communication data through precise timing control.

[0025] In one embodiment, the timeout monitoring module includes a timer driver interface, which includes a timer initialization unit, a timer start unit, a timer stop unit, and a timeout interrupt callback unit. The timer initialization unit completes the basic timer configuration during the system initialization phase. The timer start unit starts timeout monitoring after a CAN message transmission request or CAN message reception request is sent. The timer stop unit stops timing when a transmission completion event or reception completion event is received. The timeout interrupt callback unit triggers a timeout event and calls the diagnostic processing module when the timer times out.

[0026] In the above technical solution, the timer initialization unit completes basic configuration during system startup, ensuring reasonable allocation of timer resources and parameter presets; the timer start unit is tightly coupled with CAN communication events, starting precise timing the instant a message transmission or reception request is issued, eliminating monitoring blind spots; the timer stop unit, through an event-driven mechanism, immediately terminates timing upon receiving a transmission completion or reception completion event, avoiding unnecessary resource consumption; and the timeout interrupt callback unit responds quickly through a hardware interrupt mechanism when a timeout occurs, ensuring the real-time nature and priority of fault handling. This setup brings multiple technical advantages: First, the combination of hardware timers and interrupt mechanisms achieves microsecond-level precision timeout detection, far exceeding the performance of traditional software polling solutions; second, the event-driven start / stop mechanism significantly reduces CPU load, consuming almost no system resources when there is no communication activity; third, the modular design decouples timer functions from business logic, improving code maintainability and portability; finally, the deep integration of timeout interrupt callbacks and diagnostic processing modules ensures that a tiered recovery strategy can be immediately initiated when a fault occurs, minimizing the impact of communication anomalies on the entire vehicle system.

[0027] Secondly, this application provides a CAN communication method based on the AUTOSAR architecture, comprising: encapsulating the AUTOSAR operating system event interface through an event management module to provide a transmit completion event interface, a receive completion event interface, and a timeout event interface; storing and providing timeout thresholds through a configuration management module; reading the timeout thresholds through a timeout monitoring module to monitor the CAN communication status, and generating a CAN communication timeout event when a transmit timeout or receive timeout is detected; and obtaining the CAN communication timeout event through a diagnostic processing module, recording diagnostic information, and executing a communication recovery strategy.

[0028] Thirdly, an embodiment of this application provides a vehicle that includes the aforementioned CAN communication system based on the AUTOSAR architecture. Attached Figure Description

[0029] To more clearly illustrate the technical solutions in the embodiments of this application or the background art, the accompanying drawings used in the embodiments of this application will be described below.

[0030] Figure 1 This is a schematic diagram of the CAN communication system based on the AUTOSAR architecture disclosed in an embodiment of this application;

[0031] Figure 2 This is a schematic diagram of the initialization process of a CAN communication system based on the AUTOSAR architecture disclosed in an embodiment of this application;

[0032] Figure 3 Update the sequence graph to the timeout threshold;

[0033] Figure 4 Sequence diagram for CAN message transmission;

[0034] Figure 5 This is a sequence diagram of CAN message reception.

[0035] Figure 6 This is a diagram of CAN message timeout sequences.

[0036] Explanation of reference numerals in the attached figures:

[0037] 10 - Event Management Module, 20 - Timeout Monitoring Module, 30 - Configuration Management Module, 40 - Diagnostic Processing Module. Detailed Implementation

[0038] The embodiments of this application are described below with reference to the accompanying drawings.

[0039] This application discloses a CAN communication system, method, and vehicle based on the AUTOSAR architecture. It can be widely applied to CAN bus data interaction scenarios of various vehicle controllers, BMS bridge chips, motor drive chips, and other vehicle-mounted devices under the centralized electronic architecture of new energy vehicles. It is mainly used to solve the technical problems of poor flexibility of traditional vehicle-mounted CAN communication timeout judgment mechanism, single diagnostic information, weak fault recovery capability, high system resource consumption, and insufficient real-time performance. It can adapt to the complex event-driven CAN message interaction requirements of new energy vehicles and effectively improve the reliability, real-time performance, and maintainability of vehicle-mounted CAN communication.

[0040] In one embodiment, see Figure 1As shown, this application provides a CAN communication system based on the AUTOSAR architecture, which is adapted to the standard AUTOSAR layered architecture and follows the AUTOSAR operating system's task scheduling and event interaction specifications. The system adopts a modular and loosely coupled design, including four major functional modules: an event management module 10, a timeout monitoring module 20, a configuration management module 30, and a diagnostic processing module 40. Each module performs its function independently and interacts in a standardized manner. It does not need to rely on the fixed timeout configuration of the traditional COM module, and can realize flexible and controllable CAN communication timeout monitoring, full-dimensional fault diagnosis, and hierarchical self-healing recovery.

[0041] Among them, the event management module 10 is the core scheduling hub of this system. It is based on the standard AUTOSAR operating system and completes secondary encapsulation. It uniformly encapsulates the underlying interfaces of the AUTOSAR operating system's native event setting, event waiting, and event clearing, shielding the differences in underlying operating system adaptation. At the same time, it provides three sets of dedicated event interfaces for CAN communication service scenarios, namely the send completion event interface, the receive completion event interface, and the timeout event interface, to build a dedicated CAN communication event-driven scheduling system.

[0042] In actual operation, the CAN controller's transmit / receive interrupt logic establishes a unique interaction path with the event management module 10. When a CAN message is sent or received, the hardware triggers the corresponding transmit / receive interrupt. By calling the transmit completion event interface and receive completion event interface of the event management module, the message transmit / receive completion signal is reported in real time, achieving immediate feedback on the normal communication status of the message. At the same time, the timeout monitoring module 20 monitors the generated CAN communication timeout fault events, which can be efficiently and accurately transmitted through the timeout event interface of the event management module 20, realizing unified collection and scheduling of normal communication events and fault timeout events.

[0043] The timeout monitoring module 20 is the core unit for system fault monitoring, and it interfaces with the configuration management module 30 and the event management module 10 throughout the process. During operation, the timeout monitoring module 20 reads the standard timeout threshold output by the configuration management module 30 in real time, continuously monitors the message transmission and reception communication status of the CAN bus, and accurately determines whether the transmission and reception timing of each CAN message frame exceeds the standard. When a message transmission timeout or message reception timeout is detected, a corresponding CAN communication timeout event is immediately generated and actively pushed to the timeout event interface of the event management module 10, completing the fault event reporting trigger and providing accurate fault input for subsequent diagnosis and recovery processing.

[0044] The configuration management module 30 is the core unit for system parameter configuration. It adopts an independent parameter storage and output architecture, specifically designed to store timeout threshold parameters corresponding to various CAN communication scenarios. Based on system operational requirements, it stably and in real-time outputs valid timeout thresholds to the timeout monitoring module 20, providing an accurate judgment benchmark for the timeout monitoring logic. This module is independent of the monitoring and diagnostic business logic, achieving complete decoupling between parameter configuration and business processing. This avoids the problems of poor adaptability and high modification risks caused by hard-coded parameters and coupling between parameters and business logic in traditional solutions.

[0045] The diagnostic processing module 40 is the core unit for system fault handling and self-healing. It monitors global CAN communication timeout events in real time through the timeout event interface of the event management module 10. Once a timeout fault signal is captured, the fault handling process is immediately initiated. On one hand, it fully records all diagnostic information corresponding to this communication anomaly, preserving evidence for fault tracing; on the other hand, it intelligently executes matching communication recovery strategies according to preset fault handling rules, achieving automatic repair of CAN communication faults and minimizing the impact of communication anomalies on the vehicle's control functions.

[0046] This embodiment constructs a standardized and unified CAN communication event interaction framework through the event management module 10. Relying on the AUTOSAR extended task multi-event waiting mechanism, a single diagnostic processing extended task can simultaneously monitor three event states: message transmission completion, message reception completion, and communication timeout. This completely eliminates the design pattern of traditional CAN communication solutions that create separate tasks for various timeout monitoring or use inefficient polling monitoring. Compared to existing technologies, this solution eliminates redundant task resources, significantly reducing system CPU utilization and memory overhead. Simultaneously, relying on the immediacy of hardware event triggering, it completely solves the problems of task scheduling delay and low timeout judgment accuracy existing in the fixed-configuration timeout mechanism of traditional COM modules, significantly improving the real-time performance and accuracy of timeout detection. Furthermore, the modular decoupling design simplifies the system architecture complexity, effectively avoiding timing errors and signal loss problems in multi-channel, multi-message concurrent communication scenarios, greatly improving the stability of CAN communication under complex automotive conditions. Moreover, the architecture has strong scalability, facilitating subsequent functional iterations and platform reuse.

[0047] As an optional implementation of this application, the configuration management module 30 dynamically updates the timeout threshold based on the message length and the number of message frames. The configuration management module 30 pre-stores three types of baseline timing parameters: message byte transmission unit time, inter-frame interval, and reserved time interval. For a single complete CAN interaction process, it calculates the dedicated timeout threshold matching this interaction in real time using the following formula: Timeout threshold = Total length of transmitted message bytes × Message byte transmission unit time + Number of transmitted message frames × Inter-frame interval + Total length of received message bytes × Message byte transmission unit time + Number of received message frames × Inter-frame interval + Reserved time interval.

[0048] As an optional implementation of this application, the configuration management module 30 is functionally optimized and upgraded. The configuration management module 30 not only has the basic functions of storing timeout thresholds and fixed output, but is also configured to dynamically correct and update timeout thresholds according to the real-time CAN bus load rate and the actual operating status of the vehicle, so as to achieve adaptive adaptation of timeout judgment criteria.

[0049] In practice, the configuration management module 30 collects CAN bus monitoring data in real time, accurately calculates the current bus load rate, and simultaneously acquires vehicle operating condition signals, including vehicle idling, acceleration, deceleration, steady-state driving, and fault warnings. Based on a preset adaptive correction algorithm, the initially fixed static timeout threshold is dynamically adjusted.

[0050] For example, when a continuous increase in CAN bus load rate and congestion in bus data transmission are detected, the CAN message transmission and reception timeout threshold is automatically and appropriately extended to avoid message transmission delays caused by bus congestion and to prevent false alarms where normal communication delays are mistakenly judged as communication timeouts. When the vehicle is in different operating conditions, the optimal timeout threshold is intelligently matched based on the communication timing requirements and safety levels of each operating condition. For example, when the vehicle is traveling at high speed or the power system is working, a high-precision short-time threshold is adapted to ensure the real-time communication of safety-related messages. When the vehicle is idling, a more lenient threshold is adapted to reduce invalid fault reports.

[0051] This embodiment completely breaks through the limitations of traditional static threshold configuration by using a dynamic timeout threshold correction mechanism. It solves the pain point that fixed thresholds cannot adapt to complex and ever-changing vehicle communication scenarios, enabling the system timeout judgment criteria to be adaptively adjusted according to the bus environment and vehicle operating conditions. This greatly improves the flexibility, rationality and robustness of CAN communication timeout diagnosis, while taking into account both communication real-time performance and fault judgment accuracy.

[0052] Furthermore, the event interaction system of the event management module 10 is expanded. The event management module 10 is additionally configured with a timeout threshold update event interface, which is specifically used to adapt to dynamic threshold update business scenarios, realize event-driven triggering of threshold updates, and replace the traditional inefficient polling detection mechanism.

[0053] In practice, the system pre-configures thresholds for judging changes in bus load rate and vehicle operating status. When the CAN bus load rate fluctuates or the vehicle operating status changes to meet preset change conditions, the configuration management module 30 determines that the timeout threshold needs to be corrected, and then generates a threshold update trigger signal, which is actively pushed to the timeout threshold update event interface of the event management module. After receiving the trigger signal, the event management module 10 immediately activates the timeout threshold update event and binds the update event to the AUTOSAR extended task, waking up the extended task that is in a blocked waiting state.

[0054] Once the extended task is triggered and awakened by the event, it immediately calls the parameter reading interface of the configuration management module 30 to obtain the latest timeout threshold after real-time correction, and simultaneously pushes and updates the updated threshold parameters to the timeout monitoring module 20, completing the dynamic iteration update of the threshold throughout the entire process, ensuring that the timeout monitoring module 20 always performs fault judgment based on the current optimal threshold.

[0055] This embodiment uses an event-driven approach to dynamically update the timeout threshold, eliminating the need for continuous system polling to detect operating conditions and bus status, thus significantly reducing the consumption of unnecessary system resources. At the same time, the immediacy of event triggering ensures rapid synchronization of threshold parameters after changes in bus operating conditions and vehicle status, ensuring real-time adaptation of timeout judgment rules and further improving the accuracy and intelligence of system diagnosis.

[0056] For example, a new extended task specific to this invention is created in the vehicle AUTOSAR operating system configuration tool. This extended task supports a multi-event waiting mechanism, adapting to the system's requirement for synchronous monitoring of multiple types of CAN communication events, unlike the basic task which only supports single-event waiting. The core operating parameters for this extended task are configured as follows:

[0057] Task Priority: The priority level is between ordinary application tasks and system emergency tasks, and the value is set higher than the native task priority of the COM communication module. Technical Purpose: To ensure that CAN message transmission and reception, timeout faults, and threshold update-related events can be scheduled and executed with priority, avoiding preemption of time by the COM module and ordinary business tasks, and preventing timeout misjudgments caused by communication event processing delays; at the same time, it is lower than emergency tasks related to power safety, and does not affect the scheduling of the vehicle's highest safety level control logic.

[0058] Stack size: Allocate stack space based on the code execution depth of event handling logic, diagnostic information storage, and hierarchical recovery strategy, reserving sufficient redundant stack depth to avoid stack overflow when multiple events are processed concurrently.

[0059] Task scheduling attributes: Configured as an event-triggered task, automatically suspended when there is no event blocking, without occupying CPU resources for loop polling.

[0060] This extended task is associated with four sets of AUTOSAROS events: periodic events, transmission completion events, reception completion events, timeout events, and timeout threshold update events. All events are uniformly encapsulated and scheduled by the event management module 10 described in this application. The triggering conditions and corresponding processing actions for each event are shown in Table 1.

[0061] Table 1. Triggering conditions and corresponding processing actions for each event

[0062]

[0063] Figure 2 The system power-on initialization timing diagram provided in this application includes the vehicle AUTOSAR operating system, timeout monitoring module 20, and configuration management module 30 as the main interacting entities. The initialization process is uniformly scheduled by the vehicle AUTOSAR operating system: First, the vehicle AUTOSAR operating system initiates a timer initialization call to the timeout monitoring module 20. After completing the underlying resource configuration of the timer, the timeout monitoring module 20 returns an initialization completion signal to the vehicle AUTOSAR operating system. After receiving the receipt, the vehicle AUTOSAR operating system initiates a timeout threshold configuration call to the configuration management module 30. After completing the loading and configuration of various CAN communication timeout threshold parameters, the configuration management module 30 sends a configuration completion signal back to the vehicle AUTOSAR operating system. This completes all initialization work of the CAN communication system in this application.

[0064] Figure 3 This is a sequence diagram for the dynamic update of the timeout threshold during the runtime phase. The interactive objects include the vehicle AUTOSAR operating system, the event management module, and the configuration management module. The update process is driven by the periodic event tasks of the vehicle AUTOSAR operating system: the periodic event task first waits for the timeout threshold update event from the event management module; after the event management module triggers the update event, it sends a feedback to the operating system indicating that the waiting is complete; the periodic task then calls the configuration management module to complete the dynamic calculation and configuration of the timeout threshold, and after the configuration management module completes its execution, it sends back an execution completion signal; finally, the periodic task calls the event management module to clear the timeout threshold update event, and the event management module completes the event clearing and sends a feedback indicating that the clearing is complete, thus completing one round of adaptive timeout threshold update.

[0065] Figure 4 The diagram illustrates the timing interaction for normal CAN message transmission. The main components of this interaction include the vehicle's AUTOSAR operating system, the event management module, the timeout monitoring module, and the CAN transmission completion hardware interrupt. The message transmission process is initiated by a periodic event task in the vehicle's AUTOSAR operating system: the periodic event task first executes the message transmission operation and calls the timeout monitoring module to start a timer; subsequently, the periodic task calls the event management module to block and wait for either a transmission completion event or a timeout event; when the CAN hardware message transmission is completed, triggering a transmission completion interrupt, the interrupt callback function calls the timeout monitoring module to terminate the timer and notifies the event management module to set the transmission completion event; after the event management module wakes up the periodic task, the periodic task calls the event management module to clear the transmission completion event, and the entire message transmission process is completed after the event is cleared.

[0066] Figure 5The second half is the CAN response message reception timing flow, which follows the message sending process. The main interaction components include the vehicle AUTOSAR operating system, the event management module, the timeout monitoring module, and the CAN reception completion hardware interrupt. The message reception process is initiated by a periodic event task in the vehicle AUTOSAR operating system: the periodic task calls the timeout monitoring module to start the reception timer and calls the event management module to block and wait for the reception completion event or timeout event; when the CAN hardware successfully receives the response message, it triggers the reception completion interrupt. The interrupt callback function calls the timeout monitoring module to terminate the reception timer and notifies the event management module to set the reception completion event; after the event management module wakes up the periodic task, the periodic task calls the event management module to clear the reception completion event, and the current message reception process ends after the event is cleared.

[0067] Figure 6 This is a sequence diagram for handling CAN communication message transmission timeout faults. The main interactive components include the vehicle's AUTOSAR operating system, event management module, timeout monitoring module, timer timeout interrupt callback, and diagnostic processing module. The process begins with a periodic event task sending a message and starting a timer. The periodic task blocks and waits for the transmission / reception completion event or a timeout event. If the timer overflows and triggers a timeout interrupt, the interrupt callback wakes up the periodic task by setting the timeout event through the event management module. After clearing the timeout event, the periodic task sequentially calls the diagnostic processing module to complete the timeout event handling, multi-dimensional diagnostic information recording, and the execution of a tiered communication recovery strategy. The entire timeout fault handling process is then completed.

[0068] As an optional implementation of this application, the fault recording function of the diagnostic processing module 30 is refined and optimized, defining a comprehensive and multi-dimensional diagnostic information collection and storage mechanism to provide data support for fault tracing, root cause analysis and self-healing decision-making.

[0069] Specifically, when the diagnostic processing module 30 captures any CAN communication timeout event and performs fault recording operations, it not only records the basic fault code and the time of the fault occurrence, but also synchronously collects and stores full-dimensional context information at the time of the timeout, including the real-time operating status of the system, the current CAN bus communication load status, historical timeout mode statistics, and various core diagnostic parameters used for fault root cause analysis and communication recovery strategy decision-making.

[0070] The system operation status includes controller working mode, task scheduling status, and hardware resource usage; the communication load status includes real-time bus load rate, message transmission and reception frequency, and channel usage; the historical timeout mode statistics include fault characteristic data such as periodic timeout, occasional timeout, single-channel timeout, and multi-channel concurrent timeout; and various diagnostic parameters cover core data such as message ID, message length, timeout offset duration, and communication channel number.

[0071] Based on the comprehensive diagnostic information described above, the system can accurately distinguish between different fault types: historical timeout patterns can identify periodic latent faults and transient intermittent faults; bus load and resource occupancy status can differentiate between communication delay faults caused by bus congestion and system resource contention; and system operating status can correlate communication anomalies corresponding to specific vehicle operating conditions. Simultaneously, complete contextual data provides data support for the accurate execution of communication recovery strategies, avoiding blind repairs, significantly improving fault diagnosis efficiency and system maintainability, and meeting the requirements of automotive UDS diagnostic specifications and vehicle after-sales traceability.

[0072] As an optional implementation of this application, the communication recovery strategy of the diagnostic processing module 30 is refined, and a hierarchical progressive fault handling mechanism is adopted. For communication timeout faults of different severity, corresponding lightweight, medium-level and ultimate recovery methods are matched to achieve layered and precise fault management, taking into account both communication stability and vehicle functional safety.

[0073] The specific tiered recovery strategy is as follows:

[0074] The first level is a lightweight recovery strategy designed for single, momentary, and intermittent CAN communication timeout faults. These faults are mostly caused by transient bus interference and short-term timing fluctuations, without any persistent hardware or software anomalies. When a single communication timeout is detected, the system does not need to restart the link or the system. It only performs a retransmission operation on the failed message. For valid control messages that are not received after the timeout, it uses preset safety default values ​​to replace and fill in the gaps. The fault repair is completed in milliseconds, ensuring the continuity of vehicle control signals and avoiding unnecessary functional disturbances caused by minor anomalies.

[0075] The second level is a link-level recovery strategy, addressing persistent communication timeout faults where the first-level recovery strategy fails repeatedly or the fault recurs. When the lightweight repair method, which involves message retransmission and default value replacement, fails to resolve the timeout issue after triggering a preset number of times, a mid-level fault is identified, such as a CAN controller driver malfunction or link jamming. In this case, the system performs a CAN controller hardware reset, clearing the controller's abnormal state, resetting the communication link registers, repairing the underlying communication link fault, and restoring basic message transmission and reception capabilities. This eliminates the need for a vehicle controller restart, mitigating the risk of widespread system function interruption.

[0076] The third level is a system-level safety recovery strategy, serving as the ultimate fault protection mechanism. When the second-level CAN controller reset and repair fails, and a severe anomaly is determined to exist, such as hardware damage, channel failure, or serious bus failure, the system immediately initiates a safety degradation processing logic. It prioritizes switching to a redundant CAN communication channel to ensure the normal transmission of core power and safety-related messages. If there is no redundant channel or the channel switching fails, it actively notifies the upper-level application module to execute the system-level fault handling logic, synchronously and permanently storing the corresponding diagnostic fault codes to provide a basis for after-sales maintenance. At the same time, it achieves a safety degradation of the entire vehicle's functions, reserving sufficient safety buffer time.

[0077] This graded self-healing mechanism progresses from minor to severe, step by step. It can intelligently identify the severity and type of fault and accurately match the optimal recovery plan. It can quickly repair momentary minor faults and ensure real-time communication, as well as effectively handle continuous and severe communication faults, avoiding complete system failure caused by single point of failure. It achieves a balance between the reliability and real-time performance of vehicle CAN communication and the functional safety of the entire vehicle.

[0078] As an optional implementation of this application, the event triggering mechanism of the event management module 10 is refined and optimized, and a pure hardware interrupt-driven mode is adopted to realize low-latency triggering and precise control of communication events, which is suitable for vehicle-mounted high real-time control scenarios.

[0079] In practical implementation, the event management module 10 is deeply integrated with the CAN controller's hardware interrupts, employing standardized triggering logic via callback functions. When the CAN controller completes a message transmission operation and generates a transmission completion interrupt, or completes a message reception operation and generates a reception completion interrupt, the hardware interrupt signal immediately triggers a preset callback function. This callback function precisely triggers the corresponding transmission completion event or reception completion event, enabling real-time reporting of the communication status. Simultaneously, after each event processing logic is executed, the event management module 10 automatically clears the corresponding hardware interrupt flag, preventing interrupt nesting, duplicate event triggering, and status inconsistencies caused by residual interrupt flags.

[0080] This embodiment leverages the microsecond-level response capability of hardware interrupts to completely eliminate the periodic delay problem of traditional software polling, enabling instant triggering and processing of communication events. This meets the needs of high-precision real-time communication scenarios such as vehicle power control and safety control. Simultaneously, the standardized callback function design decouples event logic from hardware drivers, improving code modularity and portability. Furthermore, the system does not require CPU resources when there are no communication events, significantly improving processor resource utilization and ensuring the efficient operation of the vehicle's core tasks.

[0081] As an optional implementation of this application, the internal architecture and working logic of the timeout monitoring module 20 are further refined. The timeout monitoring module 20 has a built-in timer driver interface, which includes four functional sub-units: a timer initialization unit, a timer start unit, a timer stop unit, and a timeout interrupt callback unit, to realize full-process, high-precision monitoring of CAN communication timeout.

[0082] The specific workflow is as follows: During the system power-on initialization phase, the timer initialization unit first completes the initialization operations such as timer hardware resource configuration, timing accuracy calibration, and basic parameter solidification, and completes the pre-preparation of timeout monitoring hardware resources to ensure the stability and reliability of subsequent timing functions.

[0083] During normal system operation, when the upper-layer application initiates a CAN message sending request or a CAN message receiving request, the timer start unit is triggered synchronously, and the timer starts high-precision timing immediately to monitor the timing of the message sending and receiving throughout the entire process, eliminating blind spots in timeout monitoring and realizing full-cycle timing control of message sending and receiving.

[0084] When the event management module 10 reports a send completion event or a receive completion event, proving that the message sending and receiving has been completed normally, the timer stop unit responds immediately, terminates the current timer timing task, clears the timing data for this time, avoids invalid timing resource consumption, and waits for the next message sending and receiving task to be triggered.

[0085] If a transmit / receive completion event is not received within the preset timeout threshold during the timer's counting process, the message transmit / receive timeout is determined. The timeout interrupt callback unit immediately triggers a hardware timeout interrupt, generates a standardized CAN communication timeout event, and actively calls the diagnostic processing module to immediately start the fault recording and self-healing recovery process to ensure the real-time nature of fault handling.

[0086] This embodiment achieves high-precision timeout detection at the microsecond level through a combination of hardware timers and interrupt callbacks, far exceeding the accuracy and real-time performance of traditional software timing and polling monitoring solutions. At the same time, it achieves deep binding between timer start / stop and message transmission / reception events, resulting in zero resource consumption when there are no communication tasks, effectively reducing system load. The modular timer unit design decouples monitoring logic from business logic, improving system maintainability and platform reusability.

[0087] In one embodiment, this application also provides a CAN communication method based on the AUTOSAR architecture, applicable to the CAN communication system of any of the above embodiments. The method is simple and efficient, conforms to the AUTOSAR architecture specification, and specifically includes:

[0088] The event management module unifies the native event interface of the AUTOSAR operating system, shields the differences in underlying operating system adaptation, and provides standardized send completion event interface, receive completion event interface, and timeout event interface to build a dedicated event-driven scheduling system for CAN communication.

[0089] The configuration management module manages the storage of CAN communication timeout thresholds, dynamically adjusts the thresholds based on bus load rate and vehicle operating conditions, and stably outputs valid timeout threshold parameters.

[0090] The timeout monitoring module reads the timeout threshold output by the configuration management module in real time, continuously monitors the CAN message transmission and reception communication status, accurately determines communication timeout anomalies, and immediately generates and reports a CAN communication timeout event when a transmission timeout or reception timeout is detected.

[0091] The diagnostic processing module monitors and acquires CAN communication timeout events forwarded by the event management module in real time, fully records multi-dimensional fault diagnosis context information, and executes graded communication recovery strategies according to the severity of the fault, thereby achieving automatic fault repair and security degradation.

[0092] In one embodiment, this application also provides a vehicle equipped with a vehicle electronic control system. The vehicle electronic control system integrates a CAN communication system based on the AUTOSAR architecture described in any of the above embodiments. This CAN communication system enables efficient, reliable, and low-latency CAN data interaction between vehicle controllers, BMS bridge chips, motor drive chips, and other vehicle-mounted devices. It is adapted to event-driven communication scenarios under a domain-centralized electronic architecture, effectively improving the fault diagnosis capability, self-healing capability, and operational stability of the vehicle's CAN communication, and ensuring the vehicle's driving safety and functional reliability.

[0093] It should be noted that the vehicle can be, but is not limited to, a pure electric vehicle (PEV / BEV), a hybrid electric vehicle (HEV), a range-extended electric vehicle (REEV), a plug-in hybrid electric vehicle (PHEV), a new energy vehicle, or a gasoline vehicle.

[0094] The above embodiments are merely preferred embodiments provided to fully illustrate the present invention, and the scope of protection of the present invention is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on the present invention are all within the scope of protection of the present invention.

Claims

1. A CAN communication system based on AUTOSAR architecture, characterized in that, include: The event management module encapsulates the settings, waiting, and clearing interfaces for AUTOSAR operating system events, and provides a send completion event interface, a receive completion event interface, and a timeout event interface. Among them, the CAN transmit / receive interrupt logic reports the message transmit / receive completion signal through the send completion event interface and the receive completion event interface, and the CAN communication timeout event generated by the timeout monitoring module is transmitted through the timeout event interface. The timeout monitoring module reads the timeout threshold output by the configuration management module, monitors the CAN communication status, and generates a CAN communication timeout event and sends it to the timeout event interface when a send timeout or receive timeout is detected. The configuration management module stores and provides timeout thresholds to the timeout monitoring module; The diagnostic processing module obtains CAN communication timeout events through the timeout event interface, records diagnostic information, and executes communication recovery strategies.

2. The CAN communication system based on AUTOSAR architecture according to claim 1, characterized in that: The configuration management module dynamically updates the timeout threshold based on the message length and the number of message frames.

3. The CAN communication system based on the AUTOSAR architecture according to claim 2, characterized in that: The configuration management module is also configured to dynamically adjust the timeout threshold based on the CAN bus load rate and vehicle operating status.

4. The CAN communication system based on AUTOSAR architecture according to claim 3, characterized in that: The event management module provides a timeout threshold update event interface, which is used to receive a threshold update trigger signal sent by the configuration management module when a preset change is detected in the CAN bus load rate or vehicle operating status. The timeout threshold update event interface is associated with the extended task, so that after receiving the threshold update event, the extended task calls the configuration management module to re-obtain the corrected timeout threshold and update it to the timeout monitoring module.

5. The CAN communication system based on AUTOSAR architecture according to claim 1, characterized in that: The diagnostic information recorded by the diagnostic processing module includes context information when a timeout occurs. The context information includes at least the system operating status, current communication load status, historical timeout pattern statistics, and diagnostic parameters used for communication failure root cause analysis and system recovery decisions.

6. The CAN communication system based on AUTOSAR architecture according to claim 1, characterized in that: The communication recovery strategy executed by the diagnostic processing module adopts a hierarchical processing mechanism, including: Level 1 recovery strategy: When a single communication timeout is detected, retransmit the failed message or replace the message that was not received after the timeout with a preset default value; Second-level recovery strategy: When the first-level recovery strategy fails for a preset number of consecutive times, the CAN controller is reset to restore the communication link state; Third-level recovery strategy: When the second-level recovery strategy fails, switch to the redundant CAN communication channel or notify the upper-level application system to perform system-level fault handling and record the corresponding diagnostic fault codes.

7. The CAN communication system based on AUTOSAR architecture according to claim 1, characterized in that: The event management module adopts an interrupt-driven mechanism. When the CAN controller generates a transmit completion interrupt or a receive completion interrupt, it triggers the corresponding transmit completion event or receive completion event through a callback function, and clears the corresponding interrupt flag after the event is processed.

8. The CAN communication system based on AUTOSAR architecture according to claim 1, characterized in that: The timeout monitoring module includes a timer driver interface, which includes a timer initialization unit, a timer start unit, a timer stop unit, and a timeout interrupt callback unit. The timer initialization unit completes the basic configuration of the timer during the system initialization phase. The timer start unit starts timeout monitoring after a CAN message sending request or a CAN message receiving request is sent. The timer stop unit stops timing when a sending completion event or a receiving completion event is received. The timeout interrupt callback unit triggers a timeout event and calls the diagnostic processing module when the timer times out.

9. A CAN communication method based on AUTOSAR architecture, characterized in that, include: The AUTOSAR operating system event interface is encapsulated through the event management module, providing a send completion event interface, a receive completion event interface, and a timeout event interface. The configuration management module stores and provides timeout thresholds; the timeout monitoring module reads the timeout thresholds, monitors the CAN communication status, and generates a CAN communication timeout event when a send timeout or receive timeout is detected; the diagnostic processing module obtains the CAN communication timeout event, records diagnostic information, and executes a communication recovery strategy.

10. A vehicle, characterized in that, Including the CAN communication system based on the AUTOSAR architecture as described in any one of claims 1 to 8.

Images