Engine off-line fault monitoring method, device and computer readable storage medium

Abstract

The application provides an engine offline fault monitoring method, device and computer readable storage medium, the method comprising: a cloud server acquires ECU message information collected by a client, the ECU message information being detection information sent by an ECU of an engine during an engine offline test process; the cloud server analyzes the ECU message information to obtain fault information, the fault information including an engine number, a fault code and a fault description, the fault description being fault description information corresponding to the fault code; the cloud server establishes a prior engine fault code relationship network according to the fault information, the prior engine fault code relationship network being used to represent a mapping relationship among the engine number, the fault code and the fault description; and the cloud server outputs the fault code and the fault description corresponding to the engine number in a query request according to the prior engine fault code relationship network in response to the query request, thereby solving the problem of the influence of software update iteration on offline efficiency in the prior art.

Description

Technical Field

[0001] This invention relates to the field of engine testing technology, and more specifically, to a method, apparatus, computer-readable storage medium, and computer program product for monitoring engine off-line faults. Background Technology

[0002] During engine rollout testing, the current approach involves directly recording data into a database using the rollout software. However, due to the nature of database middleware, complex data intervention and management are not feasible. Directly storing fault data makes it difficult to build real-time monitoring, processing, and statistical services, such as targeted fault alarms, dynamic changes in fault levels, and multi-dimensional statistical information, thus affecting the timeliness of the data. Furthermore, the continuous updating of fault data necessitates adding processing logic to the rollout software, which raises costs associated with software iteration and maintenance, as well as configuration update requirements, reducing the efficiency of the rollout plan and impacting the versatility and stability of bench testing. Summary of the Invention

[0003] The main objective of this application is to provide a method, device, computer-readable storage medium, and computer program product for monitoring engine off-line faults, so as to at least solve the problem of engine off-line efficiency being affected by software updates and iterations in the prior art.

[0004] To achieve the above objectives, according to one aspect of this application, a method for monitoring engine off-line faults is provided, comprising: a cloud server acquiring ECU message information collected by a client, wherein the ECU message information is detection information sent by the ECU of the engine during engine off-line testing; the cloud server parsing the ECU message information to obtain fault information, wherein the fault information includes an engine number, a fault code, and a fault description, wherein the fault description is fault description information corresponding to the fault code; the cloud server establishing a priori engine fault code relationship network based on the fault information, wherein the priori engine fault code relationship network is used to represent the mapping relationship between the engine number, the fault code, and the fault description; and the cloud server responding to a query request by outputting the fault code and the fault description corresponding to the engine number in the query request based on the priori engine fault code relationship network.

[0005] Optionally, after the cloud server parses the ECU message information to obtain fault information, the method further includes: the cloud server cleaning abnormal data in the fault information, wherein the abnormal data abnormality types include parsing abnormalities and fault code format abnormalities; the cloud server querying a priori fault category knowledge base based on the fault code to obtain the fault level of the fault code, wherein the priori fault category knowledge base is used to represent the mapping relationship between the fault code and the fault level; and the cloud server triggering an alarm according to the alarm method corresponding to the fault level of the fault code.

[0006] Optionally, the cloud server queries a priori fault category knowledge base based on the fault code to obtain the fault level of the fault code, including: if the fault code does not exist in the priori fault category knowledge base, the cloud server obtains the fault level of the fault code as manually assessed; and updates the fault code and the corresponding fault level to the priori fault category knowledge base.

[0007] Optionally, the cloud server parses the ECU message information to obtain fault information, including: the cloud server parses the ECU message information to obtain fault data, the fault data including the fault information and other information not belonging to the fault information; filtering and formatting the fault information to obtain the fault information, the formatting process being used to unify the fault codes and fault descriptions of different faults.

[0008] Optionally, the method further includes: updating and iterating the cloud server to update the functionality of the data on the cloud server.

[0009] Optionally, the cloud server obtains ECU message information collected by the client, including: the cloud server obtaining client information, the client information being the client's ID; the cloud server registering the client based on the client information and establishing a long-term network connection between the client and the cloud server; and the cloud server obtaining the ECU message information through the long-term network connection.

[0010] Optionally, the method further includes: shutting down the long network connection pipeline at the end of the engine off-line test.

