Abnormality diagnosis method, device and equipment of controller, medium and vehicle

Abstract

The invention relates to the technical field of vehicle diagnosis, in particular to an abnormality diagnosis method and device for a controller, equipment, a medium and a vehicle, and the method comprises the steps: obtaining a controller diagnosis table of the controller in the vehicle; based on the controller diagnosis table, generating a project file and a test case of the controller, and collecting a diagnosis log for executing the project file and the test case; and abnormal parameters in the diagnosis log are extracted, and an abnormal diagnosis result that the controller meets a preset abnormal diagnosis condition is generated according to the abnormal parameters. Therefore, the problems that in the related technology, a fault scene is built in advance, feedback and fault information are compared manually, reverse table searching is needed, the response speed is low, and the use requirement of an actual scene cannot be met are solved.

Description

Technical Field

[0001] This application relates to the field of vehicle diagnostic technology, and in particular to a method, apparatus, device, medium, and vehicle for diagnosing abnormalities in a controller. Background Technology

[0002] In related technologies, a testing system including a real-time machine, controller, diagnostic tools, and fault diagnosis table can be used to construct fault scenarios based on the fault diagnosis table, obtain controller feedback information, retrieve corresponding fault information from the table, and compare it using diagnostic tools to obtain the test results of the real-time machine, which are then written into the fault diagnosis table. Alternatively, an analysis matrix set can be built based on the fault diagnosis data of the vehicle controller under different operating conditions, and fault feature data can be obtained. Then, a subspace can be built for preset fault items, and a knowledge base can be constructed to correspond the fault items with the effective fault feature data. After collecting the fault detection data to be analyzed, the fault can be quickly found from the knowledge base by looking up the table.

[0003] However, the relevant technologies rely on pre-built fault scenarios and manual comparison of feedback and fault information, and require reverse lookup of tables, resulting in slow response speeds that cannot meet the needs of actual scenarios and urgently require improvement. Summary of the Invention

[0004] This application provides a method, apparatus, device, medium, and vehicle for abnormal diagnosis of controllers, in order to solve the problems in related technologies, such as relying on pre-built fault scenarios and manual comparison of feedback and fault information, requiring reverse lookup, slow response speed, and inability to meet the needs of actual use scenarios.

[0005] The first aspect of this application provides a method for diagnosing anomalies in a vehicle controller, comprising the following steps: obtaining a controller diagnostic table for the controller in the vehicle; generating an engineering file and test cases for the controller based on the controller diagnostic table, and collecting diagnostic logs of executing the engineering file and the test cases; extracting abnormal parameters from the diagnostic logs, and generating an anomaly diagnostic result in which the controller meets preset anomaly diagnostic conditions based on the abnormal parameters.

[0006] Optionally, in one embodiment of this application, generating the controller's engineering file and test cases based on the controller diagnostic table includes: parsing the controller diagnostic table to obtain the controller's current configuration parameter information and current engineering parameter information in the current state, as well as the controller's historical configuration parameter information and historical engineering parameter information in historical states; and constructing the engineering file and test cases based on the current configuration parameter information, the current engineering parameter information, the historical configuration parameter information, and the historical engineering parameter information.

[0007] Optionally, in one embodiment of this application, after generating an anomaly diagnosis result in which the controller meets preset anomaly diagnosis conditions, the method further includes: determining an anomaly trend of the controller based on the anomaly diagnosis result and the controller's historical anomaly diagnosis results in the historical state; determining the anomaly level of the controller based on the anomaly trend; and generating an alarm command in response to the anomaly level being greater than a preset level.

[0008] Optionally, in one embodiment of this application, the step of collecting diagnostic logs of the project file and the test cases includes: identifying the execution instructions of the project file and the test cases; filtering the execution instructions to obtain filtered execution instructions; and generating the diagnostic logs in response to the filtered execution instructions.

[0009] Optionally, in one embodiment of this application, generating an anomaly diagnosis result based on the anomaly parameters that the controller meets preset anomaly diagnosis conditions includes: detecting whether there is a corresponding anomaly push message in the diagnosis log based on the anomaly parameters; and generating the anomaly diagnosis result if the corresponding anomaly push message is detected in the diagnosis log.

