A remote fault diagnosis assisting method and system for a generator set

Abstract

The present application relates to the technical field of data processing for after-sales maintenance of generator sets, and particularly relates to a remote fault diagnosis assisting method and system for generator sets. The method comprises the following steps: receiving repair information and equipment identification of the generator set, reading the equipment archives, calling a generator set fault dictionary to perform entity extraction and synonym normalization on the fault description text, and generating a fault feature record; matching a standard fault code based on the equipment model and the equipment model adaptation relationship matching standard, and generating a candidate fault cause; generating a diagnosis suggestion based on the historical maintenance cases, and associating the maintenance scheme and the spare part demand record; querying the warehouse inventory account, generating an inventory checking result, an inventory locking record or a requisition, and binding the result to the diagnosis work order and pushing the result to the maintenance engineer terminal. The present application forms a continuous processing record of the repair information, the fault cause, the spare part demand and the inventory processing result, and effectively improves the consistency of the diagnosis work order and the spare part preparation state.

Description

Technical Field

[0001] This invention relates to the field of generator set after-sales maintenance data processing technology, and in particular to a remote fault diagnosis auxiliary method and system for generator sets. Background Technology

[0002] In the field of generator set after-sales maintenance data processing technology, existing solutions for remote fault diagnosis of generator sets typically receive operating data, instantaneous data of fault occurrence, repair requests, or repair work orders through generator set controllers, data acquisition modules, fault diagnosis platforms, or repair acceptance systems. Based on expert experience rules, fault diagnosis trees, historical repair cases, or manually entered content, they generate fault causes, repair suggestions, or repair work orders. While these solutions can monitor operating status, record fault information, and output repair suggestions in conventional scenarios, they are prone to limitations in generator set after-sales repair scenarios, such as difficulty in matching fault description text with standard fault codes, lack of compatibility between candidate fault causes and equipment records, and insufficient alignment between diagnostic suggestions and spare parts inventory status.

[0003] Existing solutions often rely on generator set operating data, fixed fault rules, manual acceptance records, or separate inventory query processes for processing. When customer-submitted repair information contains colloquial descriptions, synonyms, requires the association of equipment identification with equipment files, or involves changes in parts inventory versions, there is a lack of stable coordination between fault description parsing, candidate fault cause generation, repair plan association, and inventory processing. This can easily lead to inconsistencies between fault causes, parts demand records, and inventory processing results in diagnostic work orders, and makes it difficult to generate inventory lock records or transfer requests simultaneously with diagnostic work orders.

[0004] Regarding the joint processing of repair reports, fault characteristic records, candidate fault causes, parts demand records, and inventory processing results, existing technologies still have common shortcomings in text parsing, fault code matching, repair plan association, inventory verification, and work order push. Therefore, it is necessary to address the issue of generating fault characteristic records based on repair reports and linking them with parts demand records and inventory processing results, specifically for generator set after-sales repair scenarios. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides a remote fault diagnosis assistance method for generator sets, comprising:

[0006] S100: Receive the generator set's repair information and equipment identifier, read the equipment file based on the equipment identifier, and call the generator set fault dictionary to extract entities and normalize synonyms from the fault description text in the repair information to generate a fault feature record.

[0007] S200. Based on the equipment model and equipment model compatibility relationship in the equipment file, standard fault codes are searched and compared, and the fault feature record is matched with the search results to generate candidate fault causes.

[0008] S300. Based on historical maintenance cases, sort the candidate fault causes, generate diagnostic suggestions, and generate basic records of diagnostic work orders based on the diagnostic suggestions, which are associated with maintenance plans and parts requirement records.

[0009] S400: Based on the parts demand record, query the warehouse inventory ledger, read the inventory version and lock validity period and generate an inventory verification result. Based on the inventory verification result, generate an inventory lock record or transfer request, bind the diagnostic suggestion, the repair plan, the parts demand record and the inventory processing result to the diagnostic work order, and push it to the repair engineer terminal.

[0010] Furthermore, the repair information includes telephone recording transcripts or online text; when the recognition confidence of the telephone recording transcript is lower than a preset threshold, a record for the field to be confirmed is generated based on the device identifier, the fault description text, and the device file.

[0011] Furthermore, the generator set fault dictionary includes fault phenomenon words, component words, operating status words, alarm words, and synonym mapping relationships; the entity extraction includes extracting the fault phenomenon words, component words, operating status words, and alarm words from the fault description text; the synonym normalization includes converting the extraction results into the fault feature records based on the synonym mapping relationships.

[0012] Furthermore, the equipment file includes equipment model, controller model, power rating, and engine type; the search and comparison of standard fault codes includes: searching in the equipment model compatibility relationship based on the equipment model, controller model, power rating, and engine type to generate fault code filtering results; and generating candidate fault causes based on the fault code filtering results and the fault feature record.

[0013] Furthermore, the step of sorting the candidate fault causes based on historical maintenance cases includes: generating a candidate cause sorting record based on fault feature matching degree, historical occurrence frequency, average maintenance time, most recent maintenance time and equipment model compatibility; and selecting the diagnostic suggestion according to the candidate cause sorting record.

[0014] Furthermore, the repair plan includes suggested inspection items, required tools and accessory compatibility relationships; the accessory requirement record includes accessory code, required quantity, compatible equipment model and alternative part identification; the accessory requirement record is generated from the diagnostic suggestions, the repair plan and the accessory compatibility relationships.

[0015] Furthermore, generating the inventory verification result includes: based on the accessory code and required quantity in the accessory demand record, reading the available inventory, locked quantity, inventory version, and lock validity period from the warehouse inventory ledger; binding the available inventory, the locked quantity, the inventory version, and the lock validity period with the accessory demand record to generate the inventory verification result.

