Method, device, server, storage medium and system for monitoring automotive diagnostic software

Abstract

The application relates to the technical field of automobile diagnosis, and discloses a method, device, server, storage medium and system for monitoring automobile diagnosis software. The method comprises the following steps: after a new version installation package is acquired, a change file list is generated by comparing the file differences between the new version and the old version; based on a mapping relationship, the monitoring probe configuration information associated with each change file is inquired to generate a monitoring probe configuration file; the configuration file is embedded into a differential update package and is delivered to a terminal device; service index data collected by the terminal device is received, and the software running state is judged through multidimensional analysis; and when an exception is found, accurate positioning alarm information is generated. The application realizes deep integration of automobile diagnosis software updating and monitoring, can actively find diagnosis function defects, significantly improves problem identification and positioning efficiency, and effectively solves the lag problem existing in the traditional manual reporting and post-log analysis mode.

Description

Technical Field

[0001] This invention relates to the field of automotive diagnostic technology, and in particular to a method, apparatus, server, storage medium, and system for monitoring automotive diagnostic software. Background Technology

[0002] As automotive electronics become increasingly intelligent, the functions of electronic control units (ECUs) are becoming more complex and diverse. Currently, automotive diagnostic software is developing towards modularity and cloud-based deployment. Against this backdrop, differential updates have become the mainstream software update method. This method effectively saves network bandwidth and update time by transmitting only the differences between versions.

[0003] However, this update model also brings new technical challenges. When the terminal device runs a new version of the automotive diagnostic software, several diagnostic function defects may be introduced. For example, certain fault codes may not be read for some specific vehicle models, data stream measurement values ​​may deviate, motion tests may fail to execute, and the flashing process may experience lag.

[0004] Currently, the discovery of these defects mainly relies on two methods. One is manual reporting by engineers after discovering the problem, and the other is reproducing the problem through specially organized testing. Both methods have significant time lags and low processing efficiency. Due to the untimely discovery of defects, it often takes a long time for them to be identified and confirmed.

[0005] During the post-defect analysis phase, engineers need to retrieve issue logs for investigation. These logs are typically quite large, slowing down problem localization. Furthermore, the transmission and storage of large amounts of log data puts pressure on network bandwidth and storage resources. Summary of the Invention

[0006] Based on this, it is necessary to address the technical problems of existing technologies, such as delayed detection, reliance on manual reporting, and low efficiency of log analysis, and propose a method, device, server, storage medium, and system for monitoring automotive diagnostic software.

[0007] In a first aspect, a method for monitoring automotive diagnostic software is provided, the method comprising:

[0008] Obtain the new version installation package of the vehicle diagnostic software, and compare the file differences between the new version installation package and the old version installation package to generate a change file list including at least one changed file;

[0009] Based on the mapping relationship, query the monitoring probe configuration information associated with each change file to generate a monitoring probe configuration file;

[0010] A differential update package is generated based on the data differences between the new version installation package and the old version installation package, and the monitoring probe configuration file is added to the differential update package. The differential update package including the monitoring probe configuration file is then sent to multiple specified terminal devices.

[0011] The system receives business indicator data collected by each terminal device based on the monitoring probe configuration file, and if the vehicle diagnostic software in the terminal device is found to be malfunctioning based on the business indicator data, it generates alarm information for that terminal device.

[0012] Secondly, an apparatus for monitoring automotive diagnostic software is provided, the apparatus comprising:

[0013] The comparison module is used to obtain a new version installation package of the vehicle diagnostic software and compare the file differences between the new version installation package and the old version installation package to generate a change file list including at least one changed file.

[0014] The mapping module is used to query the monitoring probe configuration information associated with each change file based on the mapping relationship, so as to generate the monitoring probe configuration file;

[0015] The generation module is used to generate a differential update package based on the data differences between the new version installation package and the old version installation package, add the monitoring probe configuration file to the differential update package, and send the differential update package including the monitoring probe configuration file to multiple specified terminal devices.

[0016] The alarm module is used to receive business indicator data collected by each terminal device based on the monitoring probe configuration file. If the vehicle diagnostic software in the terminal device is found to be malfunctioning based on the business indicator data, an alarm message is generated for that terminal device.

[0017] Thirdly, a server is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method for monitoring automotive diagnostic software described above.

[0018] Fourthly, a computer-readable storage medium is provided, the computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the method for monitoring vehicle diagnostic software described above.

[0019] Fifthly, the vehicle monitoring system provided includes:

[0020] The server is configured to: acquire a new version installation package of automotive diagnostic software; compare file differences between the new version installation package and the old version installation package to generate a list of changed files including at least one changed file; query monitoring probe configuration information associated with each changed file according to a mapping relationship to generate a monitoring probe configuration file; generate a differential update package based on data differences between the new version installation package and the old version installation package, add the monitoring probe configuration file to the differential update package, and send the differential update package including the monitoring probe configuration file to multiple specified terminal devices; receive business indicator data collected by each terminal device based on the monitoring probe configuration file; and generate alarm information for the terminal device if the automotive diagnostic software in the terminal device is found to be running abnormally based on the business indicator data.

[0021] The terminal device is configured to receive a differential update package from the server, including the monitoring probe configuration file; extract and remove the monitoring probe configuration file from the differential update package; merge the local old version installation package and the differential update package to obtain a new version installation package; perform an installation operation using the new version installation package and run the vehicle diagnostic software; collect business indicator data using the monitoring indicators indicated by the monitoring probe configuration file; and report the business indicator data to the server.

[0022] The beneficial effects of this application are:

[0023] This application achieves real-time monitoring and rapid response to anomalies in the operational status of automotive diagnostic software after an update by deeply integrating the monitoring mechanism into the software differential update process. By automatically analyzing the scope of change impact during the differential update package generation stage and embedding dedicated monitoring probes strongly correlated with diagnostic functions, a "monitoring as an update" technical mechanism is established.

[0024] This application effectively addresses the shortcomings and delayed detection issues inherent in traditional methods that rely on manual reporting and post-event log analysis. Through real-time collection and analysis of business metrics data, it proactively identifies software anomalies and precisely pinpoints them to specific functional modules and change files, significantly improving problem location efficiency. Furthermore, based on a multi-dimensional anomaly assessment mechanism, it can promptly identify potential operational risks, providing data support for software quality evaluation.

[0025] This application can significantly reduce reliance on manual analysis, reduce resource consumption caused by massive log transmission and storage, and form a complete closed-loop management from software updates to operation monitoring, providing a systematic guarantee for the reliable operation of automotive diagnostic software.

[0026] This application integrates software updates with real-time monitoring through embedded monitoring probes, solving the problem of delayed defect detection in automotive diagnostic software. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0028] in:

[0029] Figure 1 This is a diagram illustrating the application environment of a method for monitoring vehicle diagnostic software in one embodiment.

[0030] Figure 2 This is a flowchart of a method for monitoring vehicle diagnostic software in one embodiment;

[0031] Figure 3 This is a structural block diagram of a device for monitoring vehicle diagnostic software in one embodiment;

[0032] Figure 4 This is a structural block diagram of a server in one embodiment. Detailed Implementation

[0033] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0034] The method for monitoring vehicle diagnostic software provided in this embodiment of the invention can be applied to, for example... Figure 1 In the application environment, server 120 obtains the new version installation package of the automotive diagnostic software; compares the file differences between the new version installation package and the old version installation package to generate a list of changed files, including at least one changed file; queries the monitoring probe configuration information associated with each changed file according to the mapping relationship to generate a monitoring probe configuration file; the monitoring probe configuration file includes at least one monitoring probe configuration information, which includes at least one monitoring indicator; generates a differential update package based on the data differences between the new version installation package and the old version installation package, and adds the monitoring probe configuration file to the differential update package, and sends the differential update package including the monitoring probe configuration file to multiple specified terminal devices; receives business indicator data collected by each terminal device based on the monitoring probe configuration file; determines whether the automotive diagnostic software in each terminal device is running abnormally based on the business indicator data; if so, generates alarm information for that terminal device and executes alarm operations.

