An AUTOSAR-based monitoring and debugging method and system

Abstract

The application discloses a kind of based on AUTOSAR's monitoring debugging method and system, it is related to vehicle-mounted electronic and electrical architecture and data monitoring technical field, for solving the problem of current AUTOSAR abnormal monitoring inaccuracy, the method comprises: real-time acquisition AUTOSAR generated message data, fault diagnosis whole process data and internal operation data;Determine the data type of each real-time acquisition data, source module, data content, functional scenario and time stamp;According to data type, source module, time stamp and data content, each real-time acquisition data is encapsulated as standardized data;Select the abnormal rule corresponding to standardized data type, and detect the abnormality of each standardized data;When detecting that data is abnormal, generate exception log;Standardized data and exception log are displayed.It can quickly identify various abnormalities, and realize the all-round abnormal monitoring of AUTOSAR.

Description

Technical Field

[0001] This invention relates to the field of vehicle electronic and electrical architecture and data monitoring technology, and in particular to a monitoring and debugging method and system based on AUTOSAR. Background Technology

[0002] With the increasing electrification and intelligence of automobiles, the AUTOSAR architecture has become the mainstream framework for in-vehicle electronic system design due to its advantages of standardization, modularity, and portability. In this architecture, the ASW layer carries in-vehicle application functions, while the BSW layer provides underlying services such as communication, diagnostics, and storage. The two layers interact with each other through standardized interfaces, messages, and internal signals. Among these, diagnostic data is the core data that ensures the safe operation of the system.

[0003] Existing monitoring solutions mostly focus on the collection and anomaly detection of bus messages between the application software layer (ASW) and the basic software layer (BSW), which is insufficient for monitoring anomalies in AUTOSAR, resulting in inaccurate identification of AUTOSAR anomalies. Summary of the Invention

[0004] To address the aforementioned problems, this invention proposes a monitoring and debugging method and system based on AUTOSAR, which enables comprehensive anomaly detection using AUTOSAR.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: Firstly, an AUTOSAR-based monitoring and debugging method is proposed, including: The system collects message data, diagnostic event data, and internal status data generated during the operation of the AUTOSAR system in real time. The message data includes application messages and network management messages, the diagnostic event data includes diagnostic request and response sequences and fault state migration records, and the internal status data includes runtime variables of basic software modules and runtime environment. For each piece of data collected, the data type, source module identifier, data payload content, and associated functional scenario identifier are extracted, and the current timestamp is added to form a time-series data item with metadata; Using a pre-defined unified data template, each time series data item is reassembled and encapsulated based on its data type, source module identifier, timestamp, and data payload content to generate a standardized data packet with a standard field structure. Access the preset exception rule base, and select at least one exception detection rule corresponding to the data type based on the data type field in the standardized data packet; wherein, the exception rule base stores the mapping relationship between data types and exception detection rules; Using the selected anomaly detection rules, anomaly detection is performed on the data payload content or data timing characteristics in the standardized data packets, and when an anomaly is determined to occur, an anomaly log containing the anomaly type, anomaly data packet identifier, and detection time is generated. The standardized data packet and the exception log are output to a display device and visualized in the form of charts or text.

[0006] In some embodiments, when an anomaly is detected in the data, the anomaly level of the data is also determined; An alarm message will be issued based on the level of abnormality.

[0007] In some embodiments, the data is displayed in partitions based on the type of standardized data.

[0008] In some embodiments, both standardized data and exception logs are cached; Get the query command; Determine the specific query requirements based on the query instructions; Based on the specific query requirements, the corresponding data is retrieved from the cached standardized data and exception logs for display.

[0009] In some embodiments, message data includes message content, transmission period, data length, and message identifier; The entire fault diagnosis process data includes fault codes, fault levels, fault response times, and freeze frame data.

[0010] In some embodiments, the exception rules for message data are used to verify whether the message transmission period is within a preset period range, whether the message content is complete, and whether there is packet loss. The anomaly rules for internal operational data are used to verify whether signal values ​​exceed preset thresholds and whether signal changes conform to logic. The exception rules for fault diagnosis data are used to verify whether the diagnostic response time has exceeded the limit and whether the fault code is a known fault type.

[0011] Secondly, an AUTOSAR-based monitoring and debugging system is proposed, including: The data acquisition agent module is used to acquire message data, fault diagnosis process data and internal operation data generated by AUTOSAR in real time; determine the data type, source module, data content, functional scenario and timestamp of each real-time acquired data; and encapsulate each real-time acquired data into standardized data according to the data type, source module, timestamp and data content. The data parsing module is used to select the anomaly rules corresponding to the standardized data types and perform anomaly detection on each standardized data; when an anomaly is detected, an anomaly log is generated. The monitoring terminal is used to display standardized data and anomaly logs.

[0012] Thirdly, a computer device is proposed, the device comprising: A processor, adapted to execute computer programs; A computer-readable storage medium storing a computer program, which, when executed by the processor, implements the AUTOSAR-based monitoring and debugging method proposed in the first aspect.

[0013] Fourthly, a computer-readable storage medium is proposed, wherein the computer-readable storage medium stores a computer program adapted to be loaded and executed by a processor, which is an AUTOSAR-based monitoring and debugging method proposed in the first aspect.

[0014] Fifthly, a computer program product is proposed, which includes a computer program that, when executed by a processor, implements an AUTOSAR-based monitoring and debugging method proposed in the first aspect.

[0015] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention proposes a monitoring and debugging method and system based on AUTOSAR. The method realizes comprehensive collection and monitoring of message data, fault diagnosis process data and internal operation data generated by AUTOSAR. According to the data type, the corresponding anomaly rules are selected to perform anomaly detection on each collected data, which can quickly identify various anomalies and realize all-round anomaly monitoring of AUTOSAR.