[0010] A second aspect of this application provides an anomaly diagnosis device for a vehicle controller, comprising: an acquisition module for acquiring a controller diagnostic table of the controller in the vehicle; a collection module for generating engineering files and test cases for the controller based on the controller diagnostic table, and collecting diagnostic logs of executing the engineering files and the test cases; and a first generation module for extracting abnormal parameters from the diagnostic logs and generating an anomaly diagnosis result of the controller satisfying preset anomaly diagnosis conditions based on the abnormal parameters.

[0011] Optionally, in one embodiment of this application, the acquisition module includes: a parsing unit, configured to parse the controller diagnostic table to obtain the current configuration parameter information and current engineering parameter information of the controller in the current state, and the historical configuration parameter information and historical engineering parameter information of the controller in the historical state; and a construction unit, configured to construct the engineering file and the test cases based on the current configuration parameter information, the current engineering parameter information, the historical configuration parameter information and the historical engineering parameter information.

[0012] Optionally, in one embodiment of this application, it further includes: a first determining module, configured to determine the abnormal trend of the controller based on the abnormal diagnosis result and the historical abnormal diagnosis result of the controller in the historical state after generating an abnormal diagnosis result in which the controller meets the preset abnormal diagnosis conditions; a second determining module, configured to determine the abnormal level of the controller based on the abnormal trend; and a second generating module, configured to generate an alarm command in response to the abnormal level being greater than a preset level.

[0013] Optionally, in one embodiment of this application, the acquisition module includes: an identification unit for identifying the execution instructions of the project file and the test cases; a filtering unit for filtering the execution instructions to obtain filtered execution instructions; and a first generation unit for generating the diagnostic log in response to the filtered execution instructions.

[0014] Optionally, in one embodiment of this application, the first generation module includes: a detection unit, configured to detect whether a corresponding abnormal push message exists in the diagnostic log based on the abnormal parameters; and a second generation unit, configured to generate the abnormal diagnostic result when the corresponding abnormal push message is detected in the diagnostic log.

[0015] A third aspect of this application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the abnormal diagnosis method for a vehicle controller as described in the above embodiments.

[0016] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for diagnosing anomalies in a vehicle controller.

[0017] A fifth aspect of this application provides a vehicle that includes the electronic equipment described above.

[0018] A sixth aspect of this application provides a computer program product, including a computer program that, when executed, implements the above-described method for diagnosing anomalies in a vehicle controller.

[0019] This application's embodiments can generate corresponding engineering files and test cases based on the controller diagnostic table of the vehicle's controller, collect diagnostic logs, extract abnormal parameters, and thus generate abnormal diagnostic results that meet certain abnormal diagnostic conditions. By directly generating engineering files and test cases based on the controller diagnostic table and collecting diagnostic logs to obtain abnormal diagnostic results, it can obtain controller abnormal diagnostic results more directly and efficiently, achieving optimal reception of vehicle fault information and rapid response to improve vehicle quality. This solves the technical problems of related technologies that rely on pre-constructed fault scenarios and manual comparison of feedback and fault information, require reverse table lookup, have slow response speeds, and cannot meet the needs of real-world scenarios.

[0020] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0021] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart of a method for diagnosing anomalies in a vehicle controller according to an embodiment of this application; Figure 2 This is a flowchart illustrating the working principle of a vehicle controller anomaly diagnosis method according to an embodiment of this application; Figure 3 This is a block diagram of an anomaly diagnostic device for a vehicle controller provided according to an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of this application.

[0022] Figure label: Among them, 10-abnormal diagnosis device for vehicle controller; 100-acquisition module, 200-acquisition module, 300-first generation module; 401-memory, 402-processor, 403-communication interface. Detailed Implementation

[0023] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0024] The following description, with reference to the accompanying drawings, illustrates an anomaly diagnosis method, apparatus, device, medium, and vehicle for a controller according to embodiments of this application. Addressing the issues mentioned in the background art, such as reliance on pre-constructed fault scenarios and manual comparison of feedback and fault information, requiring reverse lookup of tables, resulting in slow response speeds and inability to meet the needs of real-world scenarios, this application provides an anomaly diagnosis method for a vehicle controller. In this method, based on the controller diagnostic table of the vehicle controller, corresponding engineering files and test cases can be generated, diagnostic logs can be collected, and abnormal parameters can be extracted to generate anomaly diagnosis results that meet certain anomaly diagnosis conditions. Directly generating engineering files and test cases based on the controller diagnostic table and collecting diagnostic logs to obtain anomaly diagnosis results allows for more direct and efficient acquisition of controller anomaly diagnosis results, enabling the reception of vehicle fault information within the optimal timeframe and rapid response to improve vehicle quality. This solves the technical problems in related technologies, such as reliance on pre-constructed fault scenarios and manual comparison of feedback and fault information, requiring reverse lookup of tables, resulting in slow response speeds and inability to meet the needs of real-world scenarios.