[0011] According to another aspect of this application, an engine off-line fault monitoring device is provided, applied to a cloud server, comprising: an acquisition unit, configured to acquire ECU message information collected by a client, wherein the ECU message information is detection information sent by the ECU of the engine during engine off-line testing; a parsing unit, configured to parse the ECU message information to obtain fault information, wherein the fault information includes an engine number, a fault code, and a fault description, wherein the fault description is fault description information corresponding to the fault code; an establishment unit, configured to establish a priori engine fault code relationship network based on the fault information, wherein the priori engine fault code relationship network is used to represent the mapping relationship between the engine number, the fault code, and the fault description; and a query unit, configured to, in response to a query request, output the fault code and the fault description corresponding to the engine number in the query request based on the priori engine fault code relationship network.

[0012] According to another aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored program, wherein, when the program is executed, it controls the device on which the computer-readable storage medium is located to perform any of the methods described.

[0013] According to another aspect of this application, a computer program product is provided, comprising a computer program that, when executed by a processor, implements any of the methods described.

[0014] Applying the technical solution of this application, in the above-mentioned engine off-line fault monitoring method, firstly, the cloud server obtains ECU message information collected by the client. The ECU message information is the detection information sent by the engine ECU during the engine off-line test. Then, the cloud server parses the ECU message information to obtain fault information, which includes the engine number, fault code, and fault description. The fault description is the fault description information corresponding to the fault code. Next, the cloud server establishes a priori engine fault code relationship network based on the fault information. This network represents the mapping relationship between the engine number, fault code, and fault description. Finally, in response to a query request, the cloud server outputs the fault code and fault description corresponding to the engine number in the query request based on the priori engine fault code relationship network. The message parsing function, the function of establishing the priori engine fault code relationship network, and the query function of the cloud server can all be implemented through functional modules. The functional modules are pluggable development entry points, meaning that the development of new functions will not affect the normal operation of already deployed functional modules, reducing the risks of software iteration development and solving the problem of engine off-line efficiency being affected by software updates in the prior art. Attached Figure Description

[0015] Figure 1A hardware structure block diagram of a mobile terminal for performing an engine off-line fault monitoring method is shown in an embodiment of this application.

[0016] Figure 2 A flowchart illustrating an engine off-line fault monitoring method according to an embodiment of this application is shown.

[0017] Figure 3 A structural block diagram of an engine off-line fault monitoring device provided according to an embodiment of this application is shown;

[0018] Figure 4 A modular architecture of a generator offline testing system provided according to an embodiment of this application is shown;

[0019] Figure 5 A flowchart illustrating the operation of a generator offline testing system according to an embodiment of this application is shown.

[0020] The above figures include the following reference numerals:

[0021] 102. Processor; 104. Memory; 106. Transmission device; 108. Input / output device. Detailed Implementation

[0022] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0023] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0024] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this application described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0025] As described in the background section, in the prior art, the software updates and iterations for engine off-line production affect off-line efficiency. To solve this technical problem, embodiments of this application provide an engine off-line fault monitoring method, apparatus, computer-readable storage medium, and computer program product.

[0026] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0027] The methods and embodiments provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Taking running on a mobile terminal as an example, Figure 1 This is a hardware structure block diagram of a mobile terminal for an engine off-line fault monitoring method according to an embodiment of the present invention. Figure 1 As shown, a mobile terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the mobile terminal described above. For example, the mobile terminal may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0028] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the device information display method in this embodiment of the invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thereby implementing the above-described method. The memory 104 may include high-speed random access memory and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of the aforementioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. The transmission device 106 is used to receive or send data via a network. Specific examples of the aforementioned networks may include wireless networks provided by the mobile terminal's communication provider. In one example, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to communicate with the Internet. In one example, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0029] This embodiment provides a method for monitoring engine off-line faults that runs on a mobile terminal, computer terminal, or similar computing device. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Also, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0030] Figure 2 This is a flowchart of an engine off-line fault monitoring method according to an embodiment of this application. Figure 2 As shown, the method includes the following steps:

[0031] Step S201: The cloud server obtains the ECU message information collected by the client. The ECU message information is the detection information sent by the engine ECU during the engine offline test.

[0032] In step S202, the cloud server parses the ECU message information to obtain fault information, which includes engine number, fault code and fault description. The fault description is the fault description information corresponding to the fault code.

[0033] Step S203: The cloud server establishes a priori engine fault code relationship network based on the fault information. The priori engine fault code relationship network is used to represent the mapping relationship between engine number, fault code and fault description.

[0034] In step S204, the cloud server responds to the query request by outputting the fault code and fault description corresponding to the engine number in the query request based on the prior engine fault code relationship network.