[0016] Further, generating an inventory lock record or transfer request based on the inventory verification result includes: when the quantity of available inventory after deducting the locked quantity is not less than the required quantity, generating the inventory lock record based on the part code, the required quantity, the inventory version, and the lock validity period; when the quantity of available inventory after deducting the locked quantity is less than the required quantity, generating the transfer request based on the part code, the required quantity, and the warehouse inventory ledger.

[0017] Furthermore, the system receives the actual fault cause, actual replaced parts, and actual repair time from the maintenance engineer's terminal; it then searches and compares the actual fault cause, actual replaced parts, and actual repair time with the diagnostic work order to generate a status write-back record, and updates the historical repair case based on the status write-back record.

[0018] Furthermore, a remote fault diagnosis auxiliary system for generator sets includes: a repair information receiving module, a fault feature record generation module, a fault diagnosis module, a maintenance plan generation module, an inventory verification module, and a diagnostic work order push module; the system is used to implement the method described in any of the above-mentioned embodiments.

[0019] The key innovations of this invention include:

[0020] (1) Associate the equipment identifier in the repair information with the equipment file, and call the generator set fault dictionary to extract entities and normalize synonyms from the fault description text to generate a fault feature record containing equipment file fields and standard fault phenomena.

[0021] (2) Based on the equipment model and equipment model compatibility relationship in the equipment file, standard fault codes are searched and compared, and fault feature records are matched with search results to generate candidate fault causes. Then, based on historical maintenance cases, candidate fault causes are sorted to generate diagnostic suggestions.

[0022] (3) Based on the diagnostic suggestions, associate the maintenance plan and parts demand records, generate the basic record of the diagnostic work order, query the warehouse inventory ledger based on the parts demand records, read the inventory version and lock validity period, generate inventory verification results, inventory lock records or transfer requests, and bind the inventory processing results to the diagnostic work order.

[0023] The following are its main beneficial effects:

[0024] (1) To address the problem that the colloquial descriptions and synonyms in the fault description text make it difficult to correspond with standard fault codes, fault feature records are formed by associating equipment files, extracting entities, and normalizing synonyms, so that the repair information can be transformed into a structured record that can be used for subsequent standard fault code matching.

[0025] (2) To address the issues of missing compatibility between candidate fault causes and equipment files, and the reliance on manual judgment for diagnostic suggestions, standard fault codes are searched and compared through equipment model compatibility, and candidate fault causes are sorted in conjunction with historical maintenance cases, so that diagnostic suggestions have a corresponding basis in equipment files and historical maintenance cases.

[0026] (3) To address the issue of insufficient connection between diagnostic recommendations, parts demand records and inventory processing results, the warehouse inventory ledger is queried through parts demand records and the inventory version and lock validity period are read, so that the inventory verification results, inventory lock records or transfer requests can be bound to the diagnostic work order to form the same processing record. Attached Figure Description

[0027] Figure 1 A flowchart illustrating a remote fault diagnosis assistance method for generator sets provided in an embodiment of this application;

[0028] Figure 2 This is a structural block diagram of a remote fault diagnosis auxiliary system for generator sets provided in an embodiment of this application. Detailed Implementation

[0029] Example 1: Refer to Figure 1 This is a flowchart illustrating a remote fault diagnosis assistance method for generator sets provided in an embodiment of the present invention. The process may include at least steps S100-S400:

[0030] S100: Receive the generator set's repair information and equipment identifier, read the equipment file based on the equipment identifier, and call the generator set fault dictionary to extract entities and normalize synonyms from the fault description text in the repair information to generate a fault feature record.

[0031] S200. Based on the equipment model and equipment model compatibility relationship in the equipment file, standard fault codes are searched and compared, and the fault feature record is matched with the search results to generate candidate fault causes.

[0032] S300. Based on historical maintenance cases, sort the candidate fault causes, generate diagnostic suggestions, and generate basic records of diagnostic work orders based on the diagnostic suggestions, which are associated with maintenance plans and parts requirement records.

[0033] S400: Based on the parts demand record, query the warehouse inventory ledger, read the inventory version and lock validity period and generate an inventory verification result. Based on the inventory verification result, generate an inventory lock record or transfer request, bind the diagnostic suggestion, the repair plan, the parts demand record and the inventory processing result to the diagnostic work order, and push it to the repair engineer terminal.

[0034] S100: Receive the generator set's repair information and equipment identifier, read the equipment file based on the equipment identifier, and call the generator set fault dictionary to extract entities and normalize synonyms from the fault description text in the repair information to generate a fault feature record.

[0035] This step is performed by the repair information receiving module and the fault feature record generation module. The repair information receiving module is deployed on the fault diagnosis platform and receives repair information from clients, online repair forms, telephone recording transcription interfaces, or maintenance acceptance terminals. The fault feature record generation module is connected to the database service module, reads the equipment file based on the equipment identifier in the repair information, and calls the generator set fault dictionary to parse and convert the fault description text.

[0036] In this step, the repair information refers to the generator set fault report submitted by the customer, which includes the equipment identifier and a fault description text. The equipment identifier is the key to search for the generator set in the equipment file, specifically the equipment number, factory number, unit number, or the equipment binding number in the after-sales system. The fault description text is a written description of the fault phenomenon by the customer, which can be from online text or from a transcript of a recorded telephone conversation. The equipment file includes the equipment model, controller model, power rating, and engine type, and can record the equipment installation location, commissioning time, warranty status, and service area; the equipment model, controller model, power rating, and engine type are used for subsequent standard fault code lookup and comparison.

