Function application monitoring method and device and medium

Abstract

The invention discloses a function application monitoring method and device and a medium. The method comprises the steps that an application is monitored, and an application monitoring event notification is triggered based on a preset application monitoring strategy; monitoring an operating system corresponding to the application and triggering a system monitoring event notification based on a preset system monitoring strategy; monitoring an associated ECU corresponding to the application and triggering a hardware monitoring event notification based on a preset hardware detection strategy; based on the application monitoring event notification, the system monitoring event notification and / or the hardware monitoring event notification, analyzing and judging according to a preset monitoring event processing strategy; and carrying out record storage and / or alarm prompt based on the analysis and judgment result. According to the invention, instant abnormity monitoring and alarm can be realized, and comprehensive monitoring data information is provided, so that the performance and the use experience of function application in the intelligent ECU can be continuously improved.

Description

Technical Field

[0001] The present invention relates to the field of application monitoring technology, and in particular to a functional application monitoring method, device and medium. Background Art

[0002] Functional applications in smart ECU / HPC refer to software programs and services running in smart electronic control units (ECUs) and high-performance computing units (HPCs). These applications are responsible for executing and managing various intelligent functions of the vehicle, such as driving assistance, in-vehicle entertainment, navigation, remote diagnosis, etc., and improve the overall performance of the vehicle and user experience by integrating hardware and software resources.

[0003] At present, when software problems and failures occur in the functional applications of smart ECUs / HPCs, it is usually after the car owner complains that after-sales or operation and maintenance personnel have conducted preliminary analysis by system and software engineers, they will obtain the application logs for further analysis and location. However, this method is lagging behind. In many cases, the logs when the abnormal phenomenon occurs have been overwritten, or the logs cannot fully analyze the root cause of the problem. At the same time, the log content depends on software experts to interpret, resulting in the inability of after-sales, operation and maintenance, and test personnel to capture comprehensive data information and logs for analysis and judgment in the first place. Summary of the invention

[0004] In response to the above technical problems, the present invention provides a functional application monitoring method, device and medium, which can realize real-time abnormality monitoring and alarm, provide comprehensive monitoring data information, and thus continuously improve the performance and user experience of functional applications in intelligent ECUs.

[0005] A first aspect of the present invention provides a function application monitoring method, comprising: Monitor the application and trigger application monitoring event notification based on a preset application monitoring strategy; Monitor the operating system corresponding to the application and trigger a system monitoring event notification based on a preset system monitoring strategy; Monitor the associated ECU corresponding to the application and trigger a hardware monitoring event notification based on a preset hardware detection strategy; Based on the application monitoring event notification, the system monitoring event notification and / or the hardware monitoring event notification, analyzing and judging according to a preset monitoring event processing strategy; Based on the results of the analysis and judgment, records are stored and / or alarms are issued.

[0006] In a possible implementation, monitoring the application and triggering an application monitoring event notification based on a preset application monitoring strategy includes: Generate and store event data of a preset structure in response to each execution result of the application; Wherein, the event data at least includes: Event type data used to identify the success or failure of the event; Time information data used to identify the time when an event occurs; Failure event data used to distinguish different events when an event fails; When an event fails, it is used to provide the source module data of the failed event source; and, severity level data for identifying the level of the incident.

[0007] In a possible implementation, the event data further includes: Details data used to describe event details.

[0008] In a possible implementation, the application monitoring strategy includes: When the severity level data is higher than a preset level, an application monitoring event notification is triggered; and / or When the number of consecutive application failures exceeds a preset number, an application monitoring event notification is triggered; and / or When the failure event data has a preset reason and occurs continuously for more than a preset number of times, an application monitoring event notification is triggered.

[0009] In a possible implementation, monitoring the operating system corresponding to the application and triggering a system monitoring event notification based on a preset system monitoring strategy includes: When the application is running, monitoring status data at the platform level and at the APP granularity in the operating system; The platform-level status data includes the system CPU load rate, memory usage rate, and whether there is a memory dump file; The state data of the APP granularity includes the CPU occupancy rate when the application is running and whether the application process is alive.

[0010] In a possible implementation, the system monitoring strategy includes: When the CPU load rate exceeds a preset first threshold value, a system monitoring event notification is triggered; and / or When the memory usage exceeds a preset second threshold, a system monitoring event notification is triggered; and / or When the memory dump file appears, trigger a system monitoring event notification; and / or When the CPU occupancy rate exceeds a preset third threshold value, a system monitoring event notification is triggered; and / or When the application process is dead or crashes, a system monitoring event notification is triggered.

[0011] In a possible implementation, monitoring the associated ECU corresponding to the application and triggering a hardware monitoring event notification based on a preset hardware detection strategy includes: Determine the associated ECU corresponding to the application based on a preset association relationship tree; Subscribe to the DTC information of the associated ECU through the DTC dynamic service interface on the associated ECU.

[0012] In a possible implementation, determining the associated ECU corresponding to the application based on a preset association tree includes: Obtaining DTC data corresponding to the associated ECU; Determine an associated DTC corresponding to the application based on the DTC data and the association tree.

[0013] In a possible implementation, if the DTC dynamic service interface cannot be directly established, the DTC information of the associated ECU is collected through the bus of the vehicle electronic architecture.