[0035] In the aforementioned engine off-line fault monitoring method, firstly, the cloud server acquires ECU message information collected by the client. This ECU message information consists of detection information sent by the engine's ECU during the engine off-line testing process. Then, the cloud server parses the ECU message information to obtain fault information, including the engine number, fault code, and fault description. The fault description corresponds to the fault code. Next, the cloud server establishes a priori engine fault code relationship network based on the fault information. This network represents the mapping relationship between the engine number, fault code, and fault description. Finally, in response to a query request, the cloud server outputs the fault code and fault description corresponding to the engine number in the query request, based on the priori engine fault code relationship network. The message parsing function, the establishment of the priori engine fault code relationship network, and the query function of the cloud server can all be implemented through functional modules. These modules provide a pluggable development entry point, ensuring that the development of new functions does not affect the normal operation of already deployed functional modules. This reduces the risks associated with software iteration and solves the problem of engine off-line efficiency being affected by software updates in existing technologies.

[0036] To provide timely early warning of faults, in one optional implementation, after parsing the ECU message information on a cloud server to obtain fault information, the method further includes:

[0037] Step S301: The cloud server cleans the abnormal data in the fault information. The abnormal data types include parsing abnormalities and fault code format abnormalities.

[0038] Step S302: The cloud server queries the prior fault category knowledge base based on the fault code to obtain the fault level of the fault code. The prior fault category knowledge base is used to represent the mapping relationship between fault codes and fault levels.

[0039] In step S303, the cloud server issues an alarm according to the alarm method corresponding to the fault level of the fault code.

[0040] In the above implementation, the cloud server includes a data governance module. This module is responsible for functions such as cleaning, transforming, issuing early warnings, and statistical analysis of fault information. After receiving fault data parsed by the gateway parsing module, the data governance module cleans and filters abnormal data, including parsing errors, fault code format errors, and other rule-defined forms. After obtaining the fault code, the module determines the fault code's level based on a priori fault level knowledge base and then pushes it to the cloud module to complete subsequent fault early warning alerts.

[0041] To achieve self-learning updates of the prior fault category knowledge base, in one optional implementation, step S302 includes:

[0042] Step S3021: If the fault code does not exist in the prior fault category knowledge base, the cloud server obtains the fault level of the manually assessed fault code.

[0043] Step S3022: Update the fault code and corresponding fault level to the prior fault category knowledge base.

[0044] In the above implementation, the prior fault level knowledge base is a self-learning fault level knowledge base. The initial state is manual maintenance. If a fault code parsed in subsequent use does not exist in the knowledge base, it will be automatically added to the knowledge base. The data governance module will push this information to the cloud module to complete the subsequent email notification to the relevant developers to complete the information maintenance of the new fault code and complete the information update.

[0045] To facilitate a unified representation of fault information, in one optional implementation, step S202 includes:

[0046] Step S2021: The cloud server parses the ECU message information to obtain fault data, which includes fault information and other information that is not fault information.

[0047] Step S2022: Filter and format the fault information to obtain fault information. The formatting process is used to unify the fault codes and fault descriptions of different faults.

[0048] In the above embodiments, the data governance module is also used to clean and filter fault data, shielding preset rule information such as vehicle faults. After cleaning and transforming the data, fault data types are filled in and data verification is performed based on a priori fault category knowledge base. Then, formatting is performed to construct a test feature profile of the off-line engine. Based on a priori engine fault code relationship network, a relationship representation between the off-line test engine and faults is constructed, forming a mapping relationship representation of engine number, fault code, and fault description. The engine features are then pushed to the cloud module for subsequent persistent storage of data features. Based on the priori engine fault code relationship network, fault statistics for each off-line test engine and multi-dimensional (batch, type, etc.) batch fault statistics are implemented. The statistical information is pushed to the cloud module for subsequent statistical push.

[0049] To avoid the impact of feature updates on offline testing efficiency, in one optional implementation, the above method further includes:

[0050] In step S401, the cloud server is updated and iterated to update the data functionality of the cloud server.

[0051] In the above implementation, the prior fault category knowledge base, the prior engine fault code relationship network, and the prior fault level knowledge base are all updated in a self-learning manner. Various cleaning, transformation, and formatting strategies in the data governance module are uniformly updated and released by the cloud module. The development of new functions will not affect the normal operation of the deployed functional modules.

[0052] To achieve engine off-line fault acquisition and monitoring, in one optional implementation, step S201 includes:

[0053] Step S2011: The cloud server obtains client information, which is the client's ID;