[0035] Terminal device 110 is used to receive a differential update package from the server, including a monitoring probe configuration file, extract and remove the monitoring probe configuration file from the differential update package, merge the old version installation package and the differential update package to obtain a new version installation package, run the vehicle diagnostic software after performing the installation operation using the new version installation package, and collect business indicator data using the monitoring indicators indicated by the monitoring probe configuration file, and report the business indicator data to the server.

[0036] The terminal device can be, but is not limited to, a professional automotive diagnostic instrument, an in-vehicle intelligent terminal, or a mobile diagnostic device. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will now be described in detail through specific embodiments.

[0037] Please see Figure 2 As shown, Figure 2 A flowchart illustrating a method for monitoring vehicle diagnostic software provided in an embodiment of the present invention includes the following steps:

[0038] S1. Obtain the new version installation package of the vehicle diagnostic software, and compare the file differences between the new version installation package and the old version installation package to generate a change file list including at least one changed file.

[0039] The server can obtain new version installation packages of automotive diagnostic software from designated software distribution channels. Software distribution channels refer to standardized platforms used for storing, managing, and distributing software version files. These channels constitute the official path for software to flow from the development environment to the deployment environment, ensuring the reliability, security, and traceability of software distribution. Software distribution channels can be: continuous integration with a continuous deployment platform, a version control system, or a dedicated file storage server or cloud server service.

[0040] The continuous integration and continuous deployment platform automates the code changes submitted by developers, executes the compilation, packaging, and version marking processes, and generates a deployable installation package. The server obtains the new version installation package by calling the application programming interface provided by the platform or by listening for event notifications when specific build tasks are completed.

[0041] Version control systems are not only used to manage source code, but their release functionality can also be used to store the compiled results of official versions. Servers locate and retrieve the corresponding new version installation package by accessing specific tags or release branches within the version control system.

[0042] The development team uploads the final software installation package to a file storage server or cloud storage service and organizes it according to a specified directory structure. The server then downloads the required new version of the automotive diagnostic software installation package from a designated network location via standard file transfer protocols or cloud service interfaces.

[0043] The new version installation package is a complete program collection containing all executable files, configuration files, and resource files. After receiving the new version installation package data via a secure transmission protocol, the server will perform an integrity verification process to ensure that the installation package has not been damaged or tampered with during transmission. After verification, the server will temporarily store the new version installation package in a designated storage area.

[0044] For example, when the automotive diagnostic software is upgraded to version 2.1.0, the server automatically retrieves an installation package file named diagnostic_tool_v2.1.0.zip from the company's internal software distribution platform. After verifying the integrity of the compressed package through a hash check, the server saves it for further processing.

[0045] The server obtains the old version of the installation package currently used on the terminal device as a comparison benchmark. The server performs a file-level comparison between the new version installation package and the old version. Files are the most basic building blocks of a software installation package and the smallest granular object for version management. Files in this application include, but are not limited to, binary library files, configuration files, script files, and resource files. The comparison process in this application can be as follows: by parsing the internal file structure of the two installation packages, each file within them is compared one by one. The comparison is based on file paths, file content characteristics, and file attribute information. The server can accurately identify entirely new files added in the new version relative to the old version currently used on the terminal device (i.e., newly added files), existing files whose content has been modified (i.e., modified files), and original files that have been removed (i.e., deleted files). The server organizes and summarizes all this information about changed files to form a structured list of changed files.

[0046] For example, the server obtains the installation package of the diagnostic software version 2.0.5 currently running on the terminal device as a comparison benchmark. When comparing the new version 2.1.0 installation package with the version 2.0.5 installation package, analysis reveals that the new version adds a dynamic link library file bms_diagnosis.so for battery management system diagnostics and modifies the configuration file engine_protocol.json that defines the communication protocol. The server records these changes in a list of changed files, noting the change type and full path of each file.

[0047] S3. Based on the mapping relationship, query the monitoring probe configuration information associated with each change file to generate a monitoring probe configuration file.

[0048] The server, based on a pre-established mapping relationship, queries the corresponding monitoring probe configuration information for each changed file identified in the changed file list. By analyzing the changed file list, the impact of the changes on vehicle diagnostic functions is analyzed, and monitoring probe configurations are generated. This is achieved by querying a mapping library that maintains the association between changed files and monitoring probe configurations. Based on the file type and functional category of the changed file, the server retrieves a matching monitoring probe configuration template from the mapping library, thereby generating dedicated monitoring probe configuration information for each changed file. The server integrates and compiles all this monitoring probe configuration information to ultimately form a unified monitoring probe configuration file.

[0049] For example, when engine control-related dynamic link library files exist in the changed file list, the server retrieves the corresponding fault code reading monitoring probe configuration template by querying the mapping relationship. Based on this template, the server generates configuration information including monitoring indicators such as fault code reading success rate and reading response time. Simultaneously, for changes to battery management-related configuration files, the server uses the battery parameter monitoring probe configuration template to generate configuration information including monitoring indicators such as voltage measurement accuracy and current sampling frequency. The server integrates this configuration information and outputs a complete monitoring probe configuration file.

[0050] In one embodiment of this application, S3, based on the mapping relationship, query the monitoring probe configuration information associated with each change file to generate a monitoring probe configuration file, including:

[0051] S4. Generate a differential update package based on the data differences between the new version installation package and the old version installation package, add the monitoring probe configuration file to the differential update package, and send the differential update package including the monitoring probe configuration file to multiple specified terminal devices.

[0052] The server generates a differential update package based on the data differences between the new and old versions of the installation package using a differential algorithm. This differential update package contains only the difference data between the two versions, significantly reducing data transmission volume. Simultaneously, the server embeds the monitoring probe configuration file generated in step S4 into the differential update package, specifically by writing the configuration file content into the metadata area or a specific data segment reserved in the differential update package format. After assembly, the server can simultaneously distribute the differential update package containing the monitoring probe configuration file to multiple specified terminal devices via a content delivery network.

[0053] For example, the server uses the bsdiff differential algorithm to generate a differential update package for upgrading diagnostic software from version 2.0.5 to version 2.1.0. This differential update package contains only the binary difference data between the two versions. The server writes the monitoring probe configuration file in JSON format into the metadata area of ​​the differential update package, forming a complete enhanced update package. Subsequently, the server simultaneously distributes this enhanced differential update package to all automotive diagnostic devices that need to be upgraded via a content delivery network.

[0054] S4. Receive business indicator data collected by each terminal device based on the monitoring probe configuration file. If the vehicle diagnostic software in the terminal device is found to be running abnormally based on the business indicator data, generate alarm information for that terminal device.

[0055] The server monitors the data transmission ports of each terminal device. Business indicator data is runtime information collected in real-time by the terminal devices during the execution of corresponding vehicle diagnostic functions, based on the monitoring probe configuration files in the differential update package. The server performs integrity verification and standardization processing on the received business indicator data to ensure that the data format is uniform and conforms to expected specifications. The pre-processed data is stored in a dedicated database to provide data support for subsequent anomaly analysis.

[0056] For example, when a terminal device performs an engine fault code reading operation, it collects metrics such as reading success rate and response time based on the monitoring probe configuration, and then packages and reports this data. The server continuously receives business indicator data from different terminal devices, verifies and formats it, and then stores it. The business indicator data includes software version identifiers, functional module information, specific monitoring indicator values, and timestamps.

