Function application diagnosis method and device and medium

Abstract

The invention discloses a function application diagnosis method and device and a medium. The method comprises the following steps: receiving a notification event of function application execution failure; collecting multi-dimensional abnormal data information related to execution of the function application from an abnormal data collection platform; based on a predefined root cause analysis model, analyzing the multi-dimensional abnormal data information to determine a root cause causing execution failure of the function application; and according to the root cause, automatically creating a question list and distributing the question list to a corresponding responsible party. The method can automatically analyze and confirm the root cause responsible party of the execution failure of the function application, and greatly shortens the problem analysis and transmission path of the function abnormality.

Description

Technical Field

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

[0002] In the current vehicle architecture based on intelligent ECU (electronic control unit) and HPC (high-performance computing unit), when a functional application software (APP) has a problem or failure, it usually relies on feedback from the car owner, and after-sales or operation and maintenance personnel conduct step-by-step troubleshooting by querying information and consulting system engineers. This process usually involves obtaining APP logs and analyzing them by software development engineers, and even needs to be transferred across modules to the responsible party for further judgment, and finally locate the cause of the failure. This method relies on manual analysis and is highly dependent on the experience of relevant technicians and their understanding of the system architecture.

[0003] Due to the complexity of the vehicle-side electronic architecture and the large number of modules and dependent parties called by the functional APP, it is difficult to quickly determine the root cause of the fault with existing methods, especially when it comes to cross-hardware and software issues, the analysis time and responsibility transfer process are long. In addition, the inability to fully obtain and integrate real-time abnormal data leads to data omissions or insufficiency, making it impossible to provide accurate support for problem location. This inefficient process not only prolongs the problem handling time, but also affects the user experience and vehicle operation efficiency. Summary of the invention

[0004] In response to the above technical problems, the present invention provides a functional application diagnosis method, device and medium, which can automatically analyze and confirm the party responsible for the root cause of the failure of functional application execution, greatly shorten the problem analysis transmission path of functional abnormality, quickly locate the party attributable to the problem, and improve the problem-solving efficiency and user experience of after-sales operation and maintenance.

[0005] A first aspect of the present invention provides a function application diagnosis method, comprising: Receive notification events of application execution failure; Collecting multi-dimensional abnormal data information related to the execution of the functional application from the abnormal data collection platform; Analyze the multi-dimensional abnormal data information based on a predefined root cause analysis model to determine the root cause of the failure of the functional application execution; Based on the stated root cause, problem tickets are automatically created and assigned to the appropriate responsible parties.

[0006] In a possible implementation, the multi-dimensional abnormal data information includes at least one of the following: Fault information of the hardware platform where the function is applied; Abnormal event information of the operating system where the functional application is located; Exception information or negative feedback information of other applications called by the functional application; Function application interacts with the fault information of the electronic control unit.

[0007] In a possible implementation, the root cause analysis model includes key indicator data of multiple dimensions, and each key indicator data corresponds to a weight factor.

[0008] In a possible implementation, the weight factor is used to represent the probability that the corresponding key indicator data will cause the execution failure of the functional application.

[0009] In a possible implementation, the method further includes: According to actual functional application execution failure cases, the key indicator data and their corresponding weight factors in the root cause analysis model are updated.

[0010] In a possible implementation, the updating includes: Add new key indicator data; Adjust the weighting factors of existing key indicator data.

[0011] In a possible implementation, the root cause analysis model uses the execution event name and fault code of the functional application as an index.

[0012] In a possible implementation, the method further includes: When the root cause cannot be determined based on the root cause analysis model, the multi-dimensional abnormal data information is transferred to manual analysis.

[0013] In a possible implementation, the method further includes: The root cause analysis model is updated according to the result of manual analysis.

[0014] In a possible implementation, the method further includes: Create a corresponding exception data collection configuration table for each functional application.

[0015] In a possible implementation, the abnormal data collection configuration table includes a data monitoring party, a data collection item, a triggering collection condition, and an enabling state.

[0016] In a possible implementation, the method further includes: Based on the processing result of the problem ticket, the analysis accuracy of the root cause analysis model is fed back.

[0017] A second aspect of the present invention provides a functional application diagnosis device, comprising: An event receiving module, at least used to receive a notification event of a functional application execution failure; A data collection module, at least used to collect multi-dimensional abnormal data information related to the execution of the functional application from an abnormal data collection platform; A root cause analysis module, at least for analyzing the multi-dimensional abnormal data information based on a predefined root cause analysis model to determine the root cause of the failure of the functional application execution; The work order processing module is at least used to automatically create a problem ticket and assign it to a corresponding responsible party based on the root cause.