[0054] In step S2012, the cloud server registers the client based on the client information and establishes a long-term network connection between the client and the cloud server.

[0055] In step S2013, the cloud server obtains ECU message information through a long network connection.

[0056] In the above embodiments, the cloud server further includes a gateway resolution module, and the client includes a fault acquisition module. The fault acquisition module is responsible for collecting ECU message information during the engine off-line testing process. Before the test begins, the fault acquisition module registers its terminal information (client information) with the cloud module, establishing a long-lived network connection pipeline that matches the gateway resolution module, reducing network connection request consumption for data distribution during the test. Simultaneously, it obtains the fault acquisition configuration set in the cloud and pushes data to the gateway resolution module in segments according to the preset acquisition frequency. The gateway resolution module receives message data through a message queue. After receiving the fault message pushed by the acquisition module, the gateway resolution module converts the message information into fault data and then pushes it to the data governance module.

[0057] To conserve network resources, in an optional implementation, the method further includes:

[0058] Step S501: When the engine off-line test is completed, shut off the long network connection pipeline.

[0059] In the above implementation, after the test is completed, the fault acquisition module requests the cloud server to close the network connection pipeline and release network resources.

[0060] In addition, the aforementioned cloud server includes a cloud module, which is responsible for scheduling the test bench terminal (client) and cloud services. The cloud module is responsible for the registration and maintenance of the test bench terminal (client), receiving fault code level warning pushes from the data governance module, and receiving engine fault characteristics and fault statistics from the data governance module. Upon receiving a fault code level warning push, it pushes the fault level warning to the alarm device of the test bench terminal (client) based on the network channel registered between the test bench terminal (client) and the cloud. Upon receiving engine fault statistical characteristic pushes, it pushes this information to the acquisition terminal for real-time display on the client software, ensuring that the test bench obtains data statistical information; simultaneously, it stores the data along with the received engine fault characteristic push data to complete data persistence, ensuring subsequent query and retrieval needs. The cloud module can configure various strategies of the data governance module, meeting the requirements of online configurability and upgrade updates for various data governance strategies. Simultaneously, the cloud module can also dynamically adjust the frequency of fault data message collection.

[0061] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0062] This application also provides an engine off-line fault monitoring device. It should be noted that the engine off-line fault monitoring device of this application can be used to execute the engine off-line fault monitoring method provided in this application. This device is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0063] The following describes the engine off-line fault monitoring device provided in the embodiments of this application.

[0064] Figure 3 This is a structural block diagram of an engine off-line fault monitoring device according to an embodiment of this application. Figure 3 As shown, the device includes:

[0065] The acquisition unit 10 is used to acquire ECU message information collected by the client. The ECU message information is the detection information sent by the engine ECU during the engine offline test.

[0066] The parsing unit 20 is used to parse the ECU message information to obtain fault information, which includes engine number, fault code and fault description. The fault description is the fault description information corresponding to the fault code.

[0067] Establishment unit 30 is used to establish a priori engine fault code relationship network based on fault information. The priori engine fault code relationship network is used to represent the mapping relationship between engine number, fault code and fault description.

[0068] Query unit 40, in response to the query request, outputs the fault code and fault description corresponding to the engine number in the query request based on the prior engine fault code relationship network.

[0069] In the aforementioned engine off-line fault monitoring device, the acquisition unit acquires ECU message information collected by the client. This ECU message information represents the detection information sent by the engine's ECU during the engine off-line testing process. The parsing unit parses the ECU message information to obtain fault information, including the engine number, fault code, and fault description. The fault description corresponds to the fault code. The establishment unit establishes a priori engine fault code relationship network based on the fault information. This network represents the mapping relationship between the engine number, fault code, and fault description. The query unit responds to the query request and outputs the fault code and fault description corresponding to the engine number in the query request, based on the priori engine fault code relationship network. The message parsing function, the establishment of the priori engine fault code relationship network, and the query function of the cloud server can all be implemented through functional modules. These modules provide a pluggable development entry point, ensuring that the development of new functions does not affect the normal operation of already deployed functional modules. This reduces the risks associated with software iteration and solves the problem of engine off-line efficiency being affected by software updates in existing technologies.

[0070] In order to provide timely early warning of faults, in an optional embodiment, the above-mentioned device further includes:

[0071] The cleaning unit is used to parse the ECU message information on the cloud server, obtain the fault information, and then clean the abnormal data in the fault information. The abnormal data types include parsing abnormalities and fault code format abnormalities.