[0014] In a possible implementation, the monitoring event processing strategy includes: Once the application monitoring event notification, the system monitoring event notification and / or the hardware monitoring event notification are received, the alarm prompt is directly triggered.

[0015] In a possible implementation, the monitoring and processing strategy includes: When the system monitoring event notification and / or the hardware monitoring event notification is received, continuously recording and storing; When the application monitoring event notification is received, the alarm prompt is triggered, and a query is made as to whether there is a corresponding system monitoring event notification and / or the hardware monitoring event notification; If so, the system monitoring event notification and / or the hardware monitoring event notification are carried in the alarm prompt based on a preset message structure.

[0016] In a possible implementation, the monitoring and processing strategy includes: Based on the application monitoring event notification, the system monitoring event notification and / or the hardware monitoring event notification, when the alarm prompt is triggered, trigger a diagnostic action; Among them, the diagnostic action includes triggering the corresponding APP log acquisition, triggering the corresponding MCU logistics data acquisition, and triggering the DID information acquisition.

[0017] In a possible implementation, the warning is provided in the form of an event and carries data information associated with the abnormal problem. A second aspect of the present invention provides a functional application monitoring device, comprising: An application monitoring module, deployed based on application granularity, at least for monitoring the application and triggering application monitoring event notification based on a preset application monitoring strategy; A system monitoring module, deployed based on the operating system granularity, at least for monitoring the operating system corresponding to the application and triggering a system monitoring event notification based on a preset system monitoring strategy; An associated ECU monitoring module, deployed based on the vehicle electronic architecture granularity, is at least used to monitor the associated ECU corresponding to the application and trigger a hardware monitoring event notification based on a preset hardware detection strategy; A monitoring event processor, at least used to analyze and judge according to a preset monitoring event processing strategy based on the application monitoring event notification, the system monitoring event notification and / or the hardware monitoring event notification; The processing result response module is at least used to record, store and / or issue an alarm based on the result of the analysis and judgment.

[0018] According to a third aspect of the present invention, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a computer, the method described in the first aspect is executed.

[0019] The present invention monitors the application, operating system and related ECUs, triggers corresponding monitoring event notifications based on preset monitoring strategies, and comprehensively analyzes these event notifications for record storage and alarm prompts, thereby achieving real-time monitoring of the vehicle electronic system, rapid fault location and response, and improving the stability and reliability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 The present invention is a flowchart of a method for monitoring a functional application in an embodiment of the present invention.

[0021] Figure 2 The figure is a flow chart of a function application monitoring method in an embodiment of the present invention.

[0022] Figure 3 It is a structural schematic diagram of a function application monitoring device in an embodiment of the present invention.

[0023] Figure 4 It is a structural diagram of an embodiment of an application monitoring module in an embodiment of the present invention. DETAILED DESCRIPTION

[0024] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0025] It should be understood that the terms "first", "second", and "third" etc. in the claims, specifications, and drawings of the present disclosure are used to distinguish different objects rather than to describe a specific order. The terms "include" and "comprise" used in the specification and claims of the present disclosure indicate the presence of the described features, wholes, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components, and / or their collections. It should also be understood that the terms used in this disclosure specification are only for the purpose of describing specific embodiments and are not intended to limit the present disclosure.

[0026] Vehicle electronic architecture refers to a set of electronic systems and network structures integrated in the vehicle, which are used to control and manage various vehicle functions and equipment, including engine control, transmission system, braking system, airbags, on-board entertainment system, navigation system, etc. Through electronic control units (ECU), sensors, actuators and communication networks (such as CAN bus), various components can work together to improve vehicle performance, safety and user experience.

[0027] Functional applications of vehicle electronic architecture refer to software programs running in the vehicle's electronic system. These programs control and manage various functions and equipment of the vehicle to achieve functions such as engine management, brake system control, in-vehicle entertainment and navigation, so as to improve the vehicle's performance, safety and user experience.

[0028] Monitoring the functional applications of the vehicle's electronic architecture can detect and diagnose anomalies in the system in real time, ensure the normal operation of various on-board functions, promptly discover and address potential problems, and avoid vehicle performance degradation or safety hazards caused by system failures, thereby improving vehicle reliability, safety and user satisfaction.

[0029] Based on this, refer to Figure 1 , an embodiment of the present invention provides a function application monitoring method, which is applied to the vehicle electronic architecture and includes the following steps.

[0030] S1, monitor the application and trigger application monitoring event notification based on the preset application monitoring strategy; specifically, in this step, the running status of the application in the vehicle electronic architecture is continuously monitored. This includes recording the startup, execution and shutdown of the application, and capturing the anomalies and errors encountered during its operation. The preset application monitoring strategy may include the definition of event levels (such as severe, warning, information), monitoring of the number of consecutive failures, and monitoring of specific failure causes. When these policy conditions are met, the corresponding monitoring event notification will be triggered.

[0031] S2, monitor the operating system corresponding to the application and trigger a system monitoring event notification based on a preset system monitoring strategy; specifically, in this step, monitor the running status of the operating system on which the application depends. This includes monitoring the CPU load, memory usage, system crash (coredump), etc. of the operating system. The preset system monitoring strategy can trigger an event notification by setting threshold values ​​for these parameters, for example, when the CPU load exceeds 90% or the memory usage exceeds 80%. In addition, the operating system can also be monitored to see if there are any important process interruptions or crashes. These situations can be used to trigger corresponding system monitoring event notifications.