[0057] The server performs multi-dimensional analysis on the received business indicator data to assess the operational status of the automotive diagnostic software on the terminal devices. The analysis process can employ a combination of techniques, including comparing the business indicator data with preset thresholds, detecting deviations from a dynamic performance baseline established based on historical data, and using crowd analysis methods to identify clusters of terminal devices exhibiting abnormal behavior patterns. Based on the analysis results, the server determines whether the software operational status of each terminal device is abnormal.

[0058] When the server determines that the automotive diagnostic software in the terminal device is malfunctioning, it generates an alarm message. The alarm message records the specific characteristics of the anomaly, including the software version involved, the abnormal functional module, the associated change files, and the identifier of the affected terminal device. After generating the alarm message, the server performs corresponding alarm operations, including sending a warning notification to the operation and maintenance management system, displaying the abnormal status on the monitoring interface, and automatically triggering corresponding processing procedures according to preset policies.

[0059] For example, after the server confirms that the diagnostic software version 2.1.0 is experiencing an engine fault code reading malfunction on a specific model of terminal device, it generates an alarm message containing the software version information, the name of the malfunction, a list of related change files, and the affected device number. The server then sends an alarm notification containing detailed analysis results to the maintenance personnel, highlights the abnormal status on the monitoring screen, and instructs the terminal device to initiate a version rollback procedure to restore the software version of the affected terminal device to a stable state.

[0060] In one or more possible embodiments, S1, comparing the file differences between the new version installation package and the old version installation package to generate a list of changed files including at least one changed file, includes:

[0061] S11. Iterate through the files of the new version installation package to generate a first file set, and iterate through the files of the old version installation package to generate a second file set.

[0062] S12. Compare the file differences between the first file set and the second file set to obtain at least one modified file; the modified file is a file whose content has been modified, a newly added file, or a deleted file.

[0063] S13. Generate a list of changed files based on the change type, file path, and specific change content of each changed file.

[0064] In S11, the server scans both the new and old version installation packages, parsing their internal file structures. By recursively accessing each directory level in the new version installation package, the server obtains and records the complete path information and basic attributes of each file. For the new version installation package, the server organizes all the file information it contains into a first file set; for the old version installation package used as the comparison benchmark, the server organizes it in the same way to form a second file set.

[0065] For example, when the server parses the installation package of the diagnostic software version 2.1.0, it records the engine_dtc.so dynamic link library file, the bms_communication.cfg configuration file, and multiple data definition files contained therein, forming a first file set. Simultaneously, the server performs the same operation on the 2.0.5 version installation package currently used by the terminal device, recording all file information contained therein, forming a second file set.

[0066] In S12, the server performs a comprehensive comparative analysis of the first and second file sets. This comparison process unfolds from two dimensions: file existence and file content. By comparing the path information of files in the two sets, the server identifies newly added and deleted files. For files with the same path in both sets, the server further compares their content characteristics, including but not limited to file size, last modification time, and content hash value, thereby accurately identifying files whose content has been modified.

[0067] For example, by comparing two file sets, the server finds a new_module.dll file that exists in the first file set but not in the second file set, and identifies it as a newly added file; it finds an old_module.dll file that exists in the second file set but not in the first file set, and identifies it as a deleted file; at the same time, it finds a config.xml file that exists in both sets but has different content hash values, and identifies it as a file whose content has been modified.

[0068] In S13, the server organizes all identified changed file information, recording the change type, full file path, and specific description of the changes for each file. The change type is clearly marked as addition, modification, or deletion. For files whose content has been modified, the server also records key change details. Finally, the server organizes this information into a structured list of changed files, providing complete and accurate input data for subsequent impact analysis.

[0069] For example, the server generates a list of changed files, which contains three entries: the first entry records the newly added file new_module.dll and its full path; the second entry records the deleted file old_module.dll and its full path; the third entry records the full path of the modified file config.xml, and details the changes, specifically the adjustment of the communication timeout parameter from 5000 milliseconds to 3000 milliseconds.

[0070] Through the above systematic file difference comparison process, the server can comprehensively and accurately identify all file-level changes of the new version installation package compared to the old version installation package, and generate a structured list of changed files.

[0071] In one possible embodiment, the mapping relationship includes a first mapping relationship and a second mapping relationship;

[0072] S2. Based on the mapping relationship, query the monitoring probe configuration information associated with each changed file to generate a monitoring probe configuration file, including:

[0073] S21. Based on the first mapping relationship, map each change file to the affected vehicle diagnostic function to generate a list of affected functions including at least one vehicle diagnostic function.

[0074] The first mapping relationship is a pre-established correspondence defining the relationship between each functional module in the automotive diagnostic software and the technical resources upon which its implementation depends. This first mapping relationship is constructed manually or automatically by analyzing the software architecture and functional dependencies, recording the correspondence between functions and file paths. In practice, the first mapping relationship can be represented by a functional resource mapping library. This library uses a structured data organization, where each automotive diagnostic function is assigned a unique identifier and associated with a set of technical resources necessary to implement that function. These resources include, but are not limited to, executable program files, dynamic link libraries, configuration files, and script files. The server queries the first mapping relationship to match each file in the changed file list with a specific automotive diagnostic function. By comparing the path information of the changed files with the resource paths recorded in the mapping relationship, the server identifies the automotive diagnostic functions affected by file changes and generates a list of affected functions accordingly.

[0075] For example, when a modification record for the bms_communication.cfg configuration file exists in the change file list, the server queries the functional resource mapping relationship and finds that this configuration file is associated with the battery management system communication function. Simultaneously, for the newly added engine_dtc.so file, the server determines through mapping relationships that it affects the engine fault code reading function. The server then compiles this identified functional information into a list of affected functions.

[0076] S22. Query the second mapping relationship to determine the monitoring probe configuration information associated with each vehicle diagnostic function, so as to generate a monitoring probe configuration file; the monitoring probe configuration file includes at least one monitoring probe configuration information, and the monitoring probe configuration information includes at least one monitoring indicator.

[0077] The second mapping relationship is based on predefined monitoring templates for diagnostic function types, including indicator sets and alarm rules. The server queries the pre-configured second mapping relationship to assign appropriate monitoring probe configuration information to each automotive diagnostic function in the affected function list. The second mapping relationship refers to the correspondence rules between automotive diagnostic functions and monitoring probe configuration information, established based on the type characteristics and monitoring requirements of the diagnostic functions. In specific implementation, the second mapping relationship is reflected through a monitoring probe template library. Each monitoring probe template defines a standardized monitoring scheme for a specific category of automotive diagnostic functions, including the set of monitoring indicators to be collected, the indicator collection method, triggering conditions, and anomaly judgment thresholds. Based on the specific characteristics of the affected automotive diagnostic functions, the server selects the corresponding monitoring probe template from the monitoring probe template library and generates dedicated monitoring probe configuration information for that function by instantiating the template parameters. Finally, the server integrates all generated monitoring probe configuration information to form a complete monitoring probe configuration file.

[0078] For example, when the list of affected functions includes engine fault code reading, the server queries the second mapping relationship and selects a monitoring probe template specifically for fault code reading functions. Based on the monitoring probe template, the server generates specific monitoring probe configuration information, which defines monitoring metrics including reading success rate, average response time, and the number of reading failures for specific fault codes, while also setting the normal value range and collection frequency for each metric. For battery management system communication functions, the server configures a monitoring scheme including metrics such as connection success rate and communication timeout rate. Finally, the server integrates these configurations into a unified monitoring probe configuration file.

[0079] It should be noted that when the server cannot find a matching monitoring probe configuration in the second mapping relationship, a manual mapping creation process will be initiated. The server first generates a mapping missing alarm interface on the management platform, displaying detailed information about the unmatched diagnostic function, including the function name, protocol type, and function description. Administrators can use this interface to query the existing monitoring probe template library and select an applicable basic template or create a new monitoring template based on the function's characteristics.