[0016] Advantages of additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0017] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments of this application and their descriptions are used to explain this application and do not constitute an undue limitation of this application.

[0018] Figure 1 This is a flowchart of a monitoring and debugging method based on AUTOSAR; Figure 2 This is a flowchart illustrating the workflow of the data acquisition agent module. Figure 3 A logical flowchart for data parsing and anomaly detection; Figure 4 This is an overall architecture diagram of an AUTOSAR-based monitoring and debugging method application system. Detailed Implementation

[0019] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While some embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this application. It should be understood that the drawings and embodiments of this application are for illustrative purposes only and are not intended to limit the scope of protection of this application.

[0020] In the description of the embodiments of this application, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment".

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

[0022] The key terms used in this application are explained below: AUTOSAR: Automotive Open System Architecture, is a standardized in-vehicle software architecture designed to improve the modularity, portability, and maintainability of in-vehicle electronic systems.

[0023] BSW: Basic Software Layer, the underlying software in the AUTOSAR architecture, providing low-level service functions such as communication, diagnostics, storage, and drivers.

[0024] ASW: Application Software Layer. In the AUTOSAR architecture, the application layer software implements vehicle control functions, such as powertrain control and chassis control.

[0025] COM: Communication Management Module, one of the core modules of the BSW layer, is responsible for managing communication functions such as message sending and receiving and signal routing within and between ECUs.

[0026] DCM: Diagnostic Communication Manager, the diagnostic service module of the BSW layer, is responsible for handling external diagnostic requests, managing diagnostic sessions, and executing diagnostic services.

[0027] DET: Development Error Tracer, a diagnostic service module in the BSW layer, is responsible for detecting and recording error events, fault codes, freeze frame data, etc. during software operation.

[0028] ECUA: ECU Abstraction, a hardware abstraction layer module in the BSW layer, provides an abstract access interface to the underlying hardware resources, shielding hardware differences.

[0029] NVM: Non-Volatile Memory Manager, a storage service module in the BSW layer, is responsible for managing the non-volatile memory of the ECU to achieve persistent data storage.

[0030] With the increasing electrification and intelligence of automobiles, the AUTOSAR architecture has become the mainstream framework for automotive electronic system design due to its advantages of standardization, modularity, and portability. In this architecture, the ASW layer carries automotive application functions, while the BSW layer provides underlying services such as communication, diagnostics, and storage. The two layers interact through standardized interfaces, messages, and internal signals. Diagnostic data (including fault codes, diagnostic requests / responses, freeze frames, etc.) is the core data ensuring the safe operation of the system. Currently, there are two main approaches to monitoring data under the AUTOSAR architecture: one is to add a separate hardware monitoring module to connect to the vehicle bus (CAN / LIN / Ethernet) to collect interaction messages, requiring additional deployment of chips, circuits, and communication interfaces; the other is to use external third-party testing equipment (such as CANoe, Vector CANalyzer, etc.) to capture data in real time through the bus interface, primarily used for laboratory testing or after-sales maintenance. In existing technologies, the core monitoring relies on "externally added components," failing to fully utilize the functional redundancy of existing AUTOSAR modules. Furthermore, most solutions focus on bus messages between ASW and BSW, resulting in insufficient full-process monitoring coverage of signals within each layer (such as service status signals at the BSW layer and application logic signals at the ASW layer) and diagnostic data, and a lack of data correlation analysis.

[0031] With the increasing level of automotive electronics and intelligence, the AUTOSAR architecture has become the mainstream framework for automotive electronic system design due to its advantages of standardization, modularity, and portability. In this architecture, the ASW layer carries automotive application functions, while the BSW layer provides underlying services such as communication, diagnostics, and storage. The two layers interact through standardized interfaces, messages, and internal signals. Diagnostic data (including fault codes, diagnostic requests / responses, freeze frames, etc.) is the core data ensuring the safe operation of the system. Currently, there are two main approaches to monitoring data under the AUTOSAR architecture: one is to add a separate hardware monitoring module that connects to the vehicle bus (CAN / LIN / Ethernet) to collect interaction messages, requiring additional deployment of chips, circuits, and communication interfaces; the other is to use external third-party testing equipment (such as CANoe, Vector CANalyzer) to capture data in real time through the bus interface, primarily used for laboratory testing or after-sales maintenance. In existing technologies, the core monitoring relies on "externally added components," failing to fully utilize the functional redundancy of existing AUTOSAR modules. Furthermore, most solutions focus on bus messages between ASW and BSW, resulting in insufficient full-process monitoring coverage of signals within each layer (such as service status signals at the BSW layer and application logic signals at the ASW layer) and diagnostic data, and a lack of data correlation analysis.

[0032] To achieve comprehensive real-time anomaly monitoring of AUTOSAR during vehicle dynamic operation, this invention proposes an AUTOSAR-based monitoring and debugging method. This method enables real-time and comprehensive collection and monitoring of AUTOSAR-generated message data, fault diagnosis process data, and internal operational data during vehicle dynamic operation. Based on the data type, corresponding anomaly rules are selected to perform anomaly detection on the collected data, quickly identifying various anomalies and achieving comprehensive real-time anomaly monitoring of AUTOSAR. Furthermore, by visualizing standardized data and anomaly logs, technicians can quickly trace the root cause of anomalies, reducing fault location time by more than 60%.