[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 according to the first aspect of the embodiment of the present invention is executed.

[0019] The present invention realizes the automated analysis and location of multi-dimensional abnormal data information of functional application execution failures through a predefined root cause analysis model, greatly shortening the process time from data collection, problem analysis to responsibility allocation. Through the all-round data integration of real-time monitoring and abnormal data collection platforms, the cause of the fault and the responsible party can be quickly and accurately located, avoiding the inefficient process of multiple transfers and manual judgment in traditional methods. At the same time, the function of automatically creating and allocating problem tickets improves after-sales and operation and maintenance efficiency, and improves the operating efficiency and user experience of the vehicle throughout its life cycle. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 The present invention is a flowchart of an embodiment of a method for diagnosing functional applications.

[0021] Figure 2 Schematic diagram of the acquisition scenario of multi-dimensional abnormal data information of the present invention.

[0022] Figure 3 The present invention is a flowchart of an embodiment of a method for diagnosing functional applications.

[0023] Figure 4 A topological diagram of an embodiment of a functional application diagnosis device 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] Reference Figure 1 , an embodiment of the present invention discloses a function application diagnosis method, comprising the following steps.

[0027] S1, receiving a notification event of a functional application execution failure.

[0028] Specifically, the function monitoring module of the vehicle can detect the running status of the functional application in real time, and when an abnormality or failure is found, a notification event of execution failure is generated.

[0029] In some implementations, the functional application itself may also have a built-in fault detection mechanism, and actively send an event notification to the abnormal data collection platform when execution fails.

[0030] In some implementations, the operating status of key functional applications can be monitored through an external monitoring system or a third-party application (such as a vehicle remote monitoring platform), and execution failure notifications can be delivered to the system through event push.

[0031] The notification event contains information such as event name, timestamp, function identifier, and related fault codes, providing basic data support for subsequent abnormal data collection and root cause analysis.

[0032] S2, collecting multi-dimensional abnormal data information related to the execution of the functional application from the abnormal data collection platform.

[0033] Specifically, refer to Figure 2 , collecting multi-dimensional abnormal data information related to the execution of the functional application from the abnormal data collection platform can automatically obtain all abnormal data associated with the functional application from the abnormal data collection platform of the vehicle through the real-time monitoring system, including hardware fault information (such as HPC hardware DTC, communication link abnormality, chip temperature alarm, etc.), operating system fault information (such as high CPU usage, insufficient memory, process hang, etc.), directly called third-party application abnormalities (such as call failure, response timeout, etc.) and related ECU fault information (such as DTC data of related ECU).

[0034] In some implementations, different data collection strategies may be set according to different functional modules and execution logics of functional applications to screen and filter specific abnormal data.

[0035] During the collection process, data can be dynamically updated and supplemented based on trigger conditions (such as the occurrence of abnormal events or the exceeding of thresholds) to ensure that the collected abnormal information is complete and timely, providing high-quality input data for subsequent analysis.

[0036] S3, based on a predefined root cause analysis model, analyzing the multi-dimensional abnormal data information to determine the root cause of the failure of the functional application execution.

[0037] Specifically, the corresponding analysis model can be found in the root cause analysis model library according to the name and fault code of the function execution failure event, and the collected abnormal data can be matched and analyzed using the multi-dimensional indicators in the model (such as hardware failure, operating system abnormality, called third-party application abnormality, and related ECU failure). The correlation of each indicator to the execution failure is calculated based on its weight factor. When the maturity of the matching key indicator weight factor reaches the set standard, the root cause of the problem can be directly located.

[0038] In some implementations, if there are multiple indicators that meet the conditions, the most likely root cause may be selected through a priority strategy or a highest weight factor.

[0039] In addition, in some embodiments, the matching analysis of the root cause analysis model can be dynamically adjusted in combination with the actual operating scenario. When the root cause cannot be determined, the problem can be transferred to manual intervention. The results of the manual analysis are further used to optimize and improve the root cause analysis model to improve the accuracy and efficiency of future automated diagnosis.

[0040] S4, based on the root cause, automatically creates a problem ticket and assigns it to the corresponding responsible party.