[0072] The feedback unit is used to query the prior fault category knowledge base based on the fault code to obtain the fault level of the fault code. The prior fault category knowledge base is used to represent the mapping relationship between fault codes and fault levels.

[0073] The alarm unit is used to trigger an alarm according to the alarm method corresponding to the fault level of the fault code.

[0074] In the above implementation, the cloud server includes a data governance module. This module is responsible for functions such as cleaning, transforming, issuing early warnings, and statistical analysis of fault information. After receiving fault data parsed by the gateway parsing module, the data governance module cleans and filters abnormal data, including parsing errors, fault code format errors, and other rule-defined forms. After obtaining the fault code, the module determines the fault code's level based on a priori fault level knowledge base and then pushes it to the cloud module to complete subsequent fault early warning alerts.

[0075] To enable self-learning updates of the prior fault category knowledge base, in one optional implementation, the feedback unit includes:

[0076] The first acquisition module is used to acquire the fault level of the manually assessed fault code when the fault code does not exist in the prior fault category knowledge base;

[0077] The update module is used to update fault codes and their corresponding fault levels to the prior fault category knowledge base.

[0078] In the above implementation, the prior fault level knowledge base is a self-learning fault level knowledge base. The initial state is manual maintenance. If a fault code parsed in subsequent use does not exist in the knowledge base, it will be automatically added to the knowledge base. The data governance module will push this information to the cloud module to complete the subsequent email notification to the relevant developers to complete the information maintenance of the new fault code and complete the information update.

[0079] To facilitate a unified representation of fault information, in one optional implementation, the parsing unit includes:

[0080] The parsing module is used to parse ECU message information to obtain fault data, which includes fault information and other information that is not fault information.

[0081] The processing module is used to filter and format fault information to obtain fault information. The formatting process is used to unify the fault codes and fault descriptions of different faults.

[0082] In the above embodiments, the data governance module is also used to clean and filter fault data, shielding preset rule information such as vehicle faults. After cleaning and transforming the data, fault data types are filled in and data verification is performed based on a priori fault category knowledge base. Then, formatting is performed to construct a test feature profile of the off-line engine. Based on a priori engine fault code relationship network, a relationship representation between the off-line test engine and faults is constructed, forming a mapping relationship representation of engine number, fault code, and fault description. The engine features are then pushed to the cloud module for subsequent persistent storage of data features. Based on the priori engine fault code relationship network, fault statistics for each off-line test engine and multi-dimensional (batch, type, etc.) batch fault statistics are implemented. The statistical information is pushed to the cloud module for subsequent statistical push.

[0083] To avoid the impact of feature updates on offline testing efficiency, in one optional implementation, the above-mentioned device further includes:

[0084] The update unit is used for iterative updates to update the data on the cloud server.

[0085] In the above implementation, the prior fault category knowledge base, the prior engine fault code relationship network, and the prior fault level knowledge base are all updated in a self-learning manner. Various cleaning, transformation, and formatting strategies in the data governance module are uniformly updated and released by the cloud module. The development of new functions will not affect the normal operation of the deployed functional modules.

[0086] To achieve engine off-line fault acquisition and monitoring, in one optional implementation, the acquisition unit includes:

[0087] The second acquisition module is used to acquire client information, which is the client's ID;

[0088] The registration module is used to register clients based on their information and establish a long-lived network connection between the client and the cloud server.

[0089] The third acquisition module is used to acquire ECU message information through a long network connection pipeline.

[0090] In the above embodiments, the cloud server further includes a gateway resolution module, and the client includes a fault acquisition module. The fault acquisition module is responsible for collecting ECU message information during the engine off-line testing process. Before the test begins, the fault acquisition module registers its terminal information (client information) with the cloud module, establishing a long-lived network connection pipeline that matches the gateway resolution module, reducing network connection request consumption for data distribution during the test. Simultaneously, it obtains the fault acquisition configuration set in the cloud and pushes data to the gateway resolution module in segments according to the preset acquisition frequency. The gateway resolution module receives message data through a message queue. After receiving the fault message pushed by the acquisition module, the gateway resolution module converts the message information into fault data and then pushes it to the data governance module.

[0091] To conserve network resources, in an optional implementation, the above-mentioned apparatus further includes:

[0092] The shutdown unit is used to shut down long network connections when the engine off-line testing is completed.

[0093] In the above implementation, after the test is completed, the fault acquisition module requests the cloud server to close the network connection pipeline and release network resources.