[0033] The technical approach of this application lies in fully reusing the functions of existing AUTOSAR modules. During vehicle dynamic driving, it acquires real-time message data, fault diagnosis process data, and internal operational data generated by AUTOSAR. It determines the data type, source module, data content, functional scenario, and timestamp of each real-time acquired data. Based on the data type, source module, timestamp, and data content, each real-time acquired data is encapsulated into standardized data. Anomaly rules corresponding to the standardized data type are selected to perform anomaly detection on each standardized data. When an anomaly is detected, an anomaly log is generated. The standardized data and anomaly log are displayed, achieving comprehensive monitoring of AUTOSAR anomalies and real-time display of data and anomaly logs. The entire solution requires no new hardware; it only reuses existing AUTOSAR modules and adds software logic, significantly reducing hardware costs and development cycle. It is naturally compatible with the original architecture, avoiding compatibility issues, and enables real-time online monitoring during vehicle dynamic driving, reducing costs and improving compatibility. Data acquisition is comprehensive and rich in dimensions. It covers ASW-BSW interaction messages, BSW / ASW internal signals and diagnostic process data, realizes full-link monitoring of data interaction, and provides complete data support for fault diagnosis; the data is visualized, and technicians can quickly trace the root cause of the anomaly, shortening the fault location time by more than 60% and improving the full life cycle management level of the vehicle electronic system.

[0034] Figure 4 This diagram illustrates the overall architecture of an AUTOSAR-based monitoring and debugging method application system according to an embodiment of this application. Figure 4 As shown, this system is deployed inside the vehicle's ECU, deeply integrated with the existing AUTOSAR architecture. It reuses the AUTOSAR BSW layer's communication management module (COM), diagnostic service module (DCM / DET), ECU abstraction module (ECUA), and storage module (NVM), as well as the ASW layer's basic application service module. It adds two software modules: a data acquisition proxy module and a data parsing and anomaly detection module, deployed in the BSW layer's service layer, interacting with existing modules through standardized interfaces. The specific configuration includes: the application software layer (ASW), the basic software layer (BSW) (including COM, DCM / DET, ECUDA, and NVM modules), the data acquisition proxy module, the data parsing and anomaly detection module, the local cache module, the communication transmission module, and the monitoring terminal.

[0035] 1) Communication Management Module (COM): Configure message receiving / sending callback functions, enable message transmission status feedback function, and when there is message transmission between ASW and BSW, trigger the callback function to push information such as message content, transmission time, and message ID to the data acquisition agent module; The communication management module can also use Ethernet modules (such as EthIf modules in the AUTOSAR BSW layer) for data transmission, which is particularly suitable for vehicles equipped with Ethernet architecture. EthIf modules have higher transmission rates and can support larger volumes of real-time data uploads, making them suitable for scenarios with high data transmission rate requirements (such as multi-ECU collaborative monitoring). Alternatively, vehicle networking modules (such as TCUs) can be used to upload data to a cloud monitoring platform for remote monitoring. This alternative solution improves data transmission rates and distances, expands monitoring scenarios, and offers more flexible data transmission capabilities.

[0036] 2) Diagnostic Service Module (DCM / DET): Enable the diagnostic event logging function, configure the DCM module to output status signals when receiving diagnostic requests and sending diagnostic responses, and the DET module to synchronously output fault codes, fault occurrence time, freeze frame data and other information when detecting diagnostic faults, all of which are pushed to the data acquisition agent module. 3) ECU Abstraction Module (ECUA): Calls the I / O Hardware Abstraction Layer interface to collect the operating status signals of various modules in the BSW layer (such as the CAN driver module and SPI driver module in the MCAL layer), including module working mode, resource utilization, error codes, etc., and transmits them to the data acquisition agent module through a standardized interface. 4) Storage Module (NVM): Allocate a 1MB storage partition for caching real-time data. Configure the caching strategy as "first-in, first-out". When the cache reaches 80%, data upload will be automatically triggered, while retaining the historical data of the last 7 days. 5) Data Acquisition Agent Module: Adopting a modular design, it includes three sub-units: message acquisition unit, signal acquisition unit, and diagnostic data acquisition unit. These sub-units respectively connect to the COM, EVA, and DCM / DET modules. Data is acquired through the API interfaces provided by AUTOSAR (such as Com_ReceiveSignal and Det_GetErrorInfo) and uniformly encapsulated into a standardized format of "data type-source module-timestamp-data content".

[0037] The data acquisition agent module and the data parsing and anomaly detection module are deployed in the service layer of the BSW layer, located between the COM module, DCM module, and ASW layer, without interfering with the functional interaction of the original modules. The local caching module is implemented based on the NVM module and deployed in the storage service layer of the BSW layer; the communication transmission module reuses the bus communication function of the COM module, uploading data to the monitoring terminal via CAN FD bus or Ethernet; the monitoring terminal is deployed in the cockpit or back-end monitoring center, supporting real-time data display and anomaly alarms. Data interaction between all modules follows the AUTOSAR standard communication protocol.

[0038] Furthermore, the data acquisition agent module directly integrates the acquisition logic into existing modules such as COM, DCM, and EVA. By modifying the module's configuration file, data output interfaces are added, eliminating the need for additional independent modules. The advantage of this alternative is further simplification of the system architecture and reduction of interaction latency between modules. The disadvantage is the need to modify the configuration of existing modules, requiring rigorous testing during development to avoid affecting the functionality of existing modules. The technical effect is consistent with the original solution, enabling comprehensive data acquisition.

[0039] 6) Monitoring terminal, deployed in the cockpit or back-end monitoring center, supports real-time data display and anomaly alarms. Data interaction between modules follows the AUTOSAR standard communication protocol to ensure data transmission stability and compatibility.