[0037] In one implementation, the customer submits a fault description text, "The engine shuts off immediately after startup, and the controller has a low oil pressure alarm," via an online repair form, and enters the equipment identifier. The repair information receiving module receives this information and sends the equipment identifier to the database service module. The database service module searches the equipment file according to the equipment identifier, reads the equipment model, controller model, power rating, and engine type, and returns the results to the fault feature record generation module. If multiple generator sets are bound to the same customer account, the repair information receiving module searches and compares the customer account, repair location, and equipment identifier to generate a record for fields to be confirmed. This record is then supplemented by the maintenance acceptance terminal before entering the fault feature record generation module.

[0038] The generator set fault dictionary includes fault phenomenon terms, component terms, operating status terms, alarm terms, and synonym mapping relationships. Fault phenomenon terms record the correspondence between common customer descriptions and standard fault phenomena; for example, "cannot start," "cannot start," and "unable to start" correspond to starting failure. Component terms record the names of generator set components, such as battery, starter motor, controller, fuel injector, oil pressure sensor, speed governor, and excitation regulator. Operating status terms record starting, idling, under load, stopped, alarm shutdown, and no-load operation. Alarm terms record low oil pressure alarm, high water temperature alarm, low voltage alarm, abnormal frequency alarm, and overload alarm. The synonym mapping relationships are used to convert customer natural language expressions into standard descriptions adopted by the system.

[0039] The entity extraction includes extracting fault phenomenon terms, component terms, operating status terms, and alarm terms from the fault description text. Specifically, the fault feature record generation module first performs character standardization processing on the fault description text, unifying full-width characters, half-width characters, uppercase and lowercase letters, and common symbols; then, it performs word segmentation according to the generator set fault dictionary, and searches and compares the segmentation results with fault phenomenon terms, component terms, operating status terms, and alarm terms; for the found terms, it records the source text fragment, term type, and position in the fault description text. The synonym normalization includes converting the extraction results into fault feature records based on synonym mapping relationships. For example, "machine won't start" and "motor turns but won't start" are normalized to start-up failure, and "a lot of black smoke" is normalized to the black smoke state in abnormal smoke emission.

[0040] The fault feature record is the output object generated in this step, which includes equipment identifier, equipment model, controller model, power rating, engine type, standard fault phenomenon, component object, operating status, alarm word, source text fragment, dictionary version, and parsing status. The dictionary version records the generator set fault dictionary version called in this parsing; the parsing status records normal parsing, fields awaiting confirmation, fault dictionary mismatch, or missing text. After the fault feature record is written to the database service module, it is called by S200.

[0041] When the repair request is a transcript of a telephone recording, the repair request receiving module also receives the recognition confidence level returned by the speech-to-text interface. If the recognition confidence level is lower than a preset threshold, the repair request receiving module generates a record of fields to be confirmed based on the equipment identifier, fault description text, and equipment file. The record of fields to be confirmed includes a text fragment to be confirmed, candidate fault phenomena, candidate component objects, and confirmation status. After the record of fields to be confirmed is confirmed by the maintenance acceptance terminal, the fault feature record generation module performs entity extraction and synonym normalization based on the confirmed fields. If the fault description text is empty, or the fault description text does not match the generator set fault dictionary, the fault feature record generation module retains the original fault description text and records the parsing status as fault dictionary not matched; this record still enters S200, where S200 performs subsequent searches and comparisons based on the equipment file and identifiable fields.

[0042] In another implementation, the generator set fault dictionary is maintained by the database service module. When the dictionary version changes, the fault feature record generation module reads the new dictionary version the next time it receives a repair request; the generated fault feature records retain their corresponding dictionary versions. If the same repair request is re-parsed, the system writes the new dictionary version, the re-parse time, and the re-parse status into the parsing record corresponding to the same device identifier, without overwriting the original fault description text.

[0043] For example, a customer describes over the phone that "the diesel engine can turn but won't start, and there's a low oil pressure alarm on the screen." The transcribed text of the call is sent to the repair information receiving module. The fault feature record generation module reads the equipment file, obtaining the equipment model as a specific diesel generator set model and the controller model as a specific controller model. Then, it extracts "can turn but won't start" as a fault symptom term, "low oil pressure alarm" as an alarm term, and "diesel engine" as a component term from the generator set fault dictionary. Next, it uses synonym mapping to convert "can turn but won't start" to "start failure" and "low oil pressure alarm" to "low oil pressure alarm." Finally, it generates a fault feature record containing "start failure," "low oil pressure alarm," engine component object, and corresponding equipment file fields. This fault feature record serves as input to the S200 system, where it is searched and compared against standard fault codes and equipment model compatibility.

[0044] S200. Based on the equipment model and equipment model compatibility relationship in the equipment file, standard fault codes are searched and compared, and the fault feature record is matched with the search results to generate candidate fault causes.

[0045] This step is performed by the fault diagnosis module. The fault diagnosis module reads the fault feature records generated by S100 from the database service module, and simultaneously reads the equipment file, standard fault codes, and equipment model compatibility relationships. The standard fault codes are fault code records pre-maintained by the generator set fault diagnosis platform, and include the fault code, standard fault phenomenon, compatible equipment model, compatible controller model, compatible power level, compatible engine type, candidate fault causes, and fault cause category. The equipment model compatibility relationships are used to record the compatibility range between the equipment file fields and the standard fault codes.

[0046] The device model compatibility relationship serves as a constraint for standard fault code lookup and comparison in this step. The fault diagnosis module first reads the device model, controller model, power rating, and engine type from the device file; then, it searches within the device model compatibility relationship to generate a fault code filtering result. This filtering result includes standard fault codes compatible with the device model, controller model, power rating, and engine type. If a standard fault code simultaneously satisfies the compatibility relationship between the device model and engine type, the fault diagnosis module prioritizes this standard fault code for search. If the device file lacks a controller model, the fault diagnosis module retains the device model, power rating, and engine type for the search and records the missing controller model status in the fault code filtering result.