[0032] S3, monitor the associated ECU corresponding to the application and trigger a hardware monitoring event notification based on a preset hardware detection strategy; specifically, in this step, monitor the operating status of the microcontroller unit (MCU) or classic electronic control unit (ECU) associated with the application. This includes monitoring the generation and clearing of diagnostic trouble codes (DTCs) of these ECUs. The preset hardware detection strategy may include specific types and quantity thresholds of DTCs, and when these DTCs are detected, a hardware monitoring event notification will be triggered. In addition, if certain ECU key components fail or are abnormal, corresponding monitoring events will also be triggered.

[0033] S4, based on the application monitoring event notification, the system monitoring event notification and / or the hardware monitoring event notification, analyze and judge according to the preset monitoring event processing strategy; specifically, in this step, comprehensively analyze the monitoring event notifications from the application, operating system and related ECU. The processing strategy may include: preliminary screening and priority judgment, and in-depth analysis based on the type, severity and related information of the event. For example, the processor will determine whether the failure of an application is caused by the high load of the operating system or the failure of an ECU. This step determines whether further processing or alarm is required based on the results of the analysis and judgment.

[0034] S5, based on the results of the analysis and judgment, record storage and / or alarm prompts are performed. Specifically, in this step, corresponding actions are taken based on the results of the analysis and judgment. It may include storing event information records in a database for subsequent analysis, or immediately triggering an alarm prompt to notify relevant personnel. Alarm prompts may be sent in different ways, such as vehicle dashboard warnings, background system notifications, or pushed to the operation and maintenance personnel's devices through the cloud. If the problem is determined to be serious or requires immediate processing, the system may also initiate further diagnostic and log collection operations to quickly locate and solve the problem.

[0035] Based on this, by comprehensively monitoring the applications, operating systems and related ECUs in the vehicle's electronic architecture, triggering and analyzing monitoring event notifications in real time, recording and storing key data and issuing alarm prompts, it is possible to quickly identify and handle abnormal situations, improve the stability, reliability and security of the system, and significantly enhance operation and maintenance efficiency and user experience.

[0036] Further, as an implementation mode of the present invention, step S1, monitoring the application and triggering an application monitoring event notification based on a preset application monitoring strategy, includes: Generate and store event data of a preset structure in response to each execution result of the application; Wherein, the event data at least includes: Event type data used to identify the success or failure of the event; Time information data used to identify the time when an event occurs; Failure event data used to distinguish different events when an event fails; When an event fails, it is used to provide the source module data of the failed event source; and, severity level data for identifying the level of the incident.

[0037] Specifically, obtain the event generated by each execution result of the APP function application and generate an independent<app name> _event.log is used to store and record the execution success and failure events of each APP function, and the event is judged according to the configured application monitoring strategy. When the application monitoring strategy is met, the application monitoring event notification is triggered.

[0038] The structure of event is defined as follows, which can be stored in json format.<app name> _event.log: { “event_type”: “failure / success”, / / mandatory, event type data, used to identify successful or failed events; "timestamp": "", / / mandatory, time information data, used to identify the time information of the event; “cause_code”: ””, / / conditional, failure event data: must be filled in when the event fails, used to identify and distinguish different failure events; "source_module":"" / / conditional, source module data: must be filled in when the event fails, used to identify the software module that gives the cause_code or the exception; “severity”: ”” / / mandatory, severity level data: identifies the severity level of the event, can be filled in “FATAL, ERROR, WARN, INFO”; }.

[0039] Further, as an implementation mode of the present invention, the event data also includes: Details data used to describe event details.

[0040] Specifically, the event structure definition also includes: { "detail_info": "", / / optional, detail information data: used to describe the detailed information of the event; }.

[0041] Further, as an implementation mode of the present invention, the application monitoring strategy includes: When the severity level data is higher than a preset level, an application monitoring event notification is triggered; and / or When the number of consecutive application failures exceeds a preset number, an application monitoring event notification is triggered; and / or When the failure event data has a preset reason and occurs continuously for more than a preset number of times, an application monitoring event notification is triggered.

[0042] Specifically, when the severity level data (such as errors and warnings) of an application is higher than the preset level, the system will immediately trigger an application monitoring event notification; if the number of consecutive failures of an application exceeds the preset threshold, a monitoring event notification will also be triggered; in addition, if a failure event caused by a specific reason occurs more than the preset number of times, such as network connection failure or storage error, the system will also trigger a monitoring event notification. These strategies ensure that the system can capture and respond to various abnormal situations in a timely manner and ensure the stable operation of the application.

[0043] Exemplarily, the application monitoring strategy may be: record event level: severity=xx (only record events above level xx); continuous failure times: failure_gauge=n (after the APP fails to execute for n consecutive times, a monitoring event notification is triggered); specify the number of failure event occurrences: event_type=failure, cause_code=xx, gauge=n (after a failure event with a specified fixed cause xx occurs for n consecutive times, a monitoring event is triggered).

[0044] In particular, the event_type of the APP crash must also be recorded as a failure event, and the cause_code can be set to crash.

[0045] Further, as an implementation mode of the present invention, step S2, monitoring the operating system corresponding to the application and triggering a system monitoring event notification based on a preset system monitoring strategy, includes: When the application is running, monitoring status data at the platform level and at the APP granularity in the operating system; The platform-level status data includes the system CPU load rate, memory usage rate, and whether there is a memory dump file; The state data of the APP granularity includes the CPU occupancy rate when the application is running and whether the application process is alive.