[0080] After template selection, the administrator configures a dedicated set of monitoring metrics and their alarm thresholds based on the specific monitoring requirements of the functions. The server provides configuration verification functionality to ensure the integrity and rationality of the newly created mapping relationships. After the administrator confirms that the configuration is correct, the server persistently stores the newly established mapping relationship in the second mapping relationship and assigns a unique identifier to the mapping entry. Simultaneously, the server records the mapping creation time and operator information, establishing a complete version tracking record.

[0081] In one possible embodiment, S21, mapping each change file to the affected vehicle diagnostic function according to the first mapping relationship, includes:

[0082] S211. If the changed file is a file whose content has been modified or a deleted file, extract the file path of the changed file;

[0083] S212. Search the first mapping relationship for a function entry that contains the file path;

[0084] S213. Mark the vehicle diagnostic function corresponding to the matched function entry as the affected vehicle diagnostic function; and / or

[0085] S214. If the modified file is a newly added file, obtain the function names of each function contained in the modified file;

[0086] S215. Match the function name in the first mapping relationship according to its semantic information;

[0087] S216. Mark the vehicle diagnostic function corresponding to the matched function entry as the affected vehicle diagnostic function.

[0088] In S211, when a changed file is a file whose content has been modified or a file that needs to be deleted, the server first extracts the complete storage path information of the file from the change record. This path information serves as a key identifier for subsequent queries of mapping relationships, and its accuracy and completeness must be ensured.

[0089] For example, if the server detects that the parameters in the bms_communication.cfg configuration file have been modified, it will extract its full path / config / bms_communication.cfg. Similarly, for the file legacy_module.dll marked for deletion, the server will also extract its full path / modules / legacy_module.dll.

[0090] In S212, the server uses the extracted file path as the query condition to perform a full-text search in the functional resource mapping library established by the first mapping relationship. This search process aims to find all functional entries that list the file path as their dependent resource, ensuring that no potentially affected functionalities are missed.

[0091] For example, the server uses the path / config / bms_communication.cfg as a query condition to search the feature resource map library for all feature entries containing that path in the resource list.

[0092] In S213, for each function entry matched in the query results, the server extracts its corresponding vehicle diagnostic function identifier and officially marks it as a diagnostic function affected by this document change. These marked functions will be included in the list of affected functions.

[0093] For example, if the query results show that the path / config / bms_communication.cfg is associated with the battery management system communication function, the server will mark the battery management system communication function as an affected function and add it to the list of affected functions.

[0094] In S214, for newly added modified files, especially executable files, the server obtains the name identifiers of the various functions provided by the file by parsing its symbol table or metadata information. The function names usually reflect the function of the file.

[0095] For example, for a newly added file new_action_test.so, the server parses its symbol table and obtains that the name of its main exported function is perform_ags_actuation_test.

[0096] In step S215, the server analyzes the semantic information contained in the acquired function names and performs similarity matching with the function description information recorded in the first mapping relationship. This semantic-based matching method can effectively establish the association between new files and the existing functional system. The specific matching methods include: using natural language processing technology to segment function names, extract keywords, and calculate similarity with function descriptions.

[0097] For example, the server analyzes the function name perform_ags_actuation_test, identifies keywords such as AGS (Active Grille System) and actuator (execution) contained within it, and searches for function entries in the function resource mapping library whose function descriptions contain these keywords.

[0098] When the server performs semantic analysis on function names, it first segments the function name string, breaking it down into lexical units with independent meanings. This process needs to consider programming naming conventions, including recognizing the role of uppercase letters as separators and underscore separators in camelCase. The server then builds a standardized lexicon, mapping the decomposed words to standard terms to eliminate differences between abbreviations and polymorphic words.

[0099] After completing vocabulary standardization, the server expands concepts through a semantic network, obtaining synonyms, near-synonyms, and related terms for each word to construct a complete semantic representation. Based on this, the server calculates the similarity between the expanded semantic set and the functional description information recorded in the first mapping relationship, employing a semantic matching algorithm based on a vector space model to evaluate the semantic association strength between function names and functional descriptions.

[0100] For example, when the server receives the function name performAGSCalibration, it first decomposes it into three lexical units using camelCase segmentation: perform, AGS, and Calibration. Then, it queries a normalized lexicon, mapping AGS to an active air intake grille system and Calibration to calibration. The server then uses a semantic network to obtain related terms for these words, forming a semantic set containing terms such as execution, active air intake grille, calibration, and adjustment.

[0101] In S216, after finding the corresponding function entry through semantic matching, the server officially marks the vehicle diagnostic function corresponding to that entry as a function affected by the new file and includes it in the list of affected functions.

[0102] For example, if the server finds the active air intake grille motion test function through semantic matching, it will mark the function as an affected function and add it to the list of affected functions.

[0103] It should be noted that when the server cannot find the corresponding vehicle diagnostic function for the changed file in the first mapping relationship through the automatic matching mechanism, the server will generate a mapping missing alarm message and send it to the management interface. The mapping missing alarm message lists the unmatched changed file path and its related characteristic information in detail, and also provides an interface for manually creating mapping relationships. Through this interface, the administrator can query the detailed information of the changed file, select the appropriate function from the existing list of vehicle diagnostic functions, or create a new function entry to establish a mapping relationship between the file and the function. After the server verifies the format of the mapping relationship confirmed by the administrator, it persists it to the first mapping relationship, forming a new mapping entry.

[0104] For example, when analyzing the newly added file advanced_lighting_control.so, the server cannot find the corresponding function in the first mapping relationship through the automatic matching mechanism. The server then generates an alarm message in the management interface, displaying the file path and the parsed function name. After reviewing the file details, the administrator confirms that the file implements a new matrix headlight control function, selects the function from the function list, and establishes a mapping relationship. The server adds this mapping relationship to the first mapping relationship, forming a new entry containing the file path and the corresponding matrix headlight control function.

[0105] It should be noted that, in addition to using function names for mapping, this embodiment also incorporates auxiliary mapping methods such as code call relationships and configuration file comments to improve the accuracy of the mapping.

[0106] This embodiment, through the aforementioned differentiated mapping mechanism, enables the server to employ the most suitable mapping strategy for different types of file changes, accurately establishing the correlation between file changes and functional impacts. The mapping method in this embodiment ensures the comprehensiveness and accuracy of affected function identification, providing a reliable basis for the subsequent precise deployment of monitoring probes and guaranteeing the monitorability of updated automotive diagnostic software from the source.

[0107] In one possible embodiment of this application, S22, querying the second mapping relationship to determine the monitoring probe configuration information associated with each vehicle diagnostic function, includes:

[0108] S221. Match the vehicle diagnostic function in the second mapping relationship according to the function name and / or protocol type.

[0109] S222. If a matching monitoring probe template is found.

[0110] S223. Assign values ​​to the monitoring probe template to obtain monitoring probe configuration information, which includes: probe ID, probe name, monitoring indicators, and alarm rules.

[0111] In S221, the function name is a textual identifier for the business attributes and technical characteristics of the vehicle diagnostic function, and the protocol type refers to the standardized communication protocol followed by the vehicle diagnostic function during execution. The server performs a search and matching based on the characteristic attributes of the affected vehicle diagnostic functions in the second mapping relationship. The server extracts keywords from the function name and their corresponding diagnostic protocol types as query conditions, searching for monitoring probe templates with the same or similar functional categories in the monitoring probe template library. During the matching process, the server employs a multi-level matching strategy, prioritizing exact name matching, followed by keyword matching, and finally protocol type matching, ensuring that the most suitable monitoring solution is found for each diagnostic function.

[0112] For example, for the engine fault code reading function, the server extracts "engine fault code reading" as a keyword and identifies that the function conforms to the UDS diagnostic protocol. The server first searches for a template with an exact match in the monitoring probe template library. If no match is found, it searches for templates containing the keyword "fault code reading," and finally finds a monitoring probe template suitable for the UDS protocol.