[0047] After generating the fault code filtering results, the fault diagnosis module matches the fault feature records with the fault code filtering results. Specifically, the fault diagnosis module reads the standard fault phenomena, component objects, operating status, and alarm words from the fault feature records; then it searches and compares these fields with the standard fault phenomena, candidate fault cause categories, and alarm conditions in the fault code filtering results; when the standard fault phenomena are consistent and the alarm words match, a candidate fault cause is generated; when the standard fault phenomena are consistent but the alarm words are missing, the candidate fault cause is retained, and the alarm word missing status is recorded in the candidate fault cause; when the standard fault phenomena are not completely consistent but the synonym normalization result matches the alias record of the standard fault code, the fault diagnosis module adds the fault cause corresponding to the standard fault code to the candidate fault causes.

[0048] The candidate fault causes are the output objects of this step, including equipment identifier, standard fault code, standard fault phenomenon, candidate cause name, candidate cause category, matching field, matching status, and fault code filtering result reference identifier. The candidate cause category can be recorded as fuel system, starting system, cooling system, controller input, excitation system, speed control system, or sensor abnormality; the matching status can be recorded as complete match, partial match, alarm word missing match, equipment file field missing match, or dictionary mismatch pending verification. The candidate fault causes are associated with the fault feature records generated in S100, and then proceed to S300 for historical maintenance case sorting.

[0049] The trigger condition for this step is that S100 generates a fault feature record and writes it to the database service module. If the parsing status of the fault feature record is normal parsing, the fault diagnosis module directly performs standard fault code lookup and comparison; if the parsing status is a record of fields to be confirmed, the fault diagnosis module reads the confirmed fields; if the parsing status is a fault dictionary mismatch, the fault diagnosis module retains the original text of the equipment model and repair information in the equipment file and generates a candidate fault cause record to be reviewed. The candidate fault causes to be reviewed do not directly enter the parts demand record generation, but instead enter the maintenance acceptance terminal, where the maintenance acceptance terminal supplements the fault phenomenon or component object and then re-triggers this step.

[0050] In one implementation, standard fault codes are maintained according to generator set type. For diesel generator sets, standard fault codes may include start-up failure, low generator voltage, abnormal frequency, high water temperature, low oil pressure alarm, black smoke, and overload shutdown; for gas generator sets, standard fault codes may include ignition failure, abnormal gas pressure, unstable speed, and abnormal exhaust temperature. The fault diagnosis module does not simply rely on the fault description text to match all standard fault codes, but first searches and compares them against the equipment file, and then matches the fault characteristic record with the search results. The resulting candidate fault causes carry equipment file reference identifiers, allowing the S300 to search by equipment model when recalling historical maintenance cases.

[0051] For example, the fault feature record generated by S100 includes equipment model, start-up failure, low oil pressure alarm, and engine component object. The fault diagnosis module searches for the standard fault code corresponding to the equipment model based on the equipment model adaptation relationship, obtaining standard fault codes for start-up failure and low oil pressure alarm. Then, it matches the start-up failure in the fault feature record with the start-up failure in the standard fault codes, and matches the low oil pressure alarm with the alarm conditions in the standard fault codes, generating candidate fault causes, including insufficient battery voltage, starter motor malfunction, fuel control valve malfunction, oil pressure sensor malfunction, and insufficient oil pressure. These candidate fault causes include matching fields and fault code filtering result reference identifiers, and are used as input for sorting by S300.

[0052] If the power rating or engine type in the equipment file is inconsistent with the record in the equipment model compatibility relationship, the fault diagnosis module marks that equipment file field as a status conflict and generates a candidate fault cause record containing the conflicting field. This record can be entered into the manual review path, or it can continue to enter S300 while retaining the equipment model compatibility relationship search results; when entering S300, the candidate cause sorting record will record the status conflict field, which can be viewed on the maintenance engineer's terminal later.

[0053] S300. Based on historical repair cases, sort the candidate fault causes, generate diagnostic suggestions, and generate basic records of diagnostic work orders based on the diagnostic suggestions, which are associated with repair plans and parts requirement records.

[0054] This step is performed by the maintenance plan generation module. The maintenance plan generation module receives candidate fault causes generated by S200 and reads historical maintenance cases, maintenance plans, and parts compatibility relationships from the database service module. The historical maintenance cases are records of completed maintenance work orders, including equipment model, standard fault code, actual fault cause, actual replaced parts, actual maintenance time, maintenance completion time, and case status. The maintenance plan is a maintenance processing record corresponding to the standard fault code or candidate fault cause, including suggested inspection items, required tools, inspection sequence, parts compatibility relationships, and plan version. The parts compatibility relationships are used to record part codes, compatible equipment models, compatible controller models, replacement part identifiers, and required quantity generation rules.

[0055] The maintenance plan generation module first reads historical maintenance cases based on candidate fault causes. Specifically, the module uses equipment model, standard fault code, and candidate cause name as search criteria to find completed case records with a valid status in the historical maintenance cases. For historical maintenance cases with completely identical equipment models, the module records them as cases of the same model. For historical maintenance cases with different equipment models but the same power rating and engine type, the module records them as cases of the same type of equipment. For historical maintenance cases with identical standard fault codes but slightly different equipment file fields, the module records them as reference cases. These case records then enter the process of generating candidate cause sorting records.