[0040] The data collection and processing in this embodiment strictly comply with relevant laws and regulations. The collected data is used only for vehicle system monitoring and not for other unauthorized purposes.

[0041] It should be understood that Figure 4 The architecture shown is merely illustrative and does not imply any limitation on the scope of protection of this application. This invention can also be applied to other scenarios such as multi-ECU collaborative monitoring and remote monitoring.

[0042] Figure 1 A flowchart of a monitoring and debugging method based on AUTOSAR is shown; Figure 2 A flowchart illustrating the workflow of the data acquisition agent module is shown. Figure 1 , Figure 2 As shown, an AUTOSAR-based monitoring and debugging method includes: Step S101: Real-time acquisition of message data generated by AUTOSAR, fault diagnosis process data, and internal operation data.

[0043] The internal operational data of AUTOSAR includes the operational status data of each multiplexing module in AUTOSAR.

[0044] When the vehicle system is running, the data acquisition agent module monitors the status changes of each multiplexing module in real time and obtains the operating status data of each multiplexing module; internal operating data is obtained by calling the I / O hardware abstraction layer interface through the multiplexed ECU abstraction module ECUA. The ECUA module collects the operating status signals of each module in the BSW layer in real time, including: bus load rate, transmit buffer occupancy rate, and receive error count of the CAN driver module; transmission rate and transmission error code of the SPI driver module; storage space occupancy rate and read / write count of the NVM module; and message queue length and message loss count of the COM module. The data acquisition agent module periodically queries the status signals of the ECUA module; the query period is configurable, preferably every 50ms. This step corresponds to... Figure 4The data flow between the ECUDA module and the data acquisition agent module solves the technical problem in the existing technology of being unable to obtain the operating status of the internal modules of the BSW layer.

[0045] The message data includes the message content, transmission period, data length, and message identifier. The message identifier can be represented by the message ID.

[0046] The "Communication Management Module (COM)" refers to the standardized module in the AUTOSAR BSW layer responsible for managing message transmission between the ASW and BSW. The "callback function" refers to a function automatically invoked when a specific event occurs, used to notify the data acquisition agent module that data has been generated. In the COM module's configuration file, the message reception callback function `ComRxIndication` and the message transmission callback function `ComTxConfirmation` are set. When the ASW layer sends a control message to the BSW layer, the COM module triggers the `ComTxConfirmation` callback function, pushing the message content, transmission time, and message identifier ID to the message acquisition unit of the data acquisition agent module. When the BSW layer sends a feedback message to the ASW layer, the COM module triggers the `ComRxIndication` callback function, similarly pushing relevant information to the message acquisition unit. This step corresponds to... Figure 4 The data flow between the COM module and the data acquisition agent module Figure 4 The connection relationship between the COM module and the data acquisition agent module, which pushes message data through a callback function interface, is clearly shown. With this configuration, the message acquisition unit can acquire all message data transmitted between the ASW and BSW in real time, including message identifier, data length, transmission period, message content, and other information, thus solving the technical problem in existing technologies that require an additional hardware monitoring module to acquire message data.

[0047] The entire fault diagnosis process data includes fault codes, fault levels, fault response times, and freeze frame data.

[0048] The entire fault diagnosis process data is acquired through the reuse of the Diagnostic Service Module (DCM) and the Diagnostic Equipment Module (DET). When the diagnostic instrument initiates a diagnostic request, the DCM module receives the request and pushes information such as the diagnostic request type, request time, and request parameters to the diagnostic data acquisition unit in the data acquisition agent module. After the diagnostic response is sent, the response result and response time are pushed synchronously.

[0049] If the DET module detects a fault (such as message transmission timeout or abnormal signal value), it will push the fault code, fault occurrence time, and freeze frame data to the diagnostic data acquisition unit by calling the Det_GetErrorInfo interface. The freeze frame data contains key physical environmental parameters such as power supply voltage, ECU operating temperature, and vehicle speed at the time of the abnormality.

[0050] This step corresponds to Figure 4 The data flow between the DCM / DET module and the data acquisition agent module enables full-process data acquisition from diagnostic request initiation to diagnostic response feedback and then to fault detection, solving the technical problem in existing technologies where diagnostic data monitoring is limited to fault code reading.

[0051] Step S102: Determine the data type, source module, data content, functional scenario, and timestamp for each real-time acquired data.

[0052] The data types include message data, internal operation data, and fault diagnosis data.

[0053] Data classification and attribute association are performed based on the AUTOSAR standard protocol. Specifically, after receiving the raw data, the data acquisition agent module first classifies the data according to its source. Data from the COM module is classified as message data, data from the ECUA module is classified as internal operation data, and fault diagnosis process data from the DCM and DET modules is classified as fault diagnosis data.

[0054] Meanwhile, the data acquisition agent module records the source module identifier of each piece of data, such as the module name (COM, ECUA, DCM, DET, etc.), as well as the functional scenario when the data was generated, such as normal operation scenario or diagnostic mode scenario.

[0055] The data acquisition agent module adds a microsecond-level timestamp to each data entry, ensuring that data from different sources can be correlated and analyzed in chronological order. The timestamp uses the ECU's internal system clock, achieving microsecond-level accuracy.

[0056] By classifying data types, we can select appropriate exception rules based on the data type to achieve accurate anomaly detection.

[0057] Determining the timestamp of the data facilitates subsequent anomaly analysis.

[0058] Step S103: Encapsulate each piece of real-time acquired data into standardized data according to data type, source module, timestamp, and data content.

[0059] The data acquisition agent module encapsulates the collected raw data into a standardized format of "data type identifier - source module identifier - timestamp - data content". For example, a message-type data is encapsulated as "message type - COM - 1234567890 - message ID: 0x123, data length: 8, content: 0x01020304...".