[0041] Specifically, after locating the root cause of the failure of functional application execution through the root cause analysis model, a problem ticket can be automatically generated based on the analysis results of the model. The problem ticket content includes the event name, fault code, root cause description, analysis basis and recommended responsible party.

[0042] If the responsible party has been identified, the problem ticket can be automatically assigned to the corresponding module or team (such as the hardware department, operating system development group, or third-party application support).

[0043] If the analysis fails to locate the responsible party, the problem ticket will be marked as requiring manual intervention, and the relevant personnel will be alerted through a notification mechanism.

[0044] In some implementations, the allocation of problem tickets may be integrated into an after-sales operation and maintenance management system to support real-time tracking of processing progress.

[0045] In addition, in some implementations, the feedback results of the problem ticket, such as the accuracy of the root cause analysis and the processing time efficiency, can also be recorded, which can be further used to optimize the allocation logic and model weight factors to make the creation and allocation of problem tickets more efficient and accurate.

[0046] For example, taking the overall upgrade of HPC (high-performance computing platform) as an example, first, the upgrade APP (LUM) runs on the S32G chip of HPC. After receiving the event notification of "upgrade_failure" and the fault code of "8295_transmit_failure" in step S1, step S2 collects multi-dimensional abnormal data related to the LUM upgrade in real time, including MCU fault information, S32G OS abnormal events (such as CPU usage 100%), and negative feedback information of calling function applications (such as "get_package_not_completed").

[0047] Next, step S3 uses the event name and fault code as indexes to search for a matching LUM root cause analysis model in the root cause analysis model library. If the model fails to match the key indicator data that meets the maturity standard, the problem is transferred to manual analysis. For example, when the analysis confirms that the root cause is that the LUM process is suspended, the key indicator data is added to the root cause analysis model, and its weight factor is set to 5, indicating that its maturity standard is met; if the match is successful, step S4 is executed to automatically infer the root cause and generate a problem ticket to push to the relevant responsible party (such as the operating system team).

[0048] This scenario illustrates the complete process of the functional application diagnosis method from event detection, data collection to root cause analysis, and demonstrates the high efficiency of the embodiments of the present invention.

[0049] The functional application diagnosis method described in the above implementation mode receives notification events of functional application execution failure in real time, combines comprehensive collection of multi-dimensional abnormal data, uses predefined root cause analysis models to quickly and accurately locate the cause of the fault, and automatically generates a problem ticket and assigns it to the responsible party, thereby achieving full automation and efficiency of the diagnosis process. Compared with the traditional method that relies on manual analysis, this method greatly shortens the time from data collection to problem allocation, and improves the accuracy and efficiency of fault diagnosis. At the same time, the method also supports dynamic optimization of the model, improves the diagnostic capabilities of the system through continuous iteration, and ultimately improves the operational efficiency and user experience of the vehicle throughout its life cycle.

[0050] Further, as an embodiment of the present invention, the multi-dimensional abnormal data information includes at least one of the following: Fault information of the hardware platform where the function is applied; Abnormal event information of the operating system where the functional application is located; Exception information or negative feedback information of other applications called by the functional application; Function application interacts with the fault information of the electronic control unit.

[0051] Specifically, the fault information of the hardware platform where the functional application is located refers to various abnormalities or fault data that occur on the hardware platform on which the functional application depends. This information reflects the possible impact of the hardware level on the normal operation of the functional application. Fault information includes DTC (diagnostic fault code) of the hardware platform, communication link failure, abnormal status of hardware modules (such as chip overheating, temperature protection triggering), and abnormal operation of hardware resources (such as power supply problems). For example, when a module in the HPC hardware has a communication interruption or overload problem, this type of fault information will be collected and associated with the event of the functional application's execution failure, providing data support for subsequent root cause analysis. This information is of great significance for diagnosing whether the functional application fails due to underlying hardware problems.

[0052] The abnormal event information of the operating system where the functional application is located refers to various abnormal data that occurs in the operating system environment where the functional application runs. These data reflect the possible impact of the operating system level on the normal operation of the functional application. Abnormal event information includes key resource abnormalities of the operating system, such as excessive CPU usage, insufficient memory, operating system thread or process hang, file system error, etc. When these abnormal events occur in the operating system, it may directly lead to the failure of the functional application to run or performance degradation. This information is collected through real-time monitoring triggers. As part of the multi-dimensional abnormal data, it provides key input for the subsequent root cause analysis model, which helps to determine whether the functional application failure is related to the operating system abnormality.