[0056] The candidate cause ranking record is generated based on fault feature matching degree, historical occurrence frequency, average maintenance time, most recent maintenance time, and equipment model compatibility. Fault feature matching degree is formed by the number of corresponding matching fields in the candidate fault causes and the standard fault phenomena, component objects, operating states, and alarm words in the fault feature record; historical occurrence frequency is formed by the number of times the same standard fault code and the same candidate cause name appear in historical maintenance cases; average maintenance time is formed by the actual maintenance time in historical maintenance cases; most recent maintenance time is formed by the maintenance completion time in historical maintenance cases; and equipment model compatibility is formed by the types of cases of the same model, cases of similar equipment, and reference cases. The maintenance plan generation module writes the above fields into the candidate cause ranking record and selects diagnostic suggestions according to the candidate cause ranking record.

[0057] The diagnostic suggestion is an intermediate output of this step, including device identifier, standard fault code, sorted candidate fault causes, suggested inspection items, candidate cause sorting record reference identifier, and suggestion status. If there are multiple records among the candidate fault causes with adjacent sorting results and a difference less than a preset difference, the maintenance plan generation module retains multiple candidate fault causes in the diagnostic suggestion and provides an inspection order according to the candidate cause sorting record; if there is only one valid record for a candidate fault cause, the maintenance plan generation module uses that candidate fault cause as the primary fault cause in the diagnostic suggestion. The preset difference here is a system configuration item that can be configured by the fault diagnosis platform according to the standard fault code category.

[0058] After generating diagnostic suggestions, the repair solution generation module associates these suggestions with repair solutions and parts requirement records. Specifically, the module reads the standard fault codes and candidate fault causes from the diagnostic suggestions, searches for the corresponding solution version in the repair solutions, reads the suggested inspection items, required tools, and parts compatibility relationships from the repair solutions, and then generates parts requirement records based on these compatibility relationships. These parts requirement records include parts codes, required quantities, compatible equipment models, and substitute part identifiers. The required quantity can be given by the parts usage rules in the repair solutions or by the default quantity in the parts compatibility relationships. If a substitute part identifier exists in the repair solutions, the module writes the primary part and the substitute part into the parts requirement records respectively, and records the priority status of the primary part.

[0059] The diagnostic work order basic record is the output object of this step, which includes the repair information reference identifier, equipment identifier, equipment file reference identifier, fault characteristic record reference identifier, candidate fault cause reference identifier, diagnostic suggestion, maintenance plan, parts requirement record, and work order basic status. The work order basic status can be recorded as pending inventory verification, pending review, or pending supplementation. If there are candidate fault causes pending review in the diagnostic suggestion, the diagnostic work order basic record is marked as pending review; if both the diagnostic suggestion and the parts requirement record have been generated, the diagnostic work order basic record is marked as pending inventory verification and proceeds to S400.

[0060] In one implementation, historical maintenance cases are generated by the maintenance result write-back module after maintenance is completed. The actual fault cause, actual replaced parts, and actual maintenance time in the historical maintenance cases are written to the database service module after being transmitted back by the maintenance engineer's terminal. When the maintenance plan generation module reads historical maintenance cases, it filters valid records according to the case status; historical maintenance cases with statuses of canceled, false alarm, or incomplete are not included in the candidate cause sorting record. If the number of historical maintenance cases is insufficient, the maintenance plan generation module retains the fault feature matching degree and equipment model compatibility fields and records the insufficient historical cases status in the candidate cause sorting record.

[0061] For example, the candidate fault causes generated by S200 include insufficient battery voltage, fuel control valve malfunction, and oil pressure sensor malfunction. The repair solution generation module searches historical repair cases based on the equipment model and standard fault codes for start-up failures. It finds cases where insufficient battery voltage occurs frequently, fuel control valve malfunctions take a long time to repair, and oil pressure sensor malfunctions are associated with low oil pressure alarms. Subsequently, it generates a candidate cause ranking record and forms diagnostic suggestions, including checking the battery voltage first, followed by checking the fuel control valve and oil pressure sensor. Based on these diagnostic suggestions, the repair solution generation module associates repair solutions, reads the required tool and accessory compatibility relationships, generates a accessory requirement record including the battery, fuel control valve seals, and oil pressure sensor, and writes it into the diagnostic work order basic record.

[0062] If the repair plan and the parts compatibility relationship are inconsistent, the repair plan generation module writes the version inconsistency status into the diagnostic work order basic record and reads the currently valid parts compatibility relationship. If the currently valid parts compatibility relationship cannot be read, the diagnostic work order basic record is marked as a field to be supplemented. This diagnostic work order basic record is not entered into inventory locking processing. The parts demand record generation process in S300 is retried after the parts compatibility relationship is supplemented. Once the parts demand record is generated, S400 can query the warehouse inventory ledger based on the parts code and the required quantity.

[0063] S400: Based on the parts demand record, query the warehouse inventory ledger, read the inventory version and lock validity period and generate an inventory verification result. Based on the inventory verification result, generate an inventory lock record or transfer request, bind the diagnostic suggestion, the repair plan, the parts demand record and the inventory processing result to the diagnostic work order, and push it to the repair engineer terminal.

[0064] This step is performed by the inventory verification module and the diagnostic work order push module. The inventory verification module receives the basic record of the diagnostic work order generated by S300, and reads the parts demand record, diagnostic suggestions, and repair plan from the basic record; then it queries the warehouse inventory ledger to read the available inventory, locked quantity, inventory version, and lock validity period corresponding to the parts code, and generates the inventory verification result. The diagnostic work order push module receives the inventory verification result, inventory lock record, or transfer request, and binds the inventory processing result with the diagnostic suggestions, repair plan, and parts demand record to the diagnostic work order, and pushes it to the repair engineer's terminal.