[0113] In S222, once the server successfully finds the monitoring probe template corresponding to the vehicle diagnostic function in the second mapping relationship, it confirms that the template is suitable for the monitoring requirements of the current function. The server verifies the applicability of the template, including checking whether the monitoring indicators defined by the template cover the key operating parameters of the function, whether the collection frequency meets the business requirements, and whether the alarm rules match the importance of the function.

[0114] For example, the server matches the power management monitoring probe template to the voltage reading function of the battery management system. After verification, the voltage measurement accuracy index, sampling frequency setting and voltage anomaly threshold defined by the template meet the monitoring requirements of the function. The server confirms that this template will be used for subsequent configuration generation.

[0115] In S223, the process of assigning values ​​to monitoring probe templates by the server is based on the context information of specific diagnostic functions, replacing the parameter variables in the template with specific numerical values. This process first generates a globally unique identifier for each probe instance, which is unique throughout the entire monitoring system. Subsequently, the server determines the naming rules for the probes based on the specific characteristics of the diagnostic functions, ensuring that the names reflect their monitoring objectives and functional affiliations.

[0116] During the monitoring metric assignment phase, the server sets specific collection parameters and calculation rules for each monitoring metric based on the technical specifications and performance requirements of the diagnostic function. This includes determining basic parameters such as the sampling frequency, data aggregation method, and numerical units. For metrics requiring threshold judgment, the server sets reasonable normal range boundaries and anomaly judgment conditions based on the function's quality standards and historical operating data.

[0117] During the alarm rule assignment process, the server configures multi-level alarm triggering conditions based on the importance of the diagnostic function and the scope of the anomaly's impact. This includes setting the alarm severity level classification, trigger threshold, and alarm notification method. The server also establishes an alarm escalation mechanism and configures automatic reporting rules for persistent anomalies.

[0118] For example, when the server instantiates a monitoring probe for the engine temperature reading function, it first generates a unique probe identifier PT_ENGINE_TEMP_001. Based on the functional characteristics, the probe is named the engine temperature monitoring probe, the temperature acquisition frequency is set to once per second, and the data aggregation method is to calculate the average value per minute.

[0119] The server is set to a normal temperature range of -40℃ to +120℃. A primary alarm is triggered when the temperature exceeds +120℃, and a critical alarm is triggered when the temperature exceeds +150℃. An alarm escalation rule is also configured so that if the probe on the same device triggers a critical alarm three times consecutively, an emergency notification is automatically sent to the device administrator.

[0120] This embodiment utilizes a systematic template assignment mechanism, enabling the server to quickly generate monitoring probe configurations that precisely match specific diagnostic functions. This parameterized configuration generation method ensures both the technical consistency of the monitoring solution and accommodates the personalized monitoring needs of different functions, significantly improving the efficiency and quality of monitoring deployment and providing refined monitoring assurance for the stable operation of automotive diagnostic software.

[0121] In one possible embodiment of this application, S3, adding the monitoring probe configuration file to the differential update package, includes:

[0122] S31. Serialize the monitoring probe configuration file to obtain a byte array.

[0123] S32. Generate a metadata block based on the byte array, the configuration identifier, the length of the byte array, and the version number of the new version installation package.

[0124] S33. Embed the metadata block into the header or footer of the differential update package.

[0125] In S31, the server converts the structured monitoring probe configuration file into a unified serialization format, generating a continuous sequence of bytes. This serialization process, following a predefined data exchange format specification, transforms the text information and its hierarchical structure in the configuration file into a binary data stream. This conversion process ensures that the configuration information maintains a consistent format and data integrity when transmitted between different systems, while simultaneously reducing data volume to improve transmission efficiency.

[0126] For example, the server will serialize a JSON-formatted configuration file containing probe identifiers, monitoring metrics, and alerting rules into a binary byte array. This byte array fully preserves all the parameters and their logical relationships from the original configuration, but exists in a more compact binary form.

[0127] In S32, the configuration identifier represents the data identity. By reading the configuration identifier, the receiver can quickly determine the type and format of the metadata block without context information. The server combines the serialized byte array with relevant descriptive information to generate a complete metadata block. This metadata block contains specific identification fields to distinguish data types, records the actual length of the byte array for subsequent parsing, and associates corresponding software version information to ensure the matching relationship between configuration and version. The metadata block is assembled according to a predefined structure, with fields arranged in a fixed order and supplemented with necessary padding bits to ensure data alignment.

[0128] For example, the server creates a metadata block that contains a magic word MONP (i.e., configuration identifier) ​​to identify monitoring configuration data, records configuration data with a length of 1024 bytes, specifies the applicable software version number as 2.1.0, and finally appends the serialized byte array to these descriptive information to form a complete metadata block.

[0129] In S33, the server writes the generated metadata block to a specific location in the differential update package. Based on the differential update package format specification, the server chooses to place the metadata block in a reserved area at the beginning of the file or append it to the end. This embedding process ensures that the metadata block and the differential data together constitute a complete update package file, while maintaining the format compatibility of the original differential update package. After embedding is complete, the server recalculates and updates the size checksum information for the entire file.

[0130] For example, the server writes a block of metadata containing monitoring configuration to a reserved area at the end of the differential update package file. This area's location and size conform to the differential package format specification. After embedding, the server updates the checksum field at the end of the file to ensure the integrity of the entire file.

[0131] This embodiment achieves seamless integration of monitoring configuration information and differential update packages through serialization processing and metadata block embedding mechanisms. This integration method maintains the integrity and compatibility of the differential update package format, ensuring that monitoring configurations can be distributed synchronously with software updates, while providing a standardized parsing interface for client use. This technical solution guarantees timely deployment of monitoring configurations without interfering with existing update processes.

[0132] In one possible embodiment of this application, a method for determining whether the vehicle diagnostic software is malfunctioning based on the business indicator data includes:

[0133] A. Compare the business indicator data with the preset static threshold, and determine whether the vehicle diagnostic software in the terminal device is running abnormally based on the comparison result;

[0134] B. Compare the business indicator data with dynamic thresholds established based on historical data, and determine whether the vehicle diagnostic software in the terminal device is malfunctioning based on the comparison results; or

[0135] C. Cluster the business indicator data from various terminal devices, and determine whether the vehicle diagnostic software in the terminal device is malfunctioning based on the clustering results.

[0136] In step A, the server directly compares the received business indicator data with pre-set fixed thresholds, and determines the operating status of the automotive diagnostic software in the terminal device based on the comparison result. These static thresholds are absolute value boundaries set based on the technical specifications and operational requirements of the automotive diagnostic function, possessing clear and fixed characteristics. By comparing the business indicator data with these preset thresholds in real time, the server can quickly identify abnormal situations that significantly deviate from the normal range.

[0137] During the comparison process, the server independently evaluates each monitoring indicator. When any key indicator exceeds its corresponding static threshold range, the server determines that the automotive diagnostic software on that terminal device is malfunctioning. This judgment method is characterized by its immediacy and determinism, making it suitable for the rapid identification of serious anomalies.

[0138] For example, if a server sets a static threshold of 95% for the success rate of establishing a diagnostic session, and receives a success rate of 90% from a terminal device, the server compares this data and finds it to be lower than the preset threshold, then determines that the diagnostic software on that device is malfunctioning. As another example, if a server sets a static threshold of 500 milliseconds for data stream read response time, and detects that the average response time of a device reaches 800 milliseconds, the server immediately determines that there is a performance anomaly.

[0139] In step B, the server establishes a dynamic performance baseline with time characteristics by analyzing business indicator data accumulated over historical periods. This dynamic threshold is not a fixed value, but rather an intelligent boundary that adaptively adjusts with different time periods and operating environments. The server uses time series analysis technology, combined with the statistical characteristics of historical data, to construct a dynamic threshold model that reflects normal fluctuation ranges.