[0025] Specifically, Figure 1 This is a flowchart of an anomaly diagnosis method for a vehicle controller provided according to an embodiment of this application.

[0026] like Figure 1 As shown, the anomaly diagnosis method for the vehicle controller includes the following steps: In step S101, the controller diagnostic table of the controller in the vehicle is obtained.

[0027] It is understood that, in the embodiments of this application, the controller can be a vehicle controller, engine controller, transmission controller, brake controller, body controller, or a combination thereof. The specific configuration can be made by those skilled in the art according to the actual situation, and this application does not impose any specific limitations.

[0028] In actual implementation, the embodiments of this application can obtain the controller diagnostic tables of each controller in the vehicle.

[0029] For example, embodiments of this application can utilize a vehicle self-diagnostic system to obtain the controller diagnostic tables of the vehicle controller and brake controller in the vehicle, or obtain the controller diagnostic table of the vehicle controller in the vehicle through a mobile application. This application does not impose any specific limitations.

[0030] In step S102, based on the controller diagnostic table, the controller's project files and test cases are generated, and diagnostic logs of executing the project files and test cases are collected.

[0031] It is understood that, in the embodiments of this application, the engineering files are a collection of files used in the development, configuration and integration of the vehicle controller, which may include, but are not limited to, communication configuration files, controller configuration files and project information files, etc., and this application does not impose specific limitations.

[0032] Among them, the communication configuration file is used to define communication protocols and parameters, describe network topology, etc.; the controller configuration file is used to set controller operating parameters, define control strategies and algorithm parameters, etc.; the project information file is used to record basic project information, store hardware and software lists, etc., and this application does not impose specific restrictions.

[0033] Test cases are a collection of test steps and expected results designed to verify whether the controller's functions and performance meet the design requirements. They may include, but are not limited to, functional test cases, such as normal function tests, boundary condition tests, and abnormal function tests; and performance test cases, such as response time tests, load tests, and reliability tests. This application does not impose specific limitations on them.

[0034] Among them, normal function testing is used to design test cases for various normal functions of the controller to verify the correctness of the controller's functions under normal operating conditions; boundary condition testing can be understood as considering the boundary values ​​of the controller's input parameters and designing test cases to verify the controller's operation under boundary conditions; abnormal function testing can be understood as simulating various abnormal situations, such as sensor failure, communication interruption, power failure, etc., and designing test cases to verify the controller's fault diagnosis and handling capabilities; response time testing is used to measure the controller's response time to input signals to verify whether it meets the design requirements; load testing can be understood as testing the controller under a certain load to verify its performance stability; reliability testing is used to verify the controller's reliability and durability through long-term operation testing or simulated harsh environment testing.

[0035] In some embodiments, the present application can generate the controller's engineering files and test cases through the controller diagnostic table, execute the engineering files and test cases, and then collect the corresponding diagnostic logs.

[0036] Optionally, in one embodiment of this application, generating the controller's engineering files and test cases based on the controller diagnostic table includes: parsing the controller diagnostic table to obtain the current configuration parameter information and current engineering parameter information of the controller in the current state, as well as the historical configuration parameter information and historical engineering parameter information of the controller in the historical state; and constructing the engineering files and test cases based on the current configuration parameter information, current engineering parameter information, historical configuration parameter information, and historical engineering parameter information.

[0037] It is understood that, in the embodiments of this application, the current configuration parameter information can be understood as the set of configuration parameters that are effective in the current operating state of the controller, such as the ambient temperature and intake pressure of the engine controller, and the shift line parameters of the transmission controller, etc., and this application does not impose specific limitations; while the historical configuration parameter information can be understood as the record of configuration parameters that were effective in the past operating state of the controller.

[0038] Current engineering parameter information can be understood as the current version and calibration data identifier of the controller's hardware and software, such as the controller's hardware number and software version number, etc., and this application does not impose specific restrictions; while historical engineering parameter information can be understood as the controller's past hardware and software version records, such as the software version number and hardware number before the upgrade, etc., and this application does not impose specific restrictions.