[0065] The warehouse inventory ledger is a data record in the inventory system that records the inventory status of parts. It includes warehouse identifier, part code, available inventory, locked quantity, inventory version, inventory update time, and warehouse area. The inventory version records the status version of the inventory ledger when it is read; the lock validity period records the valid time range of the inventory lock record. When the inventory verification module reads the inventory version, it binds the inventory version with the part demand record; when a subsequent inventory lock record is generated, the inventory lock record continues to reference this inventory version. If the inventory version returned by the inventory system has changed before locking, the inventory verification module rereads the warehouse inventory ledger and generates a new inventory verification result based on the new inventory version.

[0066] The inventory verification results include the part code, required quantity, available inventory, locked quantity, inventory version, lock validity period, warehouse identifier, and verification status. The inventory verification module reads the available inventory, locked quantity, inventory version, and lock validity period from the warehouse inventory ledger based on the part code and required quantity in the part requirement record. It then compares the available inventory (minus the locked quantity) with the required quantity to generate a verification status. If the available inventory (minus the locked quantity) is not less than the required quantity, the verification status is recorded as "locking condition met"; if the available inventory (minus the locked quantity) is less than the required quantity, the verification status is recorded as "locking condition not met". If a substitute part identifier exists in the part requirement record, the inventory verification module first reads the main part's inventory verification result; if the main part does not meet the locking condition, it then reads the warehouse inventory ledger corresponding to the substitute part and generates a substitute part's inventory verification result.

[0067] When the inventory verification result meets the locking conditions, the inventory verification module generates an inventory lock record based on the part code, required quantity, inventory version, and lock validity period. The inventory lock record includes the diagnostic work order basic record reference identifier, equipment identifier, part code, locked quantity, warehouse identifier, inventory version, lock validity period, and lock status. The lock status can be recorded as lock successful, lock failed, or lock pending confirmation. If the inventory version is inconsistent with the current version in the warehouse inventory ledger when generating the inventory lock record, the inventory verification module does not write a lock successful status; instead, it re-queries the warehouse inventory ledger and generates a new inventory verification result.

[0068] When the inventory verification result does not meet the locking conditions, the inventory verification module generates a transfer request based on the part code, required quantity, and warehouse inventory ledger. The transfer request includes the diagnostic work order basic record reference identifier, part code, required quantity, target warehouse, originating warehouse, transfer quantity, and transfer status. The target warehouse can be generated from the warehouse corresponding to the service area in the equipment file or the area where the maintenance engineer's terminal is located; the originating warehouse is generated from the warehouse in the warehouse inventory ledger whose available inventory meets or partially meets the required quantity; the transfer status can be recorded as pending transfer, partial transfer, transfer completed, or transfer failed. If multiple warehouses have available inventory, the inventory verification module generates an originating warehouse record according to the correspondence between the warehouse area and the equipment file service area; if no warehouse meets the required quantity, a transfer failure status is generated, and an insufficient inventory field is retained.

[0069] In this step, the inventory processing result refers to the inventory lock record or transfer request. The diagnostic work order push module binds the inventory processing result, diagnostic suggestions, repair plans, and parts demand records to the diagnostic work order. The diagnostic work order includes a work order identifier, a repair information reference identifier, an equipment identifier, an equipment file field, a fault characteristic record reference identifier, candidate fault causes, diagnostic suggestions, repair plans, parts demand records, inventory verification results, inventory lock record or transfer request, push status, and work order status. If the inventory lock record is successfully locked, the work order status is recorded as "awaiting receipt by the repair engineer"; if the transfer request is pending transfer, the work order status is recorded as "awaiting parts transfer"; if the inventory processing result is a lock failure or transfer failure, the work order status is recorded as "awaiting review".

[0070] In one implementation, the diagnostic work order push module pushes the diagnostic work order to the maintenance engineer's terminal, which receives diagnostic suggestions, repair plans, parts requirement records, and inventory processing results. The maintenance engineer's terminal displays the candidate fault cause ranking, suggested inspection items, required tools, parts codes, inventory lock records, or transfer request status in the diagnostic work order. If the maintenance engineer's terminal does not return a receipt status within a preset time, the diagnostic work order push module records the push status as "not received" and returns the diagnostic work order to the pending list of the fault diagnosis platform. This processing does not change the lock validity period of the inventory lock record; when the lock validity period expires and no requisition status is generated, the inventory verification module updates the inventory lock record to "lock timeout release" and writes the release status to the diagnostic work order.

[0071] For example, the parts requirement record generated by S300 includes a parts code for an oil pressure sensor, a required quantity of 1, and a compatible equipment model for a diesel generator set. The inventory verification module queries the warehouse inventory ledger and reads that the available inventory of this part in the target warehouse is 3, the locked quantity is 1, the inventory version is V2026070201, and the lock validity period is 24 hours. Since the available inventory minus the locked quantity is 2, the inventory verification module generates an inventory verification result that meets the locking conditions and generates an inventory lock record based on the parts code, required quantity, inventory version, and lock validity period. The diagnostic work order push module then binds the diagnostic suggestions, repair plan, parts requirement record, and this inventory lock record to the diagnostic work order and pushes it to the repair engineer's terminal.

[0072] In another implementation, if the required quantity of fuel control valve seals in the parts demand record is 2, while the available inventory in the target warehouse is 1 and the locked quantity is 1, the inventory verification module generates an inventory verification result indicating that the locking conditions are not met. Subsequently, it searches the warehouse inventory ledger for available inventory of the corresponding parts code in other warehouses and generates a transfer request containing the target warehouse, the warehouse from which the transfer originates, the transfer quantity, and the transfer status. The diagnostic work order push module binds this transfer request as an inventory processing result to the diagnostic work order. After receiving the diagnostic work order, the maintenance engineer's terminal can read the transfer status and parts demand record.