[0060] Through standardized encapsulation, each piece of data has a clear data type, source module, and functional scenario identifier from the moment of collection, providing an accurate data foundation for subsequent classification, association, and anomaly detection.

[0061] Step S104: Select the anomaly rules corresponding to the standardized data types and perform anomaly detection on each standardized data.

[0062] Figure 3 The diagram illustrates the logic flow of data parsing and anomaly detection, as follows: Figure 3 As shown, after receiving standardized data, the data parsing and anomaly detection module calls the preset anomaly rule library for real-time verification based on the data type.

[0063] For message-type data, anomaly rules are used to verify whether the message transmission period is within a preset range, whether the message content is complete, and whether there is packet loss. For example, the preset transmission period for critical messages is 10ms ± 2ms. If the actual transmission period exceeds this range, it is determined to be a period anomaly.

[0064] For internal signal data, anomaly rules are used to verify whether signal values ​​exceed preset thresholds and whether signal changes are logically consistent. For example, the preset threshold for CAN bus load rate is 80%. If the actual load rate exceeds this threshold, it is determined to be an abnormal load rate.

[0065] For fault diagnosis data, anomaly rules are used to verify whether the diagnostic response time exceeds the time limit and whether the fault code is a known fault type. For example, the preset timeout threshold for the diagnostic response is 500ms. If the actual response time exceeds this threshold, it is determined to be a response timeout anomaly.

[0066] Furthermore, this embodiment can also employ machine learning algorithms (such as decision trees and support vector machines) to train an anomaly recognition model based on historical monitoring data, thereby achieving dynamic optimization of anomaly rules. This approach can improve the accuracy of anomaly recognition, and is particularly suitable for identifying sporadic anomalies in complex scenarios. The drawback is the need for an additional algorithm training module, which places certain demands on the ECU's computing resources. Technically, it can improve the adaptive capability of anomaly recognition and reduce false alarm and false negative rates.

[0067] Step S105: When an anomaly is detected in the data, an anomaly log is generated.

[0068] In addition, when data anomalies are detected, the level of anomaly is determined. An alarm message will be issued based on the level of abnormality.

[0069] Once the anomaly detection module detects an anomaly, it immediately marks the anomaly level. Based on the degree of impact of the anomaly on vehicle operation safety, the anomaly level is divided into three levels: severe anomaly, general anomaly, and minor anomaly.

[0070] Critical anomalies refer to anomalies that may cause vehicle malfunction or safety risks, such as loss of critical messages or diagnostic response timeouts; general anomalies refer to anomalies that may affect vehicle performance but will not cause malfunction, such as message cycle deviation or signal values ​​approaching thresholds; minor anomalies refer to anomalies that have a minor impact on vehicle operation, such as slight deviations in the cycle of non-critical messages.

[0071] The anomaly detection module generates an anomaly log, recording information such as the data type, source module, timestamp, data content, anomaly type, and anomaly level of the anomaly data. Based on the anomaly level, the system issues corresponding alarm information.

[0072] Step S106: Display the standardized data and anomaly logs.

[0073] The data is displayed in partitions based on the type of standardized data.

[0074] This invention also caches both standardized data and exception logs; Get the query command; Determine the specific query requirements based on the query instructions; Based on the specific query requirements, the corresponding data is retrieved from the cached standardized data and exception logs for display.

[0075] The data parsing and anomaly detection module transmits standardized data and anomaly logs to the local caching module for caching. The data is stored in a designated partition of the NVM module in a "timestamp + data type" format. The cached standardized data includes both normal and abnormal data. The local caching module is implemented based on the NVM module, allocating a dedicated 1MB storage partition and employing a first-in, first-out (FIFO) strategy to manage the cached data.

[0076] When the cache reaches 80%, data upload is automatically triggered. The data is uploaded to the monitoring terminal via the communication transmission module. If the vehicle is equipped with vehicle networking capabilities, the data can be uploaded to the backend monitoring center simultaneously. The communication transmission module reuses the bus communication function of the COM module, transmitting data via CAN FD bus or Ethernet. The real-time data upload cycle is 80ms to 120ms, and anomaly logs are uploaded immediately.

[0077] Furthermore, this invention can also employ a combination of RAM temporary caching and NVM persistent storage. Real-time data is first stored in RAM (for faster access speeds), and the data is periodically synchronized to the NVM module. This improves the data caching rate, reduces the number of read / write operations on the NVM module, and extends its lifespan. This alternative solution is suitable for scenarios with high caching speed requirements, and technically improves data caching efficiency while reducing storage module wear and tear.

[0078] like Figure 3 As shown, after receiving data, the monitoring terminal displays the data in partitions according to the type of standardized data. Message data is displayed in the message display area, showing information such as message ID, transmission period, and content. Internal signal data is displayed in the signal display area in the form of curves or numerical values. Diagnostic data is displayed in the diagnostic display area, showing information such as diagnostic process, fault codes, and freeze frames.

[0079] The monitoring terminal's abnormal alarm zone displays abnormal information in real time, and uses different colors to mark abnormal information according to the level of abnormality. Severe abnormalities are marked in red and trigger an audible alarm, general abnormalities are marked in yellow, and minor abnormalities are marked in blue.

[0080] The monitoring terminal supports historical data query functionality. It can receive query commands from users and determine the specific query requirements based on these commands, such as querying historical data within a specific time range, based on a specific data type, or with a specific anomaly level.

[0081] Based on the specific query requirements, the system retrieves and displays the corresponding standardized data and exception logs from the local cache module. The local cache module retains historical data from the last 7 days, facilitating technical personnel to review past failures and analyze their evolution.