[0039] In some embodiments, the present application can parse the controller diagnostic table to extract the current configuration parameter information and current engineering parameter information of the controller in the current state, as well as the historical configuration parameter information and historical engineering parameter information of the controller in the historical state. Then, based on the current configuration parameter information, current engineering parameter information, historical configuration parameter information, and historical engineering parameter information, the engineering file and test cases can be constructed.

[0040] For example, in this application embodiment, the configuration parameter information and engineering parameter information required by CANOE, such as communication protocol, communication parameters, and engineering parameters, can be obtained by parsing the controller diagnostic table. Then, the corresponding engineering files and test cases can be generated. When the controller diagnostic is updated, the engineering files and test cases are regenerated, and the information before the update is saved as historical configuration parameter information and historical engineering parameter information for viewing and comparing the update history and troubleshooting problems, thereby generating the corresponding engineering files and test cases.

[0041] Optionally, in one embodiment of this application, collecting diagnostic logs of the executed project files and test cases includes: identifying the execution instructions of the project files and test cases; filtering the execution instructions to obtain filtered execution instructions; and generating diagnostic logs in response to the filtered execution instructions.

[0042] It is understood that the embodiments of this application may contain instructions with low relevance, low priority, poor feasibility, and repeated execution. Therefore, the embodiments of this application can filter the execution instructions based on relevance, priority, feasibility, and repeatability to obtain the filtered execution instructions.

[0043] Among them, relevance can be understood as the execution instructions that are directly related to the test cases, avoiding the waste of resources by executing irrelevant instructions; priority can be understood as assigning priority to execution instructions according to the importance and urgency of different test cases, ensuring that key test cases are executed first; feasibility can be understood as avoiding the execution of instructions that cannot be completed based on the feasibility of the execution instructions; repeatability can be understood as repeating the same execution instructions, optimizing the execution process, and reducing repetitive operations.

[0044] Furthermore, the embodiments of this application can be filtered manually or automatically, and the specific settings can be made by those skilled in the art according to the actual situation. This application does not impose any specific limitations.

[0045] In some embodiments, the present application embodiments may first identify the execution instructions of the project files and test cases, and then filter the execution instructions to obtain the filtered execution instructions, and then generate a diagnostic log in response to the filtered execution instructions.

[0046] In addition, the embodiments of this application can generate a unique index for each diagnostic log by item, part number, vehicle identification number, and date, which is used to retrieve and distinguish different items and different controllers. The logs are uploaded to the cloud server by automatic or manual upload, reducing local storage. The parsing method of the diagnostic logs is determined according to the upload method and the file format of the diagnostic logs. The specific settings can be made by those skilled in the art according to the actual situation, and this application does not impose any specific limitations.

[0047] In step S103, abnormal parameters are extracted from the diagnostic log, and abnormal diagnostic results are generated based on the abnormal parameters to indicate that the controller meets the preset abnormal diagnostic conditions.

[0048] Abnormal parameters may include, but are not limited to, NRC (Negative Response Code), abnormal messages, etc., and this application does not impose specific restrictions.

[0049] In some embodiments, the present application may first parse the diagnostic log and extract abnormal parameters from it, and then evaluate the extracted abnormal parameters based on preset abnormal diagnostic conditions to generate a diagnostic result that meets the preset abnormal diagnostic conditions. The preset abnormal diagnostic conditions can be set by those skilled in the art according to actual conditions, and the present application does not impose specific limitations.

[0050] For example, in this application embodiment, a scanning task is performed on manually uploaded diagnostic logs, and when the diagnostic logs contain configured NRC, abnormal messages and other abnormal parameters, an abnormal diagnostic result that meets the preset abnormal diagnostic conditions is obtained, and the abnormal diagnostic result is automatically sent to the email or work application of the corresponding responsible person. For example, different controller diagnostic tables can be configured with corresponding responsible persons to generate different problem tracking processes. This application does not impose specific limitations.

[0051] In some embodiments, the present application can trigger timed automatic diagnostic logs, such as scanning the diagnostic logs obtained on the same day (excluding diagnostic logs that have been manually executed) at a timed interval every morning according to the keywords configured in the project controller of the low-code platform. The present application does not impose specific limitations.

[0052] Furthermore, in this embodiment of the application, when the diagnostic log contains configured abnormal parameters such as NRC and abnormal messages, an abnormal diagnostic result that meets the preset abnormal diagnostic conditions can be determined, and the abnormal diagnostic result can be automatically sent to the email address or work application of the corresponding responsible person in order to quickly respond to the problem and handle it.