[0073] After repair, the repair result write-back module receives the actual fault cause, actual replaced parts, and actual repair time from the repair engineer's terminal. The actual fault cause, actual replaced parts, and actual repair time are compared with the diagnostic work order to generate a status write-back record. This record includes a diagnostic work order reference identifier, actual fault cause, actual replaced parts, actual repair time, diagnostic suggestion reference identifier, parts requirement record reference identifier, and write-back status. The database service module updates historical repair cases based on the status write-back record, enabling the S300 to retrieve new repair completion records when reading historical repair cases. If the actual replaced parts do not match the parts code in the inventory lock record, the repair result write-back module writes a parts discrepancy field to the status write-back record and retains the original inventory lock record and the actual replaced parts record.

[0074] Example 2: Figure 2 A structural block diagram of a remote fault diagnosis auxiliary system for generator sets according to an embodiment of the present invention is shown. Figure 2 As shown, the structure may include:

[0075] The repair information receiving module 01 is used to receive repair information and equipment identification from the generator set. The module receives repair information from clients, online repair forms, telephone recordings transcribed into text, or maintenance acceptance terminals, and reads the equipment identification and fault description text from the repair information. The module performs format verification on the equipment identification and establishes the same repair record for the equipment identification and the fault description text. When the fault description text is empty or the equipment identification is missing, the module generates a record for a field to be confirmed and retains the original repair information. When the repair information is telephone recording transcribed into text, the module records the identification confidence level and the source text fragment. The module provides the equipment identification, the fault description text, and the repair record to the fault feature record generation module.

[0076] The fault feature record generation module 02, connected to the repair information receiving module, is used to read the equipment file based on the equipment identifier and call the generator set fault dictionary to extract entities and normalize synonyms from the fault description text in the repair information to generate a fault feature record. The fault feature record generation module receives the equipment identifier, fault description text, and repair record provided by the repair information receiving module, and reads the equipment file based on the equipment identifier. The equipment file includes the equipment model, controller model, power rating, and engine type. The fault feature record generation module calls the generator set fault dictionary to extract entities from the fault description text. The system extracts fault phenomenon terms, component terms, operating status terms, and alarm terms, and converts the extracted results into fault feature records based on synonym mapping relationships. When the fault description text does not match the generator set fault dictionary, the fault feature record generation module writes the original fault description text into the fault feature record and records the fault dictionary mismatch status. The fault feature record includes equipment identifier, equipment model, controller model, power level, engine type, standard fault phenomenon, component object, operating status, alarm term, and parsing status. The fault feature record generation module provides the equipment file and the fault feature record to the fault diagnosis module.

[0077] The fault diagnosis module 03, connected to the fault feature record generation module, is used to search and compare standard fault codes based on the equipment model and equipment model adaptation relationship in the equipment file, and match the fault feature record with the search results to generate candidate fault causes. The fault diagnosis module receives the equipment file and fault feature record provided by the fault feature record generation module, reads the equipment model in the equipment file, and searches and compares standard fault codes in the equipment model adaptation relationship. The fault diagnosis module forms search results for standard fault codes that match the equipment model adaptation relationship, and then compares the standard fault phenomena and components in the fault feature record. The system matches the object, operating status, and alarm words with the search results. When both the standard fault symptom and the alarm word match, the fault diagnosis module generates a corresponding candidate fault cause. When the standard fault symptom matches but the alarm word is missing, the fault diagnosis module generates a candidate fault cause with a missing alarm word status. When there is a conflict between the device model in the device file and the device model compatibility relationship, the fault diagnosis module records the conflict field and retains the matching search results. The candidate fault cause includes the standard fault code, standard fault symptom, candidate cause name, matching field, and matching status. The fault diagnosis module provides the candidate fault cause to the maintenance plan generation module.

[0078] The maintenance plan generation module 04, connected to the fault diagnosis module, is used to sort the candidate fault causes based on historical maintenance cases, generate diagnostic suggestions, and generate a basic diagnostic work order record based on the diagnostic suggestions and associated with maintenance plans and parts requirement records. The maintenance plan generation module receives candidate fault causes provided by the fault diagnosis module and reads historical maintenance cases based on the standard fault codes, candidate cause names, and equipment models in the candidate fault causes. The maintenance plan generation module generates a candidate cause sorting record based on fault feature matching degree, historical occurrence frequency, average maintenance time, most recent maintenance time, and equipment model adaptability, and generates diagnostic suggestions according to the candidate cause sorting record. The module reads the repair plan based on the diagnostic suggestions, which includes suggested inspection items, required tools, and parts compatibility relationships. The repair plan generation module generates a parts requirement record based on the diagnostic suggestions, the repair plan, and the parts compatibility relationships. The parts requirement record includes the parts code, required quantity, compatible equipment model, and substitute part identifier. When historical repair cases are insufficient, the repair plan generation module retains the fault feature matching degree and equipment model compatibility degree, and records the historical case insufficiency status. The repair plan generation module writes the diagnostic suggestions, the repair plan, and the parts requirement record into the diagnostic work order basic record, and provides the parts requirement record and the diagnostic work order basic record to the inventory verification module.

[0079] The inventory verification module 05, connected to the repair plan generation module, is used to query the warehouse inventory ledger based on the parts demand record, read the inventory version and lock validity period, and generate an inventory verification result. Based on the inventory verification result, it generates an inventory lock record or transfer request. The inventory verification module receives the parts demand record and diagnostic work order basic record provided by the repair plan generation module, and queries the warehouse inventory ledger based on the parts code and required quantity in the parts demand record. The inventory verification module reads the available inventory, locked quantity, inventory version, and lock validity period from the warehouse inventory ledger, and binds the available inventory, locked quantity, inventory version, and lock validity period to the parts demand record to generate inventory. Verification results: When the available inventory after deducting the locked quantity is not less than the required quantity, the inventory verification module generates an inventory lock record based on the part code, the required quantity, the inventory version, and the lock validity period; when the available inventory after deducting the locked quantity is less than the required quantity, the inventory verification module generates a transfer request based on the part code, the required quantity, and the warehouse inventory ledger; when the inventory version changes before generating the inventory lock record, the inventory verification module rereads the warehouse inventory ledger and regenerates the inventory verification result; the inventory verification module provides the inventory verification result, the inventory lock record, or the transfer request to the diagnostic work order push module.