[0140] The process of establishing a dynamic threshold in this embodiment includes:

[0141] The process of establishing dynamic thresholds on the server begins with the systematic collection of historical business indicator data. The server selects business indicator data from the most recent complete period as training samples. This period typically covers multiple complete work cycles to ensure data representativeness. The server preprocesses the collected historical data, including removing obvious outliers and handling missing data, to ensure that the data quality meets the modeling requirements.

[0142] After data preprocessing, the server uses time series analysis to construct a dynamic performance baseline model. This model establishes independent statistical models for different time periods, fully considering the normal fluctuation characteristics of business indicators across different time periods. The server calculates the statistical characteristic values ​​of business indicators within each time window, including key parameters such as the mean and standard deviation, forming a baseline reference line. The mean represents the arithmetic mean of historical data and is used to measure the central trend; the standard deviation represents the dispersion of the data and is used to set the dynamic range.

[0143] Based on statistical characteristic values, the server applies statistical process control principles to set a dynamic threshold range. This range is centered on a benchmark value and bounded by integer multiples of the standard deviation, forming a normal value interval that varies over time. The server periodically updates the dynamic threshold model, incorporating the latest historical data to maintain the timeliness and accuracy of the thresholds.

[0144] It should be noted that when establishing dynamic thresholds, if there is no historical data, a predefined static threshold or a threshold based on similar functionality should be used as the initial value.

[0145] For example, the server collects diagnostic session setup time data from all terminal devices during the peak period from 9:00 AM to 11:00 AM daily over the past 14 days. After data cleaning, the server calculates the average time for this period to be 220 milliseconds, with a standard deviation of 30 milliseconds. Applying the 3-sigma principle, the server sets a dynamic threshold upper limit of 310 milliseconds and a lower limit of 130 milliseconds for this period.

[0146] For example, regarding the engine fault code reading function, the server analyzed the operating data of the same model of equipment over the past 30 days and found that the average success rate on Mondays was significantly higher than on weekends. The server established independent dynamic threshold models for weekdays and weekends, with the threshold range being 98.5% to 99.9% on weekdays and 97.8% to 99.7% on weekends.

[0147] During the anomaly detection process, the server compares the real-time received business indicator data with the dynamic thresholds for the corresponding time period. This comparison process considers the temporal characteristics and statistical distribution patterns of the data, and assesses whether it exceeds the normal fluctuation range by calculating the degree of deviation of the current data from the dynamic baseline. The server sets anomaly detection rules based on statistical principles. When the real-time data shows a significant deviation from the dynamic threshold, the server determines that the automotive diagnostic software on the terminal device is malfunctioning.

[0148] In step C, the server performs cluster analysis on business indicator data from multiple terminal devices, automatically dividing devices with similar behavioral characteristics into different groups using an unsupervised learning algorithm. For example, using the K-means clustering algorithm, devices are divided into normal, abnormal, and other groups based on business indicators. The server selects key business indicators that reflect the software's operating status as clustering features and uses a suitable clustering algorithm to divide the device groups. After completing the clustering, the server analyzes the statistical characteristics of each cluster to identify abnormal groups that show significant differences from the mainstream device behavior patterns.

[0149] The server determines the criteria for identifying anomalous clusters by comparing the distribution characteristics of business metrics across different clusters and combining this with device context information. For devices identified as anomalous clusters, the server determines that the automotive diagnostic software they are running is malfunctioning. Simultaneously, the server analyzes the common characteristics of devices in anomalous clusters to provide clues for problem localization.

[0150] It should be noted that this embodiment can “use anomaly detection algorithms (such as Isolation Forest) to assist clustering, or set a minimum sample size requirement to reduce the clustering algorithm’s susceptibility to data volume and noise and thus reduce the likelihood of misjudgment, thereby enhancing the robustness of clustering.”

[0151] For example, a server collects diagnostic session establishment success rate and average response time data from 1000 terminal devices. Using a clustering algorithm, these devices are divided into three main groups: the first group represents the mainstream cluster of normally functioning devices; the second group represents the outlier cluster of devices exhibiting obvious abnormalities; and the existence of the third group reflects the diversity of device behavior. In real-world applications, in addition to completely normal and obviously abnormal devices, there is usually a transitional or uniquely characterized group (i.e., the third group). This group may include devices with slight performance fluctuations, those on the verge of abnormality, or those with special behavioral patterns. This division avoids simplistic binary representation of complex device behavior and is more in line with engineering practice.

[0152] Specifically, the first group in this embodiment comprises approximately 950 devices, with a success rate exceeding 99.2% and a response time within 200 milliseconds; the second group comprises approximately 50 devices, with a success rate below 85% and a response time exceeding 800 milliseconds. The server identifies the latter as the abnormal group, confirming that the diagnostic software on these devices is malfunctioning. Further analysis reveals that the abnormal devices are all running version 2.1.0 diagnostic software and equipped with version 1.2 ECU hardware. Based on this, the server determines that there is a compatibility issue between version 2.1.0 software and version 1.2 ECU hardware.

[0153] In one possible embodiment of this application, S4, generating alarm information for the terminal device includes:

[0154] S41. Determine one or more monitoring indicators corresponding to the business indicator data;

[0155] S42. Query the corresponding target vehicle diagnostic function in the second mapping relationship according to each monitoring indicator, and use the target vehicle diagnostic function as the vehicle diagnostic function that triggers the abnormality.

[0156] S43. Based on the target vehicle diagnostic function, query the corresponding target change file in the first mapping relationship, and perform an intersection operation between the target change file and the change file list to obtain the change file that triggers the abnormality;

[0157] S44. Generate alarm information based on the vehicle diagnostic function that triggered the anomaly and the change file, and push the alarm information to the pre-bound maintenance personnel; the alarm information includes alarm ID, timestamp, version number of the vehicle diagnostic software, function name of the vehicle diagnostic function that triggered the anomaly, and file name of the change file that triggered the anomaly.

[0158] In S41, the server parses the received business indicator data packets and identifies the specific monitoring indicator items contained within. Based on the structured format of the data packets, the server extracts key data points characterizing the software's operational status. These data points directly correspond to the monitoring indicators defined in the monitoring probe configuration. The server then categorizes and organizes the extracted monitoring indicators, establishing a data foundation for subsequent anomaly tracing and analysis.

[0159] For example, the server parses data packets reported by a terminal device and finds a 92% success rate for diagnostic session establishment, an average response time of 450 milliseconds, and five failed attempts to read a specific fault code. The server confirms that these data points correspond to the session success rate metric, response time metric, and specific fault code reading metric defined in the monitoring configuration.

[0160] In S42, the server, based on the identified abnormal monitoring indicators, reverse-engineers the vehicle diagnostic functions associated with these indicators in the second mapping relationship. The server queries the diagnostic function monitoring probe mapping library to determine the monitoring probe to which each monitoring indicator belongs, and then finds the specific vehicle diagnostic function monitored by that probe. The server marks these identified functions as the target vehicle diagnostic functions that triggered the anomaly.

[0161] For example, if the server detects an anomaly in the session success rate metric, it determines through a query of the second mapping relationship that the metric belongs to a diagnostic session monitoring probe, which is responsible for monitoring the diagnostic session management function. Based on this, the server marks the diagnostic session management function as the target function that triggered the anomaly.

[0162] In step S43, the server searches for the technical resources required to implement the identified target vehicle diagnostic function in the first mapping relationship. The server retrieves a complete list of file resources corresponding to the function by querying the function resource mapping library. Subsequently, the server performs an intersection operation between this resource list and the list of changed files in this update, filtering out files that are both function dependencies and fall within the scope of this change, and identifying these files as the change files that trigger the exception.