[0094] In addition, the aforementioned cloud server includes a cloud module, which is responsible for scheduling the test bench terminal (client) and cloud services. The cloud module is responsible for the registration and maintenance of the test bench terminal (client), receiving fault code level warning pushes from the data governance module, and receiving engine fault characteristics and fault statistics from the data governance module. Upon receiving a fault code level warning push, it pushes the fault level warning to the alarm device of the test bench terminal (client) based on the network channel registered between the test bench terminal (client) and the cloud. Upon receiving engine fault statistical characteristic pushes, it pushes this information to the acquisition terminal for real-time display on the client software, ensuring that the test bench obtains data statistical information; simultaneously, it stores the data along with the received engine fault characteristic push data to complete data persistence, ensuring subsequent query and retrieval needs. The cloud module can configure various strategies of the data governance module, meeting the requirements of online configurability and upgrade updates for various data governance strategies. Simultaneously, the cloud module can also dynamically adjust the frequency of fault data message collection.

[0095] The engine off-line fault monitoring device includes a processor and a memory. The aforementioned acquisition unit, parsing unit, establishment unit, and query unit are all stored as program units in the memory. The processor executes these program units stored in the memory to achieve the corresponding functions. All of the above modules reside in the same processor; alternatively, the modules may be located in different processors in any combination.

[0096] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and adjusting kernel parameters can address the issue of software updates impacting engine production efficiency in existing technologies.

[0097] The memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0098] This invention provides a computer-readable storage medium including a stored program, wherein the program, when running, controls the device where the computer-readable storage medium is located to execute an engine off-line fault monitoring method.

[0099] Specifically, the methods for monitoring engine off-line faults include:

[0100] Step S201: The cloud server obtains the ECU message information collected by the client. The ECU message information is the detection information sent by the engine ECU during the engine offline test.

[0101] In step S202, the cloud server parses the ECU message information to obtain fault information, which includes engine number, fault code and fault description. The fault description is the fault description information corresponding to the fault code.

[0102] Step S203: The cloud server establishes a priori engine fault code relationship network based on the fault information. The priori engine fault code relationship network is used to represent the mapping relationship between engine number, fault code and fault description.

[0103] In step S204, the cloud server responds to the query request by outputting the fault code and fault description corresponding to the engine number in the query request based on the prior engine fault code relationship network.

[0104] This invention provides a processor for running a program, wherein the program executes an engine offline fault monitoring method during runtime.

[0105] Specifically, the methods for monitoring engine off-line faults include:

[0106] Step S201: The cloud server obtains the ECU message information collected by the client. The ECU message information is the detection information sent by the engine ECU during the engine offline test.

[0107] In step S202, the cloud server parses the ECU message information to obtain fault information, which includes engine number, fault code and fault description. The fault description is the fault description information corresponding to the fault code.

[0108] Step S203: The cloud server establishes a priori engine fault code relationship network based on the fault information. The priori engine fault code relationship network is used to represent the mapping relationship between engine number, fault code and fault description.

[0109] In step S204, the cloud server responds to the query request by outputting the fault code and fault description corresponding to the engine number in the query request based on the prior engine fault code relationship network.

[0110] This application also provides a computer program product, which, when executed on a data processing device, is suitable for executing an initialization program having at least the following method steps:

[0111] Step S201: The cloud server obtains the ECU message information collected by the client. The ECU message information is the detection information sent by the engine ECU during the engine offline test.

[0112] In step S202, the cloud server parses the ECU message information to obtain fault information, which includes engine number, fault code and fault description. The fault description is the fault description information corresponding to the fault code.

[0113] Step S203: The cloud server establishes a priori engine fault code relationship network based on the fault information. The priori engine fault code relationship network is used to represent the mapping relationship between engine number, fault code and fault description.

[0114] In step S204, the cloud server responds to the query request by outputting the fault code and fault description corresponding to the engine number in the query request based on the prior engine fault code relationship network.