[0046] Specifically, when the application is running, the status data at the operating system platform level and the application level are monitored. The status data at the platform level includes the system's CPU load rate, that is, CPU usage; memory occupancy rate, that is, memory usage; and whether there is a memory dump file (coredump), that is, whether the system has crashed. The status data at the application level includes the CPU occupancy rate when the application is running, that is, the proportion of CPU resources occupied by the application; and whether the application process is alive, that is, whether the application process is running normally. These monitoring data ensure that the system can capture the operating status of the operating system and applications in real time, and trigger event notifications in time to deal with potential problems.

[0047] Further, as an implementation mode of the present invention, the system monitoring strategy includes: When the CPU load rate exceeds the preset first threshold value, a system monitoring event notification is triggered; when the CPU load rate exceeds the preset first threshold value, a system monitoring event notification is triggered, that is, if the system detects that the CPU usage rate exceeds the set threshold (for example, 90%), a system monitoring event notification will be generated, indicating that there may be performance bottlenecks or resource overload problems, so that appropriate measures can be taken in time for diagnosis and processing.

[0048] Alternatively, when the memory occupancy rate exceeds a preset second threshold value, a system monitoring event notification is triggered; when the memory occupancy rate exceeds the preset second threshold value, a system monitoring event notification is triggered, that is, if it is detected that the memory usage rate exceeds the set threshold (for example, 80%), a system monitoring event notification is generated, indicating that the memory may be insufficient or there is a memory leak problem, so that relevant personnel can take timely measures to diagnose and handle it to prevent system performance degradation or crash.

[0049] Alternatively, a system monitoring event notification is triggered when the memory dump file appears; a system monitoring event notification is triggered when a memory dump file (coredump) appears. Specifically, when the generation of a memory dump file is detected, this is a memory snapshot file saved by the operating system when a serious error or crash occurs, which contains the status and error information of the program when it is running. When this happens, a system monitoring event notification is immediately triggered, indicating that a serious system failure has occurred and in-depth analysis and diagnosis are required to find out the cause of the failure as soon as possible and take corresponding repair measures to prevent similar problems from happening again.

[0050] Alternatively, when the CPU occupancy rate exceeds the preset third threshold value, a system monitoring event notification is triggered; when the CPU occupancy rate exceeds the preset third threshold value, a system monitoring event notification is triggered. Specifically, if the CPU usage rate of a specific application exceeds the set threshold (e.g., 50%), an event notification is generated. This measure is used to monitor the excessive occupancy of CPU resources by individual applications, indicating that there may be performance problems or resource contention, thereby ensuring that the application does not affect the overall performance and stability of the system due to high CPU occupancy. This notification can help identify and resolve potential application performance issues in a timely manner.

[0051] Alternatively, a system monitoring event notification is triggered when the application process is not alive or crashes; specifically, a system monitoring event notification is generated when it is detected that a certain application process has stopped running or crashed unexpectedly. This mechanism is used to monitor the normal operation status of the application, prompting possible software errors, insufficient resources or other problems that lead to process termination, so as to conduct timely troubleshooting and recovery operations to ensure the continuous and stable operation of key applications.

[0052] It should be pointed out that the above system monitoring strategies can be used alone or in any combination to meet the system monitoring requirements of different architectures.

[0053] Further, as an implementation mode of the present invention, step S3, monitoring the associated ECU corresponding to the application and triggering a hardware monitoring event notification based on a preset hardware detection strategy, includes: Determine the associated ECU corresponding to the application based on a preset association relationship tree; Subscribe to the DTC information of the associated ECU through the DTC dynamic service interface on the associated ECU.

[0054] Specifically, the monitoring of associated ECUs is mainly aimed at monitoring the microcontroller units (MCUs) or classic electronic control units (ECUs) that the functional applications in the intelligent ECU / HPC depend on, and the monitoring strategy is configured through the association tree between the application (APP) and the ECU / MCU. The structure of the association tree is a hierarchical graphical representation used to describe the relationship between the application (APP) and the microcontroller unit (MCU) or classic electronic control unit (ECU) it depends on. It takes the application as the root node and displays the association of each application with multiple MCUs / ECUs in a hierarchical manner. The connections between the nodes represent the dependencies. Each node in the tree structure contains the diagnostic trouble code (DTC) associated with it. In this way, the system can clearly identify and track the interactions and dependencies between the application and the hardware components, which helps to accurately locate and handle faults.

[0055] By monitoring the diagnostic trouble codes (DTCs) generated or eliminated by the ECU / MCU associated with the application, it is determined whether these faults affect the operation of the application. In a service-based electronic architecture, the system needs to establish a DTC dynamic service interface with the MCU or classic ECU, subscribe to the DTC addition and removal service notifications on these ECUs, so as to obtain and process application-related fault information in real time to ensure the stable operation of the application.

[0056] Further, as an embodiment of the present invention, determining the associated ECU corresponding to the application based on a preset association tree includes: acquiring DTC data corresponding to the associated ECU; and determining the associated DTC corresponding to the application based on the DTC data and the association tree.