[0163] For example, after the server determines that the diagnostic session management function is an abnormal function, it queries the first mapping relationship to obtain a list of resource files that the function depends on, including session_manager.so and comm_config.xml. The server takes the intersection of this list and the list of changed files, and finds that the comm_config.xml file was modified in this update, thus determining that this file is the changed file that triggered the abnormality.

[0164] In S44, the server integrates anomaly analysis results to generate structured alarm information. This alarm information includes a unique identifier, the time of anomaly occurrence, software version information, the name of the anomalous function, and relevant change file information. The server organizes this information according to a predefined alarm template to ensure the completeness and standardization of the alarm content. After generating the alarm information, the server sends it to designated operations personnel or operations teams through the integrated notification system.

[0165] For example, the server generates an alarm message containing the alarm ID ALT20231127001, a timestamp of November 27, 2023 at 10:30 AM, software version number 2.1.0, the abnormal function name "Diagnostic Session Management," and the abnormal change file comm_config.xml. The server then sends this alarm message to the operations and maintenance personnel via the enterprise notification system.

[0166] This embodiment's anomaly tracing mechanism enables precise location of issues, from abnormal business metrics to specific change files. This progressive analysis method can quickly and accurately identify the root cause of software anomalies, greatly shortening troubleshooting time and improving operational efficiency. Simultaneously, the structured alarm information provides clear direction for subsequent problem fixing and version optimization, significantly enhancing the quality assurance capabilities of automotive diagnostic software.

[0167] Please see Figure 3 As shown, in one embodiment, an apparatus for monitoring vehicle diagnostic software is provided, the apparatus comprising:

[0168] Comparison module 301 is used to obtain a new version installation package of automotive diagnostic software and compare the file differences between the new version installation package and the old version installation package to generate a change file list including at least one changed file.

[0169] The mapping module 302 is used to query the monitoring probe configuration information associated with each change file according to the mapping relationship, so as to generate a monitoring probe configuration file;

[0170] The generation module 303 is used to generate a differential update package based on the data differences between the new version installation package and the old version installation package, add the monitoring probe configuration file to the differential update package, and send the differential update package including the monitoring probe configuration file to multiple specified terminal devices.

[0171] The alarm module 304 is used to receive business indicator data collected by each terminal device based on the monitoring probe configuration file. If the vehicle diagnostic software in the terminal device is found to be running abnormally based on the business indicator data, an alarm message is generated for that terminal device.

[0172] In one possible embodiment, comparing the file differences between the new version installation package and the old version installation package to generate a list of changed files including at least one changed file includes:

[0173] The files of the new version installation package are traversed to generate a first file set, and the files of the old version installation package are traversed to generate a second file set;

[0174] By comparing the file differences between the first file set and the second file set, at least one modified file is obtained; the modified file is a file whose content has been modified, a newly added file, or a deleted file.

[0175] Generate a list of changed files based on the change type, file path, and specific changes made to each changed file.

[0176] In one possible embodiment, the mapping relationship includes a first mapping relationship and a second mapping relationship;

[0177] The step of querying the monitoring probe configuration information associated with each changed file based on the mapping relationship to generate a monitoring probe configuration file includes:

[0178] Based on the first mapping relationship, each change file is mapped to the affected vehicle diagnostic function to generate a list of affected functions including at least one vehicle diagnostic function.

[0179] The second mapping relationship is queried to determine the monitoring probe configuration information associated with each vehicle diagnostic function, so as to generate a monitoring probe configuration file.

[0180] In one possible embodiment, mapping each change file to the affected vehicle diagnostic function according to the first mapping relationship includes:

[0181] If the changed file is a file whose content has been modified or a file that has been deleted, extract the file path of the changed file;

[0182] Search the first mapping relationship for a function entry that contains the file path;

[0183] Mark the vehicle diagnostic functions corresponding to the matched function entries as the affected vehicle diagnostic functions; and / or

[0184] If the modified file is a newly added file, obtain the function names of each function contained in the modified file;

[0185] Matching is performed in the first mapping relationship based on the semantic information of the function name;

[0186] The vehicle diagnostic functions corresponding to the matched function entries are marked as affected vehicle diagnostic functions.

[0187] In one possible embodiment, querying the second mapping relationship to determine the monitoring probe configuration information associated with each vehicle diagnostic function includes:

[0188] Matching is performed in the second mapping relationship based on the function type, function name, or protocol type of the vehicle diagnostic function;

[0189] If a matching monitoring probe template is found;

[0190] The monitoring probe template is assigned values ​​to obtain the monitoring probe configuration information, which includes: probe ID, probe name, monitoring indicators, and alarm rules.

[0191] In one possible embodiment, adding the monitoring probe configuration file to the differential update package includes:

[0192] The monitoring probe configuration file is serialized to obtain a byte array;

[0193] Generate a metadata block based on the byte array, the configuration identifier, the length of the byte array, and the version number of the new version installation package;

[0194] The metadata block is embedded into the header or footer of the differential update package.

[0195] In one possible embodiment, determining whether the vehicle diagnostic software is malfunctioning based on the business indicator data includes:

[0196] The business indicator data is compared with a preset static threshold, and the comparison result is used to determine whether the vehicle diagnostic software in the terminal device is malfunctioning; or

[0197] The business indicator data is compared with dynamic thresholds established based on historical data, and the comparison results are used to determine whether the vehicle diagnostic software in the terminal device is malfunctioning; or

[0198] The business indicator data from various terminal devices are clustered, and the clustering results are used to determine whether the vehicle diagnostic software in the terminal device is malfunctioning.

[0199] In one possible embodiment, generating alarm information for the terminal device and performing alarm operations includes:

[0200] Determine one or more monitoring metrics corresponding to the business metric data;

[0201] Based on each monitoring indicator, query the corresponding target vehicle diagnostic function in the second mapping relationship, and use the target vehicle diagnostic function as the vehicle diagnostic function that triggers the anomaly.

[0202] Based on the target vehicle diagnostic function, the corresponding target change file is queried in the first mapping relationship, and the change file that triggers the abnormality is obtained by performing an intersection operation between the target change file and the change file list;

[0203] The system generates alarm information based on the vehicle diagnostic function that triggered the anomaly and the modified file, and pushes the alarm information to the pre-bound maintenance personnel. The alarm information includes an alarm ID, a timestamp, the version number of the vehicle diagnostic software, the function name of the vehicle diagnostic function that triggered the anomaly, and the file name of the modified file that triggered the anomaly.

[0204] In one embodiment, a server is provided, the internal structure of which can be shown as follows: Figure 4 As shown. The computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a method for monitoring automotive diagnostic software on the server side.

[0205] In one embodiment, a server is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, performs the following steps:

[0206] Obtain the latest version installation package for the car diagnostic software;

[0207] Compare the file differences between the new version installation package and the old version installation package to generate a list of changed files, including at least one changed file;

[0208] Based on the first mapping relationship, each change file is mapped to the affected vehicle diagnostic function to generate a list of affected functions including at least one vehicle diagnostic function.

[0209] The second mapping relationship is queried to determine the monitoring probe configuration information associated with each vehicle diagnostic function, so as to generate a monitoring probe configuration file; the monitoring probe configuration file includes at least one monitoring probe configuration information, and the monitoring probe configuration information includes at least one monitoring indicator;

[0210] A differential update package is generated based on the data differences between the new version installation package and the old version installation package, and the monitoring probe configuration file is added to the differential update package. The differential update package including the monitoring probe configuration file is then sent to multiple specified terminal devices.

[0211] Receive business indicator data collected by each terminal device based on the monitoring probe configuration file;

[0212] Based on the aforementioned business indicator data, determine whether the vehicle diagnostic software in each terminal device is malfunctioning;

[0213] If so, generate alarm information for the terminal device and execute alarm operations.

[0214] This application achieves deep integration of automotive diagnostic software updates and monitoring, enabling proactive detection of diagnostic function defects, significantly improving the efficiency of problem identification and localization, and effectively solving the problem of lag in traditional methods that rely on manual reporting and post-event log analysis.