[0115] This invention provides a generator offline testing system, such as... Figure 4 As shown, the generator offline testing system includes a fault acquisition module, a gateway parsing module, a data governance module, a cloud module, an alarm device, and a storage medium. The operation process of the generator offline testing system is as follows: Figure 4 and Figure 5As shown, the fault acquisition module is responsible for collecting ECU message information during the engine off-line test. Before the test begins, the fault acquisition module registers the terminal information with the cloud module and establishes a long-term network connection pipeline matching the gateway parsing module to reduce the network connection request consumption for data distribution during the test. Simultaneously, it obtains the fault acquisition configuration set by the cloud and pushes the data to the gateway parsing module in segments according to the preset acquisition frequency. After the test, the acquisition module requests the cloud module to close the network connection pipeline and release network resources. The gateway parsing module receives message data through a message queue. After receiving the fault message pushed by the acquisition module, the gateway parsing module converts the message information into fault data and then pushes it to the data governance module. The data governance module is responsible for functions such as fault information cleaning, transformation, early warning, and statistics. The overall logical steps of this module are: ① Cleaning and early warning; ② Cleaning, transformation, formatting, and statistics. Steps ① and ② are processed in parallel. In step ①, after receiving the fault data parsed by the gateway parsing module, the data governance module cleans and filters abnormal data, including parsing anomalies, fault code format anomalies, and other rule-defined forms. After obtaining the fault code, the fault code's level is determined based on the prior fault level knowledge base, and then pushed to the cloud module for subsequent fault warning reminders. The prior fault level knowledge base is a self-learning fault level knowledge base, initially manually maintained. If a fault code parsed during subsequent use does not exist in the knowledge base, it is automatically added, and the data governance module pushes this information to the cloud module to notify relevant developers via email to maintain and update the information for the new fault code. Step 2 involves cleaning and filtering the fault data, filtering out preset rule information such as vehicle faults. The cleaned data is then transformed and, based on the prior fault category knowledge base, performs fault data type filling and data verification. Formatting is then performed to construct a test feature profile of the off-line engine. Based on the prior engine fault code relationship network, a relationship representation between the off-line test engine and faults is constructed, forming a mapping relationship between engine number, fault code, and fault description. The engine features are then pushed to the cloud module for subsequent persistent storage of data features. Based on the prior engine fault code relationship network, fault statistics for each engine's off-line testing are achieved, along with multi-dimensional (batch, type, etc.) batch fault statistics. This statistical information is pushed to the cloud module for subsequent statistical updates. The prior fault category knowledge base and the prior engine fault code relationship network, along with the prior fault level knowledge base from step ①, are self-learning and updated. Various cleaning, transformation, and formatting strategies in the data governance module are uniformly updated and published by the cloud module. The cloud module is responsible for scheduling the bench terminal and cloud services. It is also responsible for the registration and maintenance of the bench terminal, receiving fault code level warnings from the data governance module, and receiving engine fault characteristics and statistics from the data governance module.Upon receiving a fault code level warning push, the system pushes the warning to the alarm device via the network pipeline registered between the data acquisition terminal and the cloud. Upon receiving an engine fault statistical feature push, the system pushes this information to the data acquisition terminal for real-time display on the client software, ensuring the acquisition of statistical data at the test bench. Simultaneously, it stores the data along with the received engine fault feature push data for persistent storage, guaranteeing subsequent query and retrieval needs. The cloud module can configure various strategies for the data governance module, enabling online configurability and upgrades for various data governance strategies. The cloud module can also dynamically adjust the fault data message acquisition frequency. The alarm device is network-connected to the data acquisition terminal. During offline testing, if a fault occurs, it will be processed by other modules, and the fault level information signal will be fed back to the alarm device. Upon receiving the fault level signal, the alarm device executes the corresponding alarm strategy based on the different fault levels.

[0116] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0117] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0118] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0119] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0120] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0121] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0122] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0123] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0124] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0125] As can be seen from the above description, the embodiments of this application achieve the following technical effects:

[0126] 1) In the engine off-line fault monitoring method of this application, firstly, the cloud server obtains ECU message information collected by the client. The ECU message information is the detection information sent by the engine ECU during the engine off-line test. Then, the cloud server parses the ECU message information to obtain fault information, which includes the engine number, fault code, and fault description. The fault description is the fault description information corresponding to the fault code. Afterward, the cloud server establishes a priori engine fault code relationship network based on the fault information. The priori engine fault code relationship network is used to represent the mapping relationship between the engine number, fault code, and fault description. Finally, in response to the query request, the cloud server outputs the fault code and fault description corresponding to the engine number in the query request based on the priori engine fault code relationship network. The message parsing function, the function of establishing the priori engine fault code relationship network, and the query function of the cloud server can all be implemented through functional modules. The functional modules are pluggable development entry points, and the development of new functions will not affect the normal operation of the deployed functional modules, reducing the hidden dangers of software iteration development and solving the problem of engine off-line efficiency being affected by software updates and iterations in the prior art.