[0053] Optionally, in one embodiment of this application, generating an abnormal diagnosis result based on abnormal parameters that the controller meets preset abnormal diagnosis conditions includes: detecting whether there is a corresponding abnormal push message in the diagnostic log based on the abnormal parameters; and generating an abnormal diagnosis result if a corresponding abnormal push message is detected in the diagnostic log.

[0054] In some embodiments, this application can detect whether there is a corresponding abnormal push message in the diagnostic log based on abnormal parameters, and generate a corresponding abnormal diagnostic result if it exists.

[0055] For example, in the embodiments of this application, the corresponding bus message can be parsed using different components according to the file format of the diagnostic log, thereby detecting whether there is a corresponding abnormal push message in the diagnostic log, and if so, storing the abnormal push message in the task record log file. The task record log file includes the index, line number and content of the abnormal push message, etc., and this application does not impose specific limitations.

[0056] It should be noted that, in order to avoid duplication of work, improve task efficiency, and shorten troubleshooting time, this application embodiment may not push known and resolved anomalies.

[0057] Optionally, in one embodiment of this application, after generating an anomaly diagnosis result in which the controller meets the preset anomaly diagnosis conditions, the method further includes: determining the anomaly trend of the controller based on the anomaly diagnosis result and the historical anomaly diagnosis result of the controller in a historical state; determining the anomaly level of the controller based on the anomaly trend; and generating an alarm command in response to the anomaly level being greater than the preset level.

[0058] It is understood that, in the embodiments of this application, abnormal trends may include, but are not limited to, trend types such as stable, fluctuating, deteriorating, mitigating, etc.; trend directions such as rising, falling, irregular, etc.; and key indicators such as abnormality occurrence rate, average severity, and scope of impact, etc., which are not specifically limited in this application.

[0059] The abnormality level may include, but is not limited to, low level, medium level, high level and emergency level, etc., and this application does not impose specific restrictions.

[0060] Among them, low level can be understood as a single anomaly with no trend of deterioration and a small impact range; medium level can be understood as repeated anomalies or slight trend of deterioration; high level can be understood as a rapid trend of deterioration or anomalies in key parameters; emergency level can be understood as a direct threat to safety or function, etc., and this application does not impose specific restrictions.

[0061] In some embodiments, the present application can determine the abnormal trend of the controller by comparing the abnormal diagnosis results with historical abnormal diagnosis results, thereby obtaining the abnormal level of the controller, and generating an alarm command, such as email, SMS, audible and visual alarm, in response to the abnormal level being greater than a preset level. The present application does not impose any specific limitations.

[0062] In addition, the preset level can be set by those skilled in the art according to the actual situation, and this application does not impose specific restrictions.

[0063] The working principle of the vehicle controller anomaly diagnosis method proposed in this application will be introduced below with reference to a specific embodiment.

[0064] in, Figure 2 This is a flowchart illustrating the working principle of a vehicle controller anomaly diagnosis method according to an embodiment of this application.

[0065] Step S201: Build the controller's project files and test cases.

[0066] In this embodiment, the corresponding engineering files and test cases can be constructed based on the current configuration parameter information and current engineering parameter information of the controller in the current state, and the historical configuration parameter information and historical engineering parameter information of the controller in the historical state.

[0067] Step S202: Collect diagnostic logs and upload them to the cloud server.

[0068] In this embodiment, the data can be uploaded to the cloud server automatically or manually, and the parsing method of the diagnostic log is determined according to the upload method and the file format of the diagnostic log.

[0069] Step S203: Generate an anomaly diagnosis result that meets the preset anomaly diagnosis conditions based on the anomaly parameters.

[0070] In this embodiment of the application, when the diagnostic log contains configured abnormal parameters such as NRC and abnormal messages, and there is a corresponding abnormal push message, a corresponding abnormal diagnostic result is generated.

[0071] Step S204: Push out abnormal diagnosis results.

[0072] In this embodiment of the application, abnormal diagnostic results can be sent to the email address or work application of the corresponding responsible person.