[0053] Exception information or negative feedback information of other applications called by functional applications refers to the abnormal status or error feedback returned by these called applications when the functional application interacts with other applications during execution. This type of information covers execution exceptions of the called application on the vehicle or cloud, such as call rejection, response timeout, error code return, or failure to complete the expected task. Exception information and negative feedback data are captured through real-time monitoring and associated with the execution failure event of the functional application to evaluate the impact of the called application on the functional application failure. These data are assigned weight factors in the root cause analysis model to help quickly determine whether the functional application failure is caused by anomalies or bad feedback from external applications, providing an important basis for accurately locating the problem.

[0054] The fault information of the electronic control unit interacted by the functional application refers to the fault or abnormal information that occurs in the electronic control unit (ECU) inside the vehicle when the functional application interacts with these ECUs during operation. This type of information includes DTCs (diagnostic fault codes) generated by the ECU, such as communication interruption, hardware damage, or functional abnormality. When the functional application calls the service or data interface of the ECU, if the interacting ECU fails, such as sensor data transmission failure or execution command failure, these fault information will be recorded and collected in real time to analyze the root cause of the failure of the functional application execution. These data are associated with abnormal events of the functional application to help determine whether the fault originates from the relevant ECU, providing key support for subsequent problem diagnosis and responsibility attribution.

[0055] Further, as an implementation of the present invention, the root cause analysis model includes key indicator data of multiple dimensions, and each key indicator data corresponds to a weight factor. The weight factor is used to indicate the probability that the corresponding key indicator data causes the execution failure of the functional application.

[0056] Specifically, the root cause analysis model includes multiple dimensions of key indicator data, which include hardware failure, operating system anomalies, called third-party application anomalies, and interactive electronic control unit failures. Each key indicator data is equipped with a weight factor to indicate the degree of correlation of the indicator with the failure of functional application execution.

[0057] For example, the root cause analysis model uses the event name and fault code as indexes, and combines multi-dimensional abnormal data for matching analysis. The value of the weight factor reflects the credibility of the indicator to the cause of the fault. For example, the higher the weight factor, the more likely the indicator is to be the root cause of the fault. The initial value of the weight factor can be set through system design and continuously optimized through case verification in actual operation. When multiple key indicators are matched at the same time, the final analysis conclusion can be determined through the priority strategy of the weight factor to achieve efficient and accurate fault location.

[0058] The weight factor is used to quantify the impact of each key indicator data on the failure of functional application execution, and its value indicates the probability of the indicator causing the failure. Specifically, when the root cause analysis model matches the abnormal data, the correlation between each key indicator and the failure event is calculated based on the weight factor of each key indicator. The higher the weight factor, the greater the possibility that the key indicator causes the current failure.

[0059] The initial weight factor can be set based on experience or system design, and dynamically adjusted through actual operating data. For example, when a key indicator is identified as the root cause in multiple fault analyses, its weight factor will gradually increase to enhance the credibility of the indicator in the model. Ultimately, the weight factor is used to guide the system to prioritize the most likely root cause, providing a quantitative basis for quickly and accurately locating faults.

[0060] The data structure and data format of the root cause analysis model can be implemented in various flexible ways, such as dictionaries, tables, excel, xml or json definitions, but they must all contain clear monitoring data indicators and weight factor values. Exemplarily, the key data elements of the root cause analysis model and their definitions include event name, fault code, fault information of the hardware platform where the functional application is located, abnormal information of the operating system (app_os), abnormal information of other applications called, and fault information of the interactive electronic control unit. Each data element is stored in a list form, containing specific abnormal information and the associated weight factor with the failure of the functional application execution. The weight factor is used to quantify the probability of the abnormality affecting the failure, and the value range is set to 1 to 10. The root cause analysis model constructs an index through these data elements and weight factors to locate the root cause of the failure of the functional application execution, providing support for quick and accurate problem analysis.

[0061] Furthermore, as an embodiment of the present invention, the function application diagnosis method further includes: According to actual functional application execution failure cases, the key indicator data and their corresponding weight factors in the root cause analysis model are updated.

[0062] The updating includes adding new key indicator data and adjusting the weight factors of existing key indicator data.

[0063] Specifically, after the functional application fails to execute, the actual root cause is determined through manual or automatic analysis, and the analysis results can be further compared with the key indicator data in the existing root cause analysis model.