[0127] 2) In the engine off-line fault monitoring device of this application, the acquisition unit acquires ECU message information collected by the client. The ECU message information is the detection information sent by the engine ECU during the engine off-line test. The parsing unit parses the ECU message information to obtain fault information, which includes the engine number, fault code, and fault description. The fault description is the fault description information corresponding to the fault code. The establishment unit establishes a priori engine fault code relationship network based on the fault information. The priori engine fault code relationship network is used to represent the mapping relationship between the engine number, fault code, and fault description. The query unit responds to the query request and outputs the fault code and fault description corresponding to the engine number in the query request based on the priori engine fault code relationship network. Among them, the message parsing function of the cloud server, the function of establishing the priori engine fault code relationship network, and the query function can all be implemented through functional modules. The functional modules are pluggable development entry points. The development of new functions will not affect the normal operation of the deployed functional modules, reducing the hidden dangers of software iteration development and solving the problem of engine off-line software updates affecting off-line efficiency in the prior art.

[0128] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for monitoring engine decommissioning faults, characterized in that, include: The cloud server obtains ECU message information collected by the client, wherein the ECU message information is the detection information sent by the ECU of the engine during the engine's off-line testing process; The cloud server parses the ECU message information to obtain fault information, which includes engine number, fault code and fault description, and the fault description is the fault description information corresponding to the fault code. The cloud server establishes a priori engine fault code relationship network based on the fault information. The priori engine fault code relationship network is used to represent the mapping relationship between the engine number, the fault code, and the fault description. In response to the query request, the cloud server outputs the fault code and fault description corresponding to the engine number in the query request based on the prior engine fault code relationship network. After the cloud server parses the ECU message information to obtain fault information, the method further includes: the cloud server cleaning abnormal data in the fault information, wherein the abnormal data abnormality types include parsing abnormality and fault code format abnormality; The cloud server queries the prior fault category knowledge base based on the fault code to obtain the fault level of the fault code. The prior fault category knowledge base is used to represent the mapping relationship between the fault code and the fault level. The cloud server issues an alarm according to the alarm method corresponding to the fault level of the fault code.

2. The method according to claim 1, characterized in that, The cloud server queries a priori fault category knowledge base based on the fault code to obtain the fault level of the fault code, including: If the fault code does not exist in the prior fault category knowledge base, the cloud server obtains the fault level of the fault code as manually assessed. Update the fault code and the corresponding fault level to the prior fault category knowledge base.

3. The method according to claim 1, characterized in that, The cloud server parses the ECU message information to obtain fault information, including: The cloud server parses the ECU message information to obtain fault data, which includes the fault information and other information that is not part of the fault information. The fault information is filtered and formatted to obtain the fault information. The formatting process is used to unify the fault codes and fault descriptions of different faults.

4. The method according to claim 1, characterized in that, The method further includes: The cloud server is updated and iterated to update the functionality of the data on the cloud server.

5. The method according to claim 1, characterized in that, The cloud server obtains ECU message information collected by the client, including: The cloud server obtains client information, which is the client's ID; The cloud server registers the client based on the client information and establishes a long-term network connection between the client and the cloud server. The cloud server obtains the ECU message information through the network long connection pipeline.

6. The method according to claim 5, characterized in that, The method further includes: At the end of the engine off-line testing, the long network connection pipeline was shut off.

7. An engine off-line fault monitoring device, applied to a cloud server, characterized in that, include: The acquisition unit is used to acquire ECU message information collected by the client, wherein the ECU message information is the detection information sent by the ECU of the engine during the engine off-line testing process; The parsing unit is used to parse the ECU message information to obtain fault information, the fault information including engine number, fault code and fault description, the fault description being the fault description information corresponding to the fault code; A building unit is used to establish a priori engine fault code relationship network based on the fault information. The priori engine fault code relationship network is used to represent the mapping relationship between the engine number, the fault code and the fault description. The query unit, in response to a query request, outputs the fault code and fault description corresponding to the engine number in the query request based on the prior engine fault code relationship network; The device further includes: a cleaning unit, used to parse the ECU message information on the cloud server, obtain fault information, and then clean abnormal data in the fault information, wherein the abnormal data includes parsing abnormalities and fault code format abnormalities; a feedback unit, used to query a priori fault category knowledge base based on the fault code to obtain the fault level of the fault code, wherein the priori fault category knowledge base is used to represent the mapping relationship between the fault code and the fault level; and an alarm unit, used to trigger an alarm according to the alarm method corresponding to the fault level of the fault code.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein, when the program is executed, it controls the device on which the computer-readable storage medium is located to perform the method according to any one of claims 1 to 6.

9. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1 to 6.

Images