[0057] Specifically, the association tree shows the dependency between each APP and multiple MCUs in detail, and records the DTC information of each MCU. Based on this, the association between APP and specific DTC is further refined to generate an APP-level DTC monitoring list. This enables the system to perform more accurate and targeted monitoring and fault diagnosis for the operating status of each APP, ensuring the reliability and performance of the application.

[0058] Based on this, by establishing the monitoring strategy configuration of the associated MCU, the monitoring of the diagnostic trouble codes (DTCs) of the microcontroller unit (MCU) associated with a specific application (APP) can be flexibly controlled. Specifically, according to the configured strategy, determine which MCU's DTCs need to be monitored, and generate the corresponding monitoring list. By updating these policy configurations, the DTC monitoring of the MCU associated with the specified APP can be dynamically started or shut down, thereby achieving accurate monitoring of the APP's operating status. This policy configuration ensures the flexibility and pertinence of monitoring, enabling the system to effectively respond to fault monitoring needs in different applications and hardware environments.

[0059] Furthermore, as an embodiment of the present invention, when subscribing to the DTC information of the associated ECU through the DTC dynamic service interface on the associated ECU, if the DTC dynamic service interface cannot be directly established, the DTC information of the associated ECU is collected through the bus of the vehicle electronic architecture.

[0060] Specifically, if it is not possible to directly establish a service interface with each ECU, the MCUs of several key nodes can be selected to collect the diagnostic trouble code (DTC) information of all ECUs on their respective buses. These MCUs will aggregate the collected DTC data into a vehicle-level DTC storage module. Then, the associated MCU monitoring module establishes a service subscription function with this storage module to regularly obtain and collect the required DTC information for monitoring. In this way, the system can still effectively monitor the DTC information of all ECUs and ensure comprehensive fault monitoring and management of the vehicle's electronic systems, even if a separate service interface cannot be established directly with each ECU.

[0061] Furthermore, as an embodiment of the present invention, step S4, based on the application monitoring event notification, the system monitoring event notification and / or the hardware monitoring event notification, performs analysis and judgment according to a preset monitoring event processing strategy. The monitoring event processing strategy can be gradually optimized and adjusted according to the stage of functional maturity or the experience of operation and maintenance / diagnosis engineering.

[0062] Specifically, as an implementation of the monitoring event processing strategy, once the application monitoring event notification, the system monitoring event notification and / or the hardware monitoring event notification is received, the alarm prompt is directly triggered.

[0063] This implementation is suitable for the initial stage of functional application release, which requires quick response and immediate processing. For example, when a key application fails, the CPU load or memory usage of the operating system exceeds the preset threshold, or an important hardware component fails, the system will immediately issue an alarm notification so that relevant personnel can quickly take measures to diagnose and repair the problem to prevent it from expanding or affecting the safety and performance of the vehicle. This approach ensures that timely response and necessary actions can be taken in emergency situations or high-priority issues.

[0064] Furthermore, as another implementation method of the monitoring event processing strategy, when the system monitoring event notification and / or the hardware monitoring event notification is received, continuous recording and storage are performed; when the application monitoring event notification is received, the alarm prompt is triggered, and a query is made as to whether there is a corresponding system monitoring event notification and / or the hardware monitoring event notification; if so, the system monitoring event notification and / or the hardware monitoring event notification is carried in the alarm prompt based on a preset message structure.

[0065] This implementation method is suitable for the stable stage of functional application release. If a DTC event notification is received from the associated MCU monitoring module, or a CPU load exceeds the threshold value, core dump, or other event notifications are received, the DTC information in the current smart ECU, whether the CPU is overloaded, and other information can be stored first, and then the DTC information in the current smart ECU, whether the CPU is overloaded, and other information can be maintained in the database. After receiving the APP function execution failure event notification, if further alarms need to be triggered, it can be queried in the database to see whether there are currently associated DTCs and CPU overloads. If so, OS and DTC related information can be carried in further triggering alarm events. Then the back-end diagnostic system will make diagnostic judgments based on comprehensive information science, and can continuously optimize the corresponding monitoring strategies and monitoring event processing strategies in various dimensions based on the diagnostic conclusions.

[0066] Furthermore, as another implementation of the monitoring event processing strategy, based on the application monitoring event notification, the system monitoring event notification and / or the hardware monitoring event notification, when the alarm prompt is triggered, a diagnostic action is triggered; wherein the diagnostic action includes triggering the corresponding APP log acquisition, triggering the corresponding MCU logistics data acquisition, and triggering DID information acquisition.

[0067] Specifically, this implementation method is suitable for the later stage of functional application release. If it can be preliminarily identified as an unknown anomaly or a complex problem, the monitoring event processing strategy can decide whether to trigger additional diagnostic actions after reporting the monitoring event alarm, such as triggering the corresponding APP log acquisition, the corresponding MCU logistics data reading, DID information, etc.

[0068] Furthermore, as an implementation mode of the present invention, the alarm prompt is provided in the form of an event and carries data information associated with the abnormal problem.