[0064] In some implementations, if the root cause data in the analysis result does not exist in the model, the key indicator data is added and assigned an initial weight factor value (eg, a default value of 3).

[0065] In other embodiments, if the data already exists in the model, its weight factor is adjusted based on its accuracy in locating the current fault. For example, if the data is confirmed to be the main cause of the fault, its weight factor will be increased (such as increased to 5 or higher). Conversely, if it is found that its correlation is low, the weight factor can be reduced.

[0066] In addition, based on multiple cases in actual operation, the weight distribution of different key indicator data in the model can be continuously optimized to ensure that the model more accurately reflects the causes of failures in actual operation scenarios, thereby improving the accuracy and efficiency of future diagnosis.

[0067] Further, as an implementation mode of the present invention, the root cause analysis model uses the execution event name and fault code of the functional application as an index.

[0068] Specifically, when a functional application fails to execute, a failure notification event containing the event name and fault code will be generated. These two fields are used as unique identifiers to locate the corresponding model in the root cause analysis model library. The model defines multi-dimensional key indicator data associated with the event and fault code, such as hardware failure, operating system anomalies, abnormalities in other called applications, and interactive electronic control unit failures. By matching the event name and fault code, the corresponding model can be quickly located, and the collected abnormal data can be analyzed in combination with the key indicators and weight factors defined in the model to determine the root cause of the failure. This indexing mechanism ensures rapid search and accurate analysis of the model, which helps to achieve efficient automated fault diagnosis.

[0069] Furthermore, as an embodiment of the present invention, the functional application diagnosis method further includes: when the root cause cannot be determined based on the root cause analysis model, transferring the multi-dimensional abnormal data information to manual analysis. According to the result of the manual analysis, updating the root cause analysis model.

[0070] Specifically, the current abnormal data is matched with the key indicators in the root cause analysis model. If the weight factors of all matching items do not meet the set maturity standards or the relevant key indicators do not exist in the model, a detailed abnormal data report is generated, including the event name, fault code, and the collected abnormal information of hardware, operating system, related applications, and ECU. Subsequently, the abnormal data is pushed to the designated analysis team or responsible department for manual investigation. After manual analysis, feedback on the analysis results is obtained to update the root cause analysis model, add uncovered key indicator data, or adjust relevant weight factors, so as to continuously improve the accuracy of the model and enhance the automation capabilities of future diagnosis.

[0071] Furthermore, as an embodiment of the present invention, the function application diagnosis method further includes: A corresponding abnormal data collection configuration table is created for each functional application. The abnormal data collection configuration table includes data monitoring parties, data collection items, trigger collection conditions and enable status.

[0072] Specifically, all abnormal data items related to the functional application are defined in advance according to the execution process of the functional application and the hardware, operating system, third-party applications and interactive electronic control units (ECUs) on which it depends. In the configuration table, the specific functional module of the functional application is used as the table header to list each data monitoring party (such as hardware platform, operating system, etc.), data collection items (such as DTC code, CPU occupancy, memory usage, call failure information, etc.), trigger collection conditions (such as fault occurrence or indicator exceeding the threshold) and enable status (such as on / off). The configuration table can be flexibly adjusted according to the actual needs of the functional application, and supports setting different data collection strategies for different functional modules to ensure the comprehensiveness and accuracy of abnormal data. The content of the configuration table will be synchronized to the abnormal data collection platform to achieve real-time monitoring and data collection of functional application anomalies, providing high-quality data support for subsequent root cause analysis.

[0073] Furthermore, as an embodiment of the present invention, the function application diagnosis method further includes: Based on the processing result of the problem ticket, the analysis accuracy of the root cause analysis model is fed back.

[0074] Specifically, when the problem ticket is processed, the actual processing results are compared with the diagnostic conclusions of the root cause analysis model. If the model successfully matches and accurately locates the party responsible for the problem, the diagnosis is marked as accurate, and the weight factors of the relevant key indicator data are appropriately increased to further optimize the maturity of the model; if the model fails to match or fails to accurately locate the root cause, the model is adjusted accordingly based on the final cause of the fault obtained by manual analysis, including adding uncovered key indicator data or correcting the weight factors of existing key indicators. Through a continuous feedback mechanism, the root cause analysis model can be gradually improved to improve the accuracy and automation level of the model in future fault diagnosis, while greatly reducing the frequency of manual intervention.