[0080] The diagnostic work order push module 06 is connected to the inventory verification module and is used to bind the diagnostic suggestions, the repair plan, the parts demand record and the inventory processing result to the diagnostic work order and push them to the repair engineer's terminal. The diagnostic work order push module receives the inventory verification result, inventory lock record, or transfer request provided by the inventory verification module, and reads the diagnostic suggestions, repair plans, and parts requirement records from the basic record of the diagnostic work order. The diagnostic work order push module uses the inventory lock record or the transfer request as the inventory processing result and binds it to the diagnostic work order along with the diagnostic suggestions, the repair plan, and the parts requirement record. The diagnostic work order includes a work order identifier, equipment identifier, fault characteristic record reference identifier, candidate fault cause, diagnostic suggestions, repair plan, parts requirement record, inventory verification result, and inventory processing result. When the inventory processing result is an inventory lock record, the diagnostic work order push module records the lock status and lock validity period. When the inventory processing result is a transfer request, the diagnostic work order push module records the transfer status. The diagnostic work order push module pushes the diagnostic work order to the maintenance engineer terminal and records the push status. When the maintenance engineer terminal does not return a receiving status, the diagnostic work order push module records the diagnostic work order as unreceived and retains the binding relationship between the inventory processing result and the diagnostic work order.

Claims

1. A remote fault diagnosis auxiliary method for generator sets, characterized in that, include: S100: Receive the generator set's repair information and equipment identifier, read the equipment file based on the equipment identifier, and call the generator set fault dictionary to extract entities and normalize synonyms from the fault description text in the repair information to generate a fault feature record. S200. Based on the equipment model and equipment model compatibility relationship in the equipment file, standard fault codes are searched and compared, and the fault feature record is matched with the search results to generate candidate fault causes. S300. Based on historical maintenance cases, sort the candidate fault causes, generate diagnostic suggestions, and generate basic records of diagnostic work orders based on the diagnostic suggestions, which are associated with maintenance plans and parts requirement records. S400: Based on the parts demand record, query the warehouse inventory ledger, read the inventory version and lock validity period and generate an inventory verification result. Based on the inventory verification result, generate an inventory lock record or transfer request, bind the diagnostic suggestion, the repair plan, the parts demand record and the inventory processing result to the diagnostic work order, and push it to the repair engineer terminal.

2. The method according to claim 1, characterized in that, The repair information includes telephone recording transcripts or online text; when the recognition confidence of the telephone recording transcript is lower than a preset threshold, a record for the field to be confirmed is generated based on the device identifier, the fault description text, and the device file.

3. The method according to claim 1, characterized in that, The generator set fault dictionary includes fault phenomenon words, component words, operating status words, alarm words, and synonym mapping relationships; the entity extraction includes extracting the fault phenomenon words, component words, operating status words, and alarm words from the fault description text; the synonym normalization includes converting the extraction results into the fault feature records based on the synonym mapping relationships.

4. The method according to claim 1, characterized in that, The equipment file includes the equipment model, controller model, power rating, and engine type; the search and comparison of standard fault codes includes: searching in the equipment model compatibility relationship based on the equipment model, controller model, power rating, and engine type to generate fault code filtering results; and generating candidate fault causes based on the fault code filtering results and the fault feature records.

5. The method according to claim 1, characterized in that, The candidate fault causes are sorted based on historical maintenance cases, including: generating a candidate fault cause sorting record based on fault feature matching degree, historical occurrence frequency, average maintenance time, most recent maintenance time and equipment model compatibility; and selecting the diagnostic suggestions according to the candidate fault cause sorting record.

6. The method according to claim 1, characterized in that, The repair plan includes suggested inspection items, required tools and parts compatibility relationships; the parts requirement record includes parts code, required quantity, compatible equipment model and alternative part identification; the parts requirement record is generated from the diagnostic suggestions, the repair plan and the parts compatibility relationships.

7. The method according to claim 1, characterized in that, Generating an inventory verification result includes: based on the part code and required quantity in the part requirement record, reading the available inventory, locked quantity, inventory version, and lock validity period from the warehouse inventory ledger; binding the available inventory, the locked quantity, the inventory version, and the lock validity period with the part requirement record to generate the inventory verification result.

8. The method according to claim 7, characterized in that, Generating an inventory lock record or transfer request based on the inventory verification result includes: generating the inventory lock record based on the accessory code, the required quantity, the inventory version, and the lock validity period when the available inventory after deducting the locked quantity is not less than the required quantity; and generating the transfer request based on the accessory code, the required quantity, and the warehouse inventory ledger when the available inventory after deducting the locked quantity is less than the required quantity.

9. The method according to claim 1, characterized in that, Receive the actual fault cause, actual replaced parts, and actual repair time from the maintenance engineer's terminal; search and compare the actual fault cause, actual replaced parts, and actual repair time with the diagnostic work order, generate a status write-back record, and update the historical repair case based on the status write-back record.

10. A remote fault diagnosis auxiliary system for generator sets, characterized in that, include: The module includes a repair information receiving module, a fault feature record generation module, a fault diagnosis module, a repair plan generation module, an inventory verification module, and a diagnostic work order push module. The system is used to implement the method described in any one of claims 1-9.

Images