[0069] Specifically, the message structure of the warning prompt can be defined as follows, which summarizes the information of APP, OS and related ECUs: { “event_type”: “failure / success”, / / mandatory, identifies a success or failure event; "timestamp": "", / / mandatory, identifies the time information when the event occurs; “cause_code”: ””, / / conditional, required to be filled in when the execution fails, used to identify and distinguish different failure events; "detail_info": "", / / optional, describes the detailed information of the event; “severity”: ”” / / mandatory, identifies the severity level of the event, “FATAL, ERROR, WARN, INFO”; "environmentInfo":{ "occu_counter": n, / / The number of times this event has occurred; "occu_info": [time1, time2], / / Record the time when this event occurs multiple times; "os_cpu": xx%, / / indicates the CPU usage of OS; "app_cpu": xx%, / / Indicates the CPU occupied by the APP; "coredump": true / false, / / Indicates whether the system has experienced a coredump; }, “DTCInfo”: { {MCU1: [DTClist]}, {MCU2: [DTClist], …} } } Specifically, the data structure of the application includes event type (identifies whether the event is successful or failed, required), timestamp (time when the event occurs, required), reason code (specific reason for failure, optional), detailed information (detailed description of the event, optional) and severity level (the severity of the event, required, such as FATAL, ERROR, WARN, INFO); the operating system (environmentInfo) part includes the number of times the event occurs, the time point of each occurrence, the CPU usage of the operating system, the CPU usage of the application, and whether a memory dump file (coredump) has occurred; the DTC information included in the associated ECU part (DTCInfo) records the fault code list of different MCUs. This structure ensures the comprehensiveness and meticulousness of the warning information, which facilitates the rapid location and diagnosis of problems.

[0070] For example, refer to Figure 2 The process of an embodiment of a function application monitoring method of the present invention includes: 1. Monitoring event triggers: monitor the running status of the application, including startup, execution, crash, etc.; monitor the status at the operating system level, such as CPU load rate, memory usage, system crash (coredump), etc.; monitor the diagnostic trouble codes (DTCs) generated or cleared by the MCU associated with the application; 2. Event reporting: Optional. When any event (MCU, OS or APP) is detected, a monitoring event notification is triggered. Or it is determined whether the event needs to be reported. If not, the event information is stored. 3. Monitoring event processing: determine whether the APP event needs to carry associated OS and DTC information; 4. Abnormal event alarm reporting: If the APP event needs to carry OS and DTC information, this information will be reported together with the abnormal event alarm; 5. Whether to trigger diagnostic actions: Determine whether further diagnostic actions are needed, such as obtaining logs and diagnostic services. If necessary, perform corresponding diagnostic operations and obtain relevant data for analysis. Among them, the analysis step can be performed by aggregating and analyzing big data based on the accumulation and summary of the case library for abnormal data from the monitoring systems of multiple vehicles in the cloud background, and further connecting the background diagnostic system and the vehicle-cloud interaction system to automatically trigger further data collection for complex problems and push reminders and recommended measures to car owners.

[0071] Through the above steps, the system can comprehensively monitor and manage the functional applications in the vehicle electronic architecture, capture abnormal situations in a timely manner, issue alarms and diagnose, and ensure the stable operation of the application.

[0072] Reference Figure 3The embodiment of the present invention also discloses a functional application monitoring device, which is applied to a vehicle electronic architecture, and includes an application monitoring module 1, a system monitoring module 2, an associated ECU monitoring module 3, a monitoring event processor 4, and a processing result response module 5.

[0073] The application monitoring module 1 is deployed based on the application granularity, and is at least used to monitor the application and trigger application monitoring event notification based on a preset application monitoring strategy; specifically, refer to Figure 4 Each execution result of the APP function application generates an event and sends it to the corresponding application monitoring module 1, which generates an independent<app name> _event.log is used to store and record the execution success and failure events of each APP function. The application monitoring module 1 judges the event according to the configured application monitoring strategy, and triggers the monitoring event notification when the application monitoring strategy is met.

[0074] The system monitoring module 2 is deployed based on the operating system granularity, and is at least used to monitor the operating system corresponding to the application and trigger the system monitoring event notification based on the preset system monitoring strategy; specifically, the system monitoring module 2 mainly monitors the status at the operating system level, and the intelligent ECU / HPC only needs to deploy an independent system monitoring module 2 based on the operating system. The system monitoring strategy triggers the system monitoring event notification by setting a threshold value.

[0075] The associated ECU monitoring module 3 is deployed based on the granularity of the vehicle electronic architecture, and is at least used to monitor the associated ECU corresponding to the application and trigger a hardware monitoring event notification based on a preset hardware detection strategy; specifically, an associated MCU monitoring module can be uniformly deployed in the vehicle electronic architecture, and the monitoring of the associated ECU / MCU is mainly to monitor the MCU / classic ECU on which the successful execution of the functional application in the vehicle electronic architecture depends. The monitoring strategy of the associated ECU monitoring module 3 can be configured through the association relationship tree between APP and ECU / MCU, and whether the DTC generated or eliminated by the ECU associated with the APP is monitored to monitor whether the operation of the APP is affected. Therefore, the functional relationship tree of the APP can be further refined to the association between the APP and the DTC, and an APP-level DTC monitoring list is generated.

[0076] In the service-based vehicle electronic architecture, the associated ECU monitoring module 3 establishes the relevant DTC dynamic service interface with the required MCU / classic ECU and subscribes to the new and clear service notifications of DTC on these MCUs. If the service interface cannot be established directly, the MCUs of several key nodes can collect the DTC information of the ECUs on their respective buses, and then aggregate them to the vehicle-level DTC storage module, and the associated ECU monitoring module 3 establishes a service subscription function with it to collect the DTC information required for monitoring.