[0215] In one embodiment, a computer-readable storage medium is provided that stores a computer program, which, when executed by a processor, performs the following steps:

[0216] Obtain the latest version installation package for the car diagnostic software;

[0217] Compare the file differences between the new version installation package and the old version installation package to generate a list of changed files, including at least one changed file;

[0218] Based on the first mapping relationship, each change file is mapped to the affected vehicle diagnostic function to generate a list of affected functions including at least one vehicle diagnostic function.

[0219] The second mapping relationship is queried to determine the monitoring probe configuration information associated with each vehicle diagnostic function, so as to generate a monitoring probe configuration file; the monitoring probe configuration file includes at least one monitoring probe configuration information, and the monitoring probe configuration information includes at least one monitoring indicator;

[0220] A differential update package is generated based on the data differences between the new version installation package and the old version installation package, and the monitoring probe configuration file is added to the differential update package. The differential update package including the monitoring probe configuration file is then sent to multiple specified terminal devices.

[0221] Receive business indicator data collected by each terminal device based on the monitoring probe configuration file;

[0222] Based on the aforementioned business indicator data, determine whether the vehicle diagnostic software in each terminal device is malfunctioning;

[0223] If so, generate alarm information for the terminal device and execute alarm operations.

[0224] This application achieves deep integration of automotive diagnostic software updates and monitoring, enabling proactive detection of diagnostic function defects, significantly improving the efficiency of problem identification and localization, and effectively solving the problem of lag in traditional methods that rely on manual reporting and post-event log analysis.

[0225] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0226] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0227] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0228] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for monitoring automotive diagnostic software, characterized in that, The method includes: Obtain the new version installation package of the vehicle diagnostic software, and compare the file differences between the new version installation package and the old version installation package to generate a change file list including at least one changed file; Based on the first mapping relationship, each change file is mapped to the affected vehicle diagnostic function to generate a list of affected functions including at least one vehicle diagnostic function; the second mapping relationship is queried to determine the monitoring probe configuration information associated with each vehicle diagnostic function to generate a monitoring probe configuration file. A differential update package is generated based on the data differences between the new version installation package and the old version installation package, and the monitoring probe configuration file is added to the differential update package. The differential update package including the monitoring probe configuration file is then sent to multiple specified terminal devices. Receive business indicator data collected by each terminal device based on the monitoring probe configuration file. If the vehicle diagnostic software in the terminal device is found to be malfunctioning based on the business indicator data, generate alarm information for that terminal device.

2. The method for monitoring vehicle diagnostic software according to claim 1, characterized in that, The step of comparing the file differences between the new version installation package and the old version installation package to generate a list of changed files, including at least one changed file, includes: The files of the new version installation package are traversed to generate a first file set, and the files of the old version installation package are traversed to generate a second file set; By comparing the file differences between the first file set and the second file set, at least one modified file is obtained; the modified file is a file whose content has been modified or a newly added file. Generate a list of changed files based on the change type, file path, and specific changes made to each changed file.

3. The method for monitoring vehicle diagnostic software according to claim 1, characterized in that, The step of mapping each change file to the affected vehicle diagnostic function according to the first mapping relationship includes: If the changed file is a file whose content has been modified, extract the file path of the changed file; Search the first mapping relationship for a function entry that contains the file path; Mark the vehicle diagnostic functions corresponding to the matched function entries as the affected vehicle diagnostic functions; and / or If the modified file is a newly added file, obtain the function names of each function contained in the modified file; Matching is performed in the first mapping relationship based on the semantic information of the function name; The vehicle diagnostic functions corresponding to the matched function entries are marked as affected vehicle diagnostic functions.

4. The method for monitoring vehicle diagnostic software according to claim 1, characterized in that, The querying of the second mapping relationship to determine the monitoring probe configuration information associated with each vehicle diagnostic function includes: Matching is performed in the second mapping relationship based on the function type, function name, or protocol type of the vehicle diagnostic function; If a matching monitoring probe template is found; The monitoring probe template is assigned values ​​to obtain the monitoring probe configuration information, which includes: probe ID, probe name, monitoring indicators, and alarm rules.

5. The method for monitoring vehicle diagnostic software according to claim 3 or 4, characterized in that, Adding the monitoring probe configuration file to the differential update package includes: The monitoring probe configuration file is serialized to obtain a byte array; Generate a metadata block based on the byte array, the configuration identifier, the length of the byte array, and the version number of the new version installation package; The metadata block is embedded into the header or footer of the differential update package.

6. The method for monitoring vehicle diagnostic software according to claim 5, characterized in that, The alarm information for the terminal device includes: Determine one or more monitoring metrics corresponding to the business metric data; Based on each monitoring indicator, query the corresponding target vehicle diagnostic function in the second mapping relationship, and use the target vehicle diagnostic function as the vehicle diagnostic function that triggers the anomaly. Based on the target vehicle diagnostic function, the corresponding target change file is queried in the first mapping relationship, and the change file that triggers the abnormality is obtained by performing an intersection operation between the target change file and the change file list; The system generates alarm information based on the vehicle diagnostic function that triggered the anomaly and the modified file, and pushes the alarm information to the pre-bound maintenance personnel. The alarm information includes: alarm ID, timestamp, version number of the vehicle diagnostic software, function name of the vehicle diagnostic function that triggered the anomaly, and file name of the modified file that triggered the anomaly.

7. A device for monitoring automotive diagnostic software, characterized in that, The device includes: The comparison module is used to obtain a new version installation package of the vehicle diagnostic software and compare the file differences between the new version installation package and the old version installation package to generate a change file list including at least one changed file. The mapping module is used to map each change file to the affected vehicle diagnostic function according to the first mapping relationship to generate a list of affected functions including at least one vehicle diagnostic function; and to query the second mapping relationship to determine the monitoring probe configuration information associated with each vehicle diagnostic function to generate a monitoring probe configuration file. The generation module is used to generate a differential update package based on the data differences between the new version installation package and the old version installation package, add the monitoring probe configuration file to the differential update package, and send the differential update package including the monitoring probe configuration file to multiple specified terminal devices. The alarm module is used to receive business indicator data collected by each terminal device based on the monitoring probe configuration file. If the vehicle diagnostic software in the terminal device is found to be malfunctioning based on the business indicator data, an alarm message is generated for that terminal device.

8. A server, characterized in that, The server includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the steps of the method for monitoring vehicle diagnostic software as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method for monitoring vehicle diagnostic software as described in any one of claims 1 to 6.

10. An automotive diagnostic system, comprising: Servers and terminal devices; The server is configured to: acquire a new version installation package of automotive diagnostic software; compare file differences between the new version installation package and the old version installation package to generate a list of changed files including at least one changed file; map each changed file to an affected automotive diagnostic function according to a first mapping relationship to generate a list of affected functions including at least one automotive diagnostic function; query a second mapping relationship to determine the monitoring probe configuration information associated with each automotive diagnostic function to generate a monitoring probe configuration file; generate a differential update package based on data differences between the new version installation package and the old version installation package, and add the monitoring probe configuration file to the differential update package; distribute the differential update package including the monitoring probe configuration file to multiple specified terminal devices; receive business indicator data collected by each terminal device based on the monitoring probe configuration file; and generate alarm information for the terminal device if the automotive diagnostic software in the terminal device is found to be running abnormally based on the business indicator data. The terminal device is configured to receive a differential update package from the server, including the monitoring probe configuration file; extract and remove the monitoring probe configuration file from the differential update package; merge the local old version installation package and the differential update package to obtain a new version installation package; perform an installation operation using the new version installation package and run the vehicle diagnostic software; collect business indicator data using the monitoring indicators indicated by the monitoring probe configuration file; and report the business indicator data to the server.

Images