[0082] This invention uses call chain tracing based on the AUTOSAR layered architecture to determine the root cause of anomalies.

[0083] Step 1. In response to detecting data anomalies and generating an anomaly log, extract the source module identifier of the abnormal data recorded in the anomaly log; Step 2. Based on the preset module-level mapping relationship, determine the starting tracing level in the AUTOSAR layered architecture corresponding to the source module identifier; the layered architecture includes an application software layer, a runtime environment layer, a basic software layer, and a microcontroller abstraction layer; Step 3. Starting from the initial tracing level, obtain the running status records of each software module layer by layer along the top-down call chain; wherein, the running status records include at least the module error code, working mode and resource utilization rate, and the running status records are obtained in real time from each layer of software modules through a standard diagnostic interface or status acquisition interface; Step 4. During the layer-by-layer inspection, if an error code or abnormal status is detected in the running status record of the current layer software module, and the status records of the software modules at the next higher level in the call chain are all normal, then the level where the current layer software module is located is determined to be the abnormal root cause level, and the level and module identifier are output as the first location result. Step 5. If the call chain tracing fails to locate a clear abnormal root cause level, then obtain the frozen frame data generated by the diagnostic event manager at the time the abnormality occurred. The frozen frame data includes power supply voltage, ECU operating temperature and vehicle speed. Step 6. Cross-compare the physical environment parameters in the frozen frame data: If the power supply voltage is lower than the preset normal voltage lower limit, the abnormality will be attributed to hardware reset or signal distortion caused by power fluctuation. If the ECU operating temperature exceeds the preset normal operating temperature limit, the abnormality will be attributed to the over-temperature protection being triggered. If all the physical environment parameters are within their normal operating range, then physical environment factors are excluded, and the root cause of the anomaly is attributed to software logic errors or communication protocol failures. Step 7. Output the final root cause location information of the exception.

[0084] For example, when the DCM module reports a "sensor signal loss" error, tracing the call chain reveals no obvious software error code. Extracting the freeze frame shows that the ECU power supply voltage drops to 6V instantaneously when the error occurs. The system determines that the root cause of the error is a hardware reset caused by power fluctuations, rather than a software bug. This guides engineers to prioritize checking the power supply line and avoid making ineffective and repeated modifications to the software.

[0085] This implementation method was tested on a vehicle ECU equipped with the AUTOSAR Classic Platform 4.4 architecture. The test scenarios included normal driving, diagnostic mode, and fault simulation.

[0086] Test results show that the data acquisition delay is no more than 5ms and the data upload delay is no more than 100ms, which can meet the real-time monitoring requirements during dynamic driving. It can collect 120 key messages of ASW and BSW interaction messages, 50 internal signals of 20 modules in the BSW layer, and full-process diagnostic data including diagnostic request response fault codes and freeze frames, with a collection coverage of 100%.

[0087] It simulates five abnormal scenarios, including message transmission timeout, signal value exceeding threshold, and diagnostic response timeout, with an anomaly identification accuracy of 100% and an anomaly alarm response time of no more than 10ms.

[0088] For simulated CAN bus overload faults, by monitoring the abnormal logs and frozen frame data of the monitoring system, technicians can quickly locate the cause as an abnormality in the transmission cycle of a non-critical message. The fault location time is reduced from 30 minutes in the original solution to 5 minutes, significantly improving efficiency.

[0089] It is understood that the COM module callback function triggering mechanism in the above embodiments is not limited to the message receiving callback function, but can also use the message sending callback function or the message transmission status callback function.

[0090] Obviously, the diagnostic request processing mechanism of the DCM module is not limited to the UDS diagnostic protocol, but can also use the OBD diagnostic protocol or other diagnostic protocols commonly used in this field.

[0091] It is understandable that the above-mentioned ECUA module can collect internal signals in ways that are not limited to calling the I / O hardware abstraction layer interface. It can also actively push internal signals by configuring the status feedback function of the ECUA module.

[0092] Obviously, the preset thresholds of the above-mentioned abnormal rule base are not limited to fixed values, but can also be dynamically adjusted according to the actual operating conditions of the vehicle, such as adaptively adjusting the thresholds based on parameters such as vehicle speed and ambient temperature.

[0093] It is understandable that the caching strategy of the aforementioned local caching module is not limited to the first-in-first-out (FIFO) strategy, but can also adopt a priority caching strategy, prioritizing the retention of exception logs and critical data.

[0094] Obviously, the data transmission method of the above communication transmission module is not limited to CAN FD bus or Ethernet, but can also use LIN bus, FlexRay bus or wireless communication.

[0095] It is understandable that the deployment location of the aforementioned monitoring terminals is not limited to the cockpit or the back-end monitoring center, but can also be deployed in other locations of the vehicle or on the cloud monitoring platform.

[0096] Obviously, the above-mentioned abnormality level markings are not limited to the three levels of severe, moderate, and minor. They can also be divided into more levels or a numerical scoring method can be adopted according to actual needs.

[0097] This embodiment proposes an AUTOSAR-based monitoring and debugging method that can be deployed not only inside the vehicle ECU but also on a monitoring terminal. The vehicle ECU is only responsible for data acquisition and transmission, while the monitoring terminal performs data parsing, anomaly detection, and display, thereby reducing the computational load on the vehicle ECU. This method is suitable for ECUs with limited computing resources. The disadvantage is that the amount of data transmission increases, and there are certain requirements for the bandwidth of the communication channel. Technically, it can achieve flexible deployment of monitoring functions and adapt to vehicle hardware with different computing capabilities.