[0077] The monitoring event processor 4 is at least used to analyze and judge based on the application monitoring event notification, the system monitoring event notification and / or the hardware monitoring event notification according to a preset monitoring event processing strategy; specifically, the monitoring event reports based on the above three dimensions can be uniformly summarized in the monitoring event processor 4 for analysis and judgment, whether to further issue an alarm prompt, or store and record. The processing strategy of the monitoring event processor 4 also uses the configuration data / file method to set the policy configuration, and supports the flexibility of dynamic updates. In the monitoring event processor 4, the monitoring event notifications from the three dimensions are uniformly analyzed and processed.

[0078] The processing result response module 5 is at least used for recording, storing and / or giving an alarm based on the result of the analysis and judgment. Specifically, the processing result response module 5 includes a monitoring event database and an alarm. The monitoring event database is used to record and store DTC event notifications of the associated MCU monitoring module, or event notifications such as CPU load exceeding a threshold value, core dump, etc. The alarm is used for giving an alarm.

[0079] Exemplarily, based on the present invention, the steps of monitoring the 4 / 5G networking function of the intelligent connection system include: 1. Set application monitoring events at the application level: a. 4 / 5G signal loss for 1 minute generates an event notification; b. Failure to establish an IP / URL connection with the cloud generates an event notification; 2. Set system monitoring data thresholds at the system level: a. CPU usage > 95% alarm notification; b. APP process not surviving alarm notification; c. Coredump generation; 3. Hardware monitoring at the associated ECU level: SIM generates DTC warning notifications; Also configure the processing strategy in the monitoring event processor: Strategy 1. When receiving an application monitoring event notification, record the vehicle speed, location latitude and longitude, and 4 / 5G signal strength value. If there is an OS alarm / DTC alarm at the same time, report it to the cloud backend with the OS&DTC alarm logo; Strategy 2. After receiving the system monitoring event notification, mark the existence of OS alarm, collect the CPU usage of the current APP, and upload the process status information associated with the APP to the cloud background so that after-sales / operation and maintenance personnel can be informed; Strategy 3. After receiving a hardware monitoring event notification, i.e., a DTC alarm notification from the SIM card, the event is recorded and stored locally and marked. It is also checked whether there are any APP & OS level notifications within 30 minutes. If there are any, they are uploaded to the cloud backend to inform the after-sales / operation and maintenance personnel. In this way, after-sales / operation and maintenance personnel in the cloud backend can analyze and further process the relevant alarm notifications received: 1. After receiving the DTC alarm from the SIM card, you can directly contact the technical support of the SIM card supplier. The OS alarm and APP alarm 10 minutes before and after the DTC alarm can be retained and ignored for the time being. They will be processed after the technical analysis of the SIM card supplier. 2. After receiving the coredump alarm at the OS layer, immediately obtain the coredump log remotely and call the OS system engineer to analyze the problem; if a CPU load alarm is received, directly find the APP software engineer to analyze the problem based on the APP usage information in the alarm information; 3. Upon receiving a functional abnormality notification from the APP layer, the corresponding module software personnel can be notified to analyze the problem first and provide support based on the abnormal reason and error module information in the abnormal notification information.

[0080] After case accumulation and diagnosis analysis confirmation, the monitoring event processing strategy can be updated and optimized, and remote control behavior can be automatically triggered or reminders or solution suggestions can be given to the car owner: 1. The SIM card DTC alarm can be notified on the car screen, or the owner can be advised to try to restart the 4 / 5 function at the appropriate time; 2. When the coredump alarm of OS is generated, the coredump log can be directly triggered on the vehicle side and uploaded to the cloud at the same time; when the CPU alarm is generated, the corresponding APP log can be automatically uploaded or the vehicle screen can be reminded to restart manually; 3. The corresponding APP log upload can be directly triggered on the vehicle side according to the reason / module information in the APP abnormal event notification, and the corresponding logistics data information and DID, DTC and other information of the related parts can be remotely obtained after receiving it in the cloud background.

[0081] The embodiment of the present invention also discloses a readable storage medium.

[0082] A readable storage medium stores a computer program, which, when executed by a processor, implements the steps of a function application monitoring method described in any one of the above embodiments.

[0083] It can be understood that computer-readable storage media may include: any entity or device capable of carrying a computer program, a recording medium, a USB flash drive, a mobile hard disk, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), and a software distribution medium, etc. A computer program includes a computer program code. The computer program code may be in source code form, object code form, an executable file, or some intermediate form, etc. A computer-readable storage medium may include: any entity or device capable of carrying a computer program code, a recording medium, a USB flash drive, a mobile hard disk, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), and a software distribution medium, etc.

[0084] In certain embodiments of the present invention, the electronic device may include a controller or a processor, and the controller is a single-chip microcomputer chip that integrates a processor, a memory, a communication module, etc. The processor may refer to a processor included in the controller. The processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc.

[0085] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, segment or portion of code that includes one or more executable instructions for implementing the steps of a specific logical function or process, and the scope of the preferred embodiments of the present invention includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in the reverse order depending on the functions involved, which should be understood by technicians in the technical field to which the embodiments of the present invention belong.