[0075] Reference Figure 3 The implementation process of a specific embodiment of the functional application diagnosis method of the present invention includes: 1. Functional application execution failure event trigger: When a functional application fails and triggers an execution failure event, the event is immediately recorded, including the event name, timestamp, and fault code. This information serves as input for subsequent diagnosis and starts the abnormal data collection and analysis process 2. Collect multi-dimensional abnormal data: Extract multi-dimensional abnormal data related to the failure of functional application execution from the abnormal data collection platform, including hardware platform failure information, operating system abnormal information, abnormal information of other called applications, and failure information of the interacting electronic control unit (ECU). These data are filtered and summarized through predefined collection strategies and trigger conditions to ensure the integrity and accuracy of the information; 3. Root cause analysis model matching: Use the root cause analysis model to analyze the collected abnormal data and try to match the root cause of the functional application failure. If the key indicator data and its weight factor in the model can meet the set maturity standard, the system can determine the party responsible for the problem (step 4b); otherwise, the process enters step 4a; 4a. Manual intervention and problem confirmation: If the root cause analysis model cannot locate the root cause (step 4a), the system will transfer the abnormal data and event information to the manual analysis team for processing. After manual analysis, the responsible party is identified and entered into the system, and new root cause data is fed back to optimize and update the existing model; 4b. Create a problem ticket and assign responsible parties: Once the responsible party for the problem is determined, a problem ticket is automatically generated, including event details, fault description, and recommended responsible departments. The problem ticket is assigned to the corresponding responsible party for processing, and the process enters the resolution phase; 5. Model optimization and feedback: After the problem is solved, the accuracy of the root cause analysis is fed back based on the problem ticket processing results. For the successfully matched model, the weight factor of the relevant key indicators is increased; for the newly discovered root cause data, it is added to the model and assigned an initial weight. This feedback mechanism ensures the dynamic optimization of the model and the continuous improvement of the diagnostic ability.

[0076] Reference Figure 4 The embodiment of the present invention further discloses a functional application diagnosis device, including an event receiving module 1, a data acquisition module 2, a root cause analysis module 3 and a work order processing module 4.

[0077] The event receiving module 1 is at least used to receive a notification event of a functional application execution failure.

[0078] Specifically, when a functional application fails to execute, the event receiving module 1 receives a notification event through the system's built-in real-time monitoring mechanism. The event content includes key information such as event name, timestamp, and fault code, which are used to identify the specific functional execution failure scenario.

[0079] The event receiving module 1 can also be connected to an external monitoring system or a vehicle data uploading module to receive event push triggered by abnormality detection.

[0080] In addition, the event receiving module 2 can support multiple communication protocols (such as CAN bus, Ethernet or cloud data transmission protocol) to ensure the reliable transmission of event information. The received event information is then passed to the data acquisition module 2 to start the subsequent abnormal data collection and root cause analysis process, thereby achieving full process automation and efficient response of diagnosis.

[0081] The data collection module 2 is at least used to collect multi-dimensional abnormal data information related to the execution of the functional application from the abnormal data collection platform.

[0082] Specifically, when the event receiving module 1 receives the notification event of the failure of the functional application execution, the data collection module 2 obtains the multi-dimensional abnormal data related to the functional application from the abnormal data collection platform according to the preset collection strategy. These data include the fault information of the hardware platform where the functional application is located, the abnormal event information of the operating system, the abnormal information of other application programs called, and the fault information of the interacting electronic control unit (ECU).

[0083] Data collection module 2 uses real-time monitoring and triggering mechanisms to filter and aggregate data according to set collection conditions (such as fault codes or over-limit indicators) to ensure the integrity and timeliness of abnormal information. The collected multi-dimensional abnormal data is then passed to root cause analysis module 3 for further analysis of the root cause of the fault. The entire process ensures the accuracy and efficiency of data collection and provides sufficient data support for subsequent diagnosis.

[0084] The root cause analysis module 3 is at least used to analyze the multi-dimensional abnormal data information based on a predefined root cause analysis model to determine the root cause of the failure of the functional application execution.

[0085] Specifically, after the data collection module 2 collects the multi-dimensional abnormal data of the functional application execution failure, the root cause analysis module 3 analyzes the abnormal data according to the event name and fault code provided by the event receiving module 1 using a predefined root cause analysis model.

[0086] The root cause analysis module 3 matches the abnormal data with the key indicator data in the model and combines the weight factors to evaluate the possibility of each abnormal data causing the fault.