[0098] This embodiment proposes an AUTOSAR-based monitoring and debugging method that reuses existing AUTOSAR modules without requiring additional hardware. This achieves low-cost, multi-dimensional, and real-time monitoring, effectively addressing the shortcomings of existing technologies. Compared with existing technologies, it has the following advantages: 1. By reusing existing modules such as the communication management module COM, diagnostic service modules DCM and DET, ECU abstraction module ECUDA, and storage module NVM of the AUTOSAR basic software layer BSW, and adding data acquisition agent module software logic, no new independent monitoring hardware modules or external testing equipment are required. This fundamentally eliminates hardware cost investment, avoids interface adaptation problems between new modules and the original system, and enables real-time online monitoring of vehicles during dynamic driving, overcoming the limitation of existing solutions that can only be used in static testing or maintenance scenarios.

[0099] 2. Through the three sub-units of the data acquisition agent module—message acquisition unit, signal acquisition unit, and diagnostic data acquisition unit—which respectively connect to the COM module, ECUDA module, DCM, and DET module, a three-dimensional full-coverage acquisition of diagnostic process data is achieved, including interactive messages between the application software layer (ASW) and the basic software layer (BSW), operating status signals of each module within the BSW layer, diagnostic request responses, and fault code freeze frames. The data acquisition coverage rate is increased from approximately 40% in the existing solution to 100%, providing complete data link support for fault diagnosis.

[0100] 3. By encapsulating the collected data into a standardized format of "data type identifier - source module identifier - timestamp - data content", the automatic association between the data and the attributes of the AUTOSAR module is realized. This ensures that each piece of data has a clear source module and functional scenario identifier from the time of collection, avoiding the inefficiency of manually identifying raw data in existing solutions, and providing an accurate data foundation for subsequent anomaly judgment.

[0101] 4. By setting up dedicated anomaly rule bases for message data, internal signal data, and diagnostic data, real-time proactive verification is performed on message transmission cycle deviation, content integrity, packet loss, signal value threshold, signal logic rationality, diagnostic response timeout, and fault code type. This achieves a shift from "reading fault codes after the fact" to "real-time anomaly detection," enabling comprehensive anomaly detection for AUTOSAR, improving anomaly identification accuracy, shortening anomaly alarm response time, and reducing anomaly location time from an average of 30 minutes in the existing solution to 5 minutes, resulting in a 6-fold increase in efficiency.

[0102] In some embodiments, an AUTOSAR-based monitoring and debugging system is proposed, comprising: The data acquisition agent module is used to acquire message data, fault diagnosis process data and internal operation data generated by AUTOSAR in real time; determine the data type, source module, data content, functional scenario and timestamp of each real-time acquired data; and encapsulate each real-time acquired data into standardized data according to the data type, source module, timestamp and data content. The data parsing module is used to select the anomaly rules corresponding to the standardized data types and perform anomaly detection on each standardized data; when an anomaly is detected, an anomaly log is generated. The monitoring terminal is used to display standardized data and anomaly logs.

[0103] The data acquisition agent module is deployed in the service layer of the BSW layer. It is used to acquire message data, fault diagnosis process data and internal operation data generated by AUTOSAR in real time. It determines the data type, source module, data content, functional scenario and timestamp of each real-time acquired data, and encapsulates each real-time acquired data into standardized data according to the data type, source module, timestamp and data content.

[0104] The data acquisition agent module adopts a modular design, comprising three sub-units: a message acquisition unit, a signal acquisition unit, and a diagnostic data acquisition unit. The message acquisition unit communicates with the COM module and obtains message data through callback functions configured in the COM module.

[0105] The signal acquisition unit communicates with the EVA module and obtains the operating status signals of the internal modules of the BSW layer through the I / O hardware abstraction layer interface provided by the EVA module. The diagnostic data acquisition unit communicates with the DCM module and the DET module to obtain diagnostic request response data and fault code freeze frame data, respectively.

[0106] The data parsing module communicates with the data acquisition agent module to select the anomaly rules corresponding to the standardized data types, perform anomaly detection on each standardized data, and generate an anomaly log when an anomaly is detected.

[0107] The data parsing module includes a data classification unit, an attribute association unit, and an anomaly detection unit. The data classification unit categorizes standardized data into message data, internal signal data, and diagnostic data.

[0108] The attribute association unit associates each piece of data with its corresponding source module and functional scenario. The anomaly detection unit calls a preset anomaly rule library to perform real-time verification of the data, and after detecting an anomaly, marks the anomaly level and generates an anomaly log.

[0109] The monitoring terminal is used to display standardized data and anomaly logs. It includes a data display area, an anomaly alarm area, and a historical query area. The data display area shows standardized data in partitions based on data type.

[0110] The anomaly alarm area displays anomaly information in real time, with different colors used to mark alarms according to their severity: severe anomalies are marked in red and trigger an audible alarm, general anomalies are marked in yellow, and minor anomalies are marked in blue. The historical query area allows users to query historical data by time range, data type, and anomaly severity.

[0111] The system uses the existing AUTOSAR module to collect data through the data acquisition agent module, performs anomaly detection through the data parsing module, and displays the data visually through the monitoring terminal, forming a complete monitoring closed loop without the need for any new independent monitoring hardware modules or external testing equipment.