[0073] The vehicle controller anomaly diagnosis method proposed in this application can generate corresponding engineering files and test cases based on the controller diagnostic table of the vehicle controller, collect diagnostic logs, extract abnormal parameters, and thus generate anomaly diagnosis results that meet certain anomaly diagnosis conditions. Directly generating engineering files and test cases based on the controller diagnostic table and collecting diagnostic logs to obtain anomaly diagnosis results allows for more direct and efficient acquisition of controller anomaly diagnosis results, enabling the receipt of vehicle fault information within the optimal time and rapid response to improve vehicle quality. This solves the technical problems in related technologies, such as reliance on pre-constructed fault scenarios and manual comparison of feedback and fault information, the need for reverse table lookup, slow response speed, and inability to meet the needs of practical applications.

[0074] Next, with reference to the accompanying drawings, an anomaly diagnosis device for a vehicle controller according to an embodiment of this application is described.

[0075] Figure 3 This is a block diagram of an anomaly diagnosis device for a vehicle controller provided according to an embodiment of this application.

[0076] like Figure 3 As shown, the abnormal diagnosis device 10 of the vehicle controller includes: an acquisition module 100, a collection module 200, and a first generation module 300.

[0077] The acquisition module 100 is used to acquire the controller diagnostic table of the controller in the vehicle.

[0078] The data acquisition module 200 is used to generate the controller's project files and test cases based on the controller diagnostic table, and to collect diagnostic logs from the execution of the project files and test cases.

[0079] The first generation module 300 is used to extract abnormal parameters from the diagnostic log and generate abnormal diagnostic results for the controller that meet the preset abnormal diagnostic conditions based on the abnormal parameters.

[0080] Optionally, in one embodiment of this application, the acquisition module 200 includes a parsing unit and a construction unit.

[0081] The parsing unit is used to parse the controller diagnostic table to obtain the current configuration parameter information and current engineering parameter information of the controller in the current state, as well as the historical configuration parameter information and historical engineering parameter information of the controller in the historical state.

[0082] The building unit is used to build project files and test cases based on current configuration parameter information, current project parameter information, historical configuration parameter information, and historical project parameter information.

[0083] Optionally, in one embodiment of this application, it further includes: a first determining module, a second determining module, and a second generating module.

[0084] The first determining module is used to determine the abnormal trend of the controller based on the abnormal diagnosis results and the historical abnormal diagnosis results of the controller in historical states after generating abnormal diagnosis results that the controller meets the preset abnormal diagnosis conditions.

[0085] The second determination module is used to determine the anomaly level of the controller based on the anomaly trend.

[0086] The second generation module is used to generate alarm commands in response to an anomaly level exceeding a preset level.

[0087] Optionally, in one embodiment of this application, the acquisition module 200 includes: an identification unit and a filtering unit.

[0088] The identification unit is used to identify the execution instructions of project files and test cases.

[0089] The filtering unit is used to filter the execution instructions to obtain the filtered execution instructions.

[0090] The first generation unit is used to generate diagnostic logs in response to the filtered execution instructions.

[0091] Optionally, in one embodiment of this application, the first generation module 300 includes: a detection unit and a second generation unit.

[0092] The detection unit is used to detect whether there is a corresponding abnormal push message in the diagnostic log based on abnormal parameters.

[0093] The second generation unit is used to generate abnormal diagnostic results when a corresponding abnormal push message is detected in the diagnostic log.

[0094] It should be noted that the explanation of the above-described embodiment of the abnormal diagnosis method for the vehicle controller also applies to the abnormal diagnosis device for the vehicle controller in this embodiment, and will not be repeated here.

[0095] The vehicle controller anomaly diagnosis device proposed in this application can generate corresponding engineering files and test cases based on the controller diagnosis table of the vehicle controller, collect diagnostic logs, extract abnormal parameters, and thus generate anomaly diagnosis results that meet certain anomaly diagnosis conditions. By directly generating engineering files and test cases based on the controller diagnosis table and collecting diagnostic logs to obtain anomaly diagnosis results, it can obtain controller anomaly diagnosis results more directly and efficiently, achieving optimal reception of vehicle fault information and rapid response to improve vehicle quality. This solves the technical problems in related technologies, such as reliance on pre-constructed fault scenarios and manual comparison of feedback and fault information, the need for reverse table lookup, slow response speed, and inability to meet the needs of practical applications.

[0096] Figure 4 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of this application. The electronic device may include: The memory 401, the processor 402, and the computer program stored on the memory 401 and capable of running on the processor 402.

[0097] When the processor 402 executes the program, it implements the abnormal diagnosis method for the vehicle controller provided in the above embodiments.