[0087] If the key indicators that meet the weight factor requirements are matched, the root cause analysis module 3 can automatically locate the root cause of the fault (process 4b); if the key indicators that meet the requirements cannot be matched, the root cause analysis module 2 will transfer the abnormal data to manual analysis (process 4a). The analysis results are used to generate problem tickets or optimize the root cause analysis model to ensure the accuracy and efficiency of subsequent diagnosis. The root cause analysis module 2 is the core component for quickly and accurately locating the responsible party for the problem.

[0088] The work order processing module 4 is at least used to automatically create a problem ticket and assign it to a corresponding responsible party based on the root cause.

[0089] Specifically, after the root cause analysis module 3 determines the root cause of the failure of the functional application execution, the work order processing module 4 will automatically generate a problem ticket, which includes the event name, fault code, root cause description and responsible party information.

[0090] If the root cause analysis model is successfully matched (process 4b), the work order processing module 4 directly assigns the problem ticket to the corresponding responsible party for processing; if the model fails to match successfully (process 4a), the work order processing module 4 generates a problem ticket based on the manual analysis results and also assigns it to the relevant responsible party (process 5a).

[0091] After the problem ticket is processed, the work order processing module 4 will record the processing feedback and pass it to the root cause analysis module 3 for optimizing the key indicators and weight factors of the analysis model (process 6).

[0092] The work order processing module 4 realizes the automated creation, allocation and tracking management of problem tickets, ensuring rapid problem handling and providing closed-loop support for model optimization.

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

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

[0095] 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.

[0096] 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.

[0097] 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.

[0098] 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.

[0099] 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 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 diagnosis method, characterized in that: include: Receive notification events of application execution failure; Collecting multi-dimensional abnormal data information related to the execution of the functional application from an abnormal data collection platform; Analyze the multi-dimensional abnormal data information based on a predefined root cause analysis model to determine the root cause of the failure of the functional application execution; Based on the stated root cause, problem tickets are automatically created and assigned to the appropriate responsible parties.

2. The function application diagnosis method according to claim 1, characterized in that: The multi-dimensional abnormal data information includes at least one of the following: Fault information of the hardware platform where the function is applied; Abnormal event information of the operating system where the functional application is located; Exception information or negative feedback information of other applications called by the functional application; Function application interacts with the fault information of the electronic control unit.

3. The function application diagnosis method according to claim 2, characterized in that: The root cause analysis model includes key indicator data of multiple dimensions, and each key indicator data corresponds to a weight factor.

4. The function application diagnosis method according to claim 3, characterized in that: The weight factor is used to represent the probability that the corresponding key indicator data will cause the execution failure of the functional application.

5. The function application diagnosis method according to claim 3, characterized in that: Also includes: According to actual functional application execution failure cases, the key indicator data and their corresponding weight factors in the root cause analysis model are updated.

6. The function application diagnosis method according to claim 5, characterized in that: The updates include: Add new key indicator data; Adjust the weighting factors of existing key indicator data.

7. The function application diagnosis method according to claim 1, characterized in that: The root cause analysis model uses the execution event name and fault code of the functional application as an index.

8. The function application diagnosis method according to claim 1, characterized in that: Also includes: When the root cause cannot be determined based on the root cause analysis model, the multi-dimensional abnormal data information is transferred to manual analysis.

9. The function application diagnosis method according to claim 8, characterized in that: Also includes: The root cause analysis model is updated according to the result of manual analysis.

10. The function application diagnosis method according to claim 1, characterized in that: Also includes: Create a corresponding exception data collection configuration table for each functional application.

11. The function application diagnosis method according to claim 10, characterized in that: The abnormal data collection configuration table includes data monitoring parties, data collection items, triggering collection conditions and enabling status.

12. The function application diagnosis method according to claim 1, characterized in that: Also includes: Based on the processing result of the problem ticket, the analysis accuracy of the root cause analysis model is fed back.

13. A functional application diagnosis device, characterized in that: The device comprises: An event receiving module, at least used to receive a notification event of a functional application execution failure; A data collection module, at least used to collect multi-dimensional abnormal data information related to the execution of the functional application from an abnormal data collection platform; A root cause analysis module, at least for analyzing the multi-dimensional abnormal data information based on a predefined root cause analysis model to determine the root cause of the failure of the functional application execution; The work order processing module is at least used to automatically create a problem ticket and assign it to a corresponding responsible party based on the root cause.

14. 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 diagnosis method according to any one of claims 1 to 13 is executed.

Images