[0112] This system is deployed within the vehicle's ECU and deeply integrated with the existing AUTOSAR architecture. The data acquisition agent module and the data parsing and anomaly detection module are deployed in the service layer of the BSW layer, located between the COM module, DCM module, and ASW layer, without interfering with the functional interaction of the original modules. The local caching module is implemented based on the NVM module and deployed in the storage service layer of the BSW layer. The communication transmission module reuses the bus communication function of the COM module, uploading data to the vehicle monitoring terminal via CAN FD bus or Ethernet. The monitoring terminal is deployed in the driver's cabin or a back-end monitoring center, supporting real-time data display and anomaly alarms. Data interaction between all modules follows the AUTOSAR standard communication protocol, ensuring the stability and compatibility of data transmission.

[0113] It should be noted that the AUTOSAR-based monitoring and debugging system provided in the above embodiments is only illustrated by the division of the functional modules described above. In practical applications, the functions described above can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. Furthermore, the AUTOSAR-based monitoring and debugging system and the AUTOSAR-based monitoring and debugging method embodiment provided in the above embodiments belong to the same concept, and their specific implementation process is detailed in the method embodiment, which will not be repeated here.

[0114] In some embodiments, this application also provides a computer device, the device comprising: A processor, adapted to execute computer programs; A computer-readable storage medium stores a computer program, which, when executed by the processor, implements the AUTOSAR-based monitoring and debugging method proposed in the above embodiments. The computer device can be an on-board ECU or a standalone monitoring device. The processor can be a central processing unit (CPU), microcontroller (MCU), digital signal processor (DSP), field-programmable gate array (FPGA), or application-specific integrated circuit (ASIC), etc. The memory can be a read-only memory (ROM), random access memory (RAM), flash memory (Flash), or other non-volatile memory.

[0115] In some embodiments, this application also provides a computer-readable storage medium storing a computer program adapted for loading and execution by a processor of the AUTOSAR-based monitoring and debugging method proposed in the above embodiments. The computer-readable storage medium can be a non-volatile storage medium, such as flash memory, EEPROM, hard disk, etc., or a volatile storage medium, such as RAM, SRAM, etc. With the computer program stored in the computer-readable storage medium, when the processor reads and executes the computer program from the computer-readable storage medium, all the technical effects described in the above method embodiments can be achieved.

[0116] In some embodiments, this application also provides a computer program product, which includes a computer program. When the computer program is executed by a processor, it implements the AUTOSAR-based monitoring and debugging method proposed in the above embodiments. The computer program product may be a software installation package, which can be downloaded via a network or distributed via a storage medium. After obtaining the computer program product, a user can install it on an electronic device. When the electronic device executes the computer program, it can achieve all the technical effects described in the above method embodiments.

[0117] The method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor. The software modules can reside in readily available storage media in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are omitted here.

[0118] Those skilled in the art will recognize that the units and algorithm steps described in conjunction with the embodiments herein can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0119] While the specific embodiments of the present invention have been described above in conjunction with the accompanying drawings, this is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solutions of the present invention are still within the scope of protection of the present invention.

Claims

1. A monitoring and debugging method based on AUTOSAR, characterized in that, include: Real-time acquisition of message data generated by AUTOSAR, data from the entire fault diagnosis process, and internal operation data; Determine the data type, source module, data content, functional scenario, and timestamp for each piece of real-time data acquired; Each piece of real-time acquired data is encapsulated into standardized data according to data type, source module, timestamp, and data content; Select the anomaly rules corresponding to the standardized data types and perform anomaly detection on each standardized data; When an anomaly is detected in the data, an anomaly log is generated; Display standardized data and exception logs.

2. The monitoring and debugging method based on AUTOSAR as described in claim 1, characterized in that, When an anomaly is detected in the data, the level of anomaly is also determined. An alarm message will be issued based on the level of abnormality.

3. The monitoring and debugging method based on AUTOSAR as described in claim 2, characterized in that, The data is displayed in partitions based on the type of standardized data.

4. The monitoring and debugging method based on AUTOSAR as described in claim 2, characterized in that, Both standardized data and exception logs are cached; Get the query command; Determine the specific query requirements based on the query instructions; Based on the specific query requirements, the corresponding data is retrieved from the cached standardized data and exception logs for display.

5. The monitoring and debugging method based on AUTOSAR as described in claim 1, characterized in that, Message data includes message content, transmission period, data length, and message identifier; The entire fault diagnosis process data includes fault codes, fault levels, fault response times, and freeze frame data.

6. The monitoring and debugging method based on AUTOSAR as described in claim 1, characterized in that, The exception rules for message data are used to verify whether the message transmission period is within the preset period range, whether the message content is complete, and whether there is packet loss. The anomaly rules for internal operational data are used to verify whether signal values ​​exceed preset thresholds and whether signal changes conform to logic. The exception rules for fault diagnosis data are used to verify whether the diagnostic response time has exceeded the limit and whether the fault code is a known fault type.

7. A monitoring and debugging system based on AUTOSAR, characterized in that, include: The data acquisition agent module is used to acquire real-time message data generated by AUTOSAR, fault diagnosis process data, and internal operation data. Determine the data type, source module, data content, functional scenario, and timestamp for each piece of real-time acquired data; encapsulate each piece of real-time acquired data into standardized data according to the data type, source module, timestamp, and data content; The data parsing module is used to select the anomaly rules corresponding to the standardized data types and perform anomaly detection on each standardized data; when an anomaly is detected, an anomaly log is generated. The monitoring terminal is used to display standardized data and anomaly logs.

8. An electronic device, characterized in that, The device includes: A processor, adapted to execute computer programs; A computer-readable storage medium storing a computer program, which, when executed by the processor, implements the AUTOSAR-based monitoring and debugging method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted for loading and execution by a processor of the AUTOSAR-based monitoring and debugging method according to any one of claims 1-6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements an AUTOSAR-based monitoring and debugging method as described in any one of claims 1-6.

Images