[0098] Furthermore, electronic devices also include: Communication interface 403 is used for communication between memory 401 and processor 402.

[0099] The memory 401 is used to store computer programs that can run on the processor 402.

[0100] Memory 401 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0101] If the memory 401, processor 402, and communication interface 403 are implemented independently, then the communication interface 403, memory 401, and processor 402 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized into address buses, data buses, control buses, etc. For ease of representation, Figure 4 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0102] Optionally, in a specific implementation, if the memory 401, processor 402, and communication interface 403 are integrated on a single chip, then the memory 401, processor 402, and communication interface 403 can communicate with each other through an internal interface.

[0103] Processor 402 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0104] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described method for diagnosing abnormalities in a vehicle controller.

[0105] This application also provides a vehicle that includes the electronic devices described above.

[0106] This application also provides a computer program product, including a computer program that, when executed, implements the above-described method for diagnosing abnormalities in a vehicle controller.

[0107] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0108] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0109] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0110] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). In addition, computer-readable media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically by optically scanning paper or other media, then editing, interpreting or otherwise processing them as necessary, and then storing them in computer memory.

[0111] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. If implemented in hardware, as in another embodiment, it can be implemented using any one or more of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0112] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0113] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0114] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. A method for diagnosing anomalies in a vehicle controller, characterized in that, Includes the following steps: Obtain the controller diagnostic table for the controller in the vehicle; Based on the controller diagnostic table, the controller's project files and test cases are generated, and diagnostic logs of executing the project files and test cases are collected; Extract abnormal parameters from the diagnostic log, and generate an abnormal diagnosis result for the controller that meets preset abnormal diagnosis conditions based on the abnormal parameters.

2. The method according to claim 1, characterized in that, The process of generating the controller's project files and test cases based on the controller diagnostic table includes: Parse the controller diagnostic table to obtain the current configuration parameter information and current engineering parameter information of the controller in the current state, as well as the historical configuration parameter information and historical engineering parameter information of the controller in the historical state; Based on the current configuration parameter information, the current project parameter information, the historical configuration parameter information, and the historical project parameter information, the project file and the test cases are constructed.

3. The method according to claim 2, characterized in that, After generating the anomaly diagnosis result that the controller meets the preset anomaly diagnosis conditions, the method further includes: Based on the anomaly diagnosis results and the historical anomaly diagnosis results of the controller in the historical state, the anomaly trend of the controller is determined; Based on the abnormal trend, the abnormality level of the controller is determined; An alarm command is generated in response to the anomaly level being greater than a preset level.

4. The method according to claim 1, characterized in that, The diagnostic logs collected from the execution of the project files and the test cases include: Identify the execution instructions of the project file and the test case; The execution instructions are filtered to obtain the filtered execution instructions; In response to the filtered execution instructions, the diagnostic log is generated.

5. The method according to claim 1, characterized in that, The step of generating an anomaly diagnosis result based on the anomaly parameters, indicating that the controller meets preset anomaly diagnosis conditions, includes: Based on the abnormal parameters, detect whether there is a corresponding abnormal push message in the diagnostic log; If the corresponding abnormal push message is detected in the diagnostic log, the abnormal diagnostic result is generated.

6. An anomaly diagnosis device for a vehicle controller, characterized in that, include: The acquisition module is used to acquire the controller diagnostic table of the controller in the vehicle; The acquisition module is used to generate the controller's project files and test cases based on the controller diagnostic table, and to collect diagnostic logs of executing the project files and test cases; The generation module is used to extract abnormal parameters from the diagnostic log and generate an abnormal diagnosis result of the controller that meets the preset abnormal diagnosis conditions based on the abnormal parameters.

7. The apparatus according to claim 6, characterized in that, The acquisition module includes: The parsing unit is used to parse the controller diagnostic table to obtain the current configuration parameter information and current engineering parameter information of the controller in the current state, as well as the historical configuration parameter information and historical engineering parameter information of the controller in the historical state. The construction unit is used to construct the project file and the test cases based on the current configuration parameter information, the current project parameter information, the historical configuration parameter information, and the historical project parameter information.

8. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the abnormal diagnosis method for a vehicle controller as described in any one of claims 1-5.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement the anomaly diagnosis method for the vehicle controller as described in any one of claims 1-5.

10. A vehicle, characterized in that, The vehicle includes the electronic equipment as described in claim 8.

Images