[0086] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0087] The above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features thereof may be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A function application monitoring method, characterized in that: include: Monitor the application and trigger application monitoring event notification based on a preset application monitoring strategy; Monitor the operating system corresponding to the application and trigger a system monitoring event notification based on a preset system monitoring strategy; Monitor the associated ECU corresponding to the application and trigger a hardware monitoring event notification based on a preset hardware detection strategy; Based on the application monitoring event notification, the system monitoring event notification and / or the hardware monitoring event notification, analyzing and judging according to a preset monitoring event processing strategy; Based on the results of the analysis and judgment, records are stored and / or alarms are issued.

2. The function application monitoring method according to claim 1, characterized in that: The monitoring of the application and triggering an application monitoring event notification based on a preset application monitoring strategy includes: Generate and store event data of a preset structure in response to each execution result of the application; Wherein, the event data at least includes: Event type data used to identify the success or failure of the event; Time information data used to identify the time when an event occurs; Failure event data used to distinguish different events when an event fails; When an event fails, it is used to provide the source module data of the failed event source; and, severity level data for identifying the level of the incident.

3. The function application monitoring method according to claim 2, characterized in that: The event data also includes: Details data used to describe event details.

4. The function application monitoring method according to claim 2 or 3, characterized in that: The application monitoring strategy includes: When the severity level data is higher than a preset level, an application monitoring event notification is triggered; and / or When the number of consecutive application failures exceeds a preset number, an application monitoring event notification is triggered; and / or When the failure event data has a preset reason and occurs continuously for more than a preset number of times, an application monitoring event notification is triggered.

5. The function application monitoring method according to claim 1, characterized in that: The monitoring of the operating system corresponding to the application and triggering a system monitoring event notification based on a preset system monitoring strategy includes: When the application is running, monitoring status data at the platform level and at the APP granularity in the operating system; The platform-level status data includes the system CPU load rate, memory usage rate, and whether there is a memory dump file; The state data of the APP granularity includes the CPU occupancy rate when the application is running and whether the application process is alive.

6. The function application monitoring method according to claim 5, characterized in that: The system monitoring strategy includes: When the CPU load rate exceeds a preset first threshold value, a system monitoring event notification is triggered; and / or When the memory usage exceeds a preset second threshold, a system monitoring event notification is triggered; and / or When the memory dump file appears, trigger a system monitoring event notification; and / or When the CPU occupancy rate exceeds a preset third threshold value, a system monitoring event notification is triggered; and / or When the application process is dead or crashes, a system monitoring event notification is triggered.

7. The function application monitoring method according to claim 1, characterized in that: The monitoring of the associated ECU corresponding to the application and triggering of hardware monitoring event notification based on a preset hardware detection strategy include: Determine the associated ECU corresponding to the application based on a preset association relationship tree; Subscribe to the DTC information of the associated ECU through the DTC dynamic service interface on the associated ECU.

8. The function application monitoring method according to claim 7, characterized in that: The determining the associated ECU corresponding to the application based on a preset association relationship tree includes: Obtaining DTC data corresponding to the associated ECU; Determine an associated DTC corresponding to the application based on the DTC data and the association tree.

9. The function application monitoring method according to claim 7, characterized in that: If the DTC dynamic service interface cannot be directly established, the DTC information of the associated ECU is collected through the bus of the vehicle electronic architecture.

10. The function application monitoring method according to claim 1, characterized in that: The monitoring event processing strategy includes: Once the application monitoring event notification, the system monitoring event notification and / or the hardware monitoring event notification are received, the alarm prompt is directly triggered.

11. The function application monitoring method according to claim 1, characterized in that: The monitoring and processing strategy includes: When the system monitoring event notification and / or the hardware monitoring event notification is received, continuously recording and storing; When the application monitoring event notification is received, the alarm prompt is triggered, and a query is made as to whether there is a corresponding system monitoring event notification and / or the hardware monitoring event notification; If so, the system monitoring event notification and / or the hardware monitoring event notification are carried in the alarm prompt based on a preset message structure.

12. The function application monitoring method according to claim 2, characterized in that: The monitoring and processing strategy includes: Based on the application monitoring event notification, the system monitoring event notification and / or the hardware monitoring event notification, when the alarm prompt is triggered, trigger a diagnostic action; Among them, the diagnostic action includes triggering the corresponding APP log acquisition, triggering the corresponding MCU logistics data acquisition, and triggering the DID information acquisition.

13. The function application monitoring method according to claim 1, characterized in that: The warning prompt is provided in the form of an event and carries data information associated with the abnormal problem.

14. A functional application monitoring device, characterized in that: include: An application monitoring module, deployed based on application granularity, at least for monitoring the application and triggering application monitoring event notification based on a preset application monitoring strategy; A system monitoring module, deployed based on the operating system granularity, at least for monitoring the operating system corresponding to the application and triggering a system monitoring event notification based on a preset system monitoring strategy; An associated ECU monitoring module is deployed based on the granularity of the vehicle electronic architecture, and is at least used to monitor the associated ECU corresponding to the application and trigger a hardware monitoring event notification based on a preset hardware detection strategy; A monitoring event processor, at least used to analyze and judge based on the application monitoring event notification, the system monitoring event notification and / or the hardware monitoring event notification according to a preset monitoring event processing strategy; The processing result response module is at least used to record, store and / or issue an alarm based on the result of the analysis and judgment.

15. A computer-readable storage medium, characterized in that: A computer program is stored thereon, and when the computer program is executed by a computer, the function application monitoring method as claimed in any one of claims 1 to 12 is executed.

Images