Operation and maintenance method and device for industrial vehicle, electronic equipment and medium
By recording operation logs and user information on industrial vehicles, and combining feature recognition and fault identification models, the time window is dynamically adjusted, solving the problem of low maintenance efficiency caused by relying on manual descriptions, and achieving fast and accurate fault analysis.
Patent Information
- Application Number
- CN202511172733.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-08-21
- Publication Date
- 2025-12-09
AI Technical Summary
In existing technologies, the operation and maintenance of industrial vehicles rely on the descriptions of operators, which leads to unclear anomaly judgments, omission of key issues, and low maintenance efficiency.
By recording vehicle operation logs and user-submitted anomaly information through onboard storage devices, and combining feature recognition and fault identification models, the time window is dynamically adjusted to quickly identify the location and type of fault and generate fault analysis results.
It enables rapid and accurate fault identification, improves operation and maintenance efficiency, reduces the need for on-site observation, and enhances user experience and repair efficiency.
Smart Images
Figure CN121094786A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of vehicle operation and maintenance, and in particular to a method, apparatus, electronic equipment, and medium for the operation and maintenance of industrial vehicles. Background Technology
[0002] Currently, the real-time status of industrial vehicles is usually recorded by various components (such as controllers and lithium batteries). When after-sales issues arise and technical support is needed, some electrical components cannot be remotely read or lack communication (such as lead-acid batteries). The system can only rely on the descriptions of on-site personnel, which can easily lead to unclear descriptions or omissions of key issues. This can cause technical support personnel to misjudge the cause based on the description or be unable to determine the cause, requiring on-site observation and analysis. This results in low maintenance efficiency. Summary of the Invention
[0003] This application provides a method, apparatus, electronic device, and medium for the operation and maintenance of industrial vehicles, which solves the problem in the prior art where operation and maintenance personnel rely on unclear or omitted descriptions of vehicle abnormalities by users to judge vehicle abnormalities and carry out repair work, resulting in low maintenance efficiency.
[0004] The first aspect of this application provides a method for the operation and maintenance of industrial vehicles, wherein a vehicle operation log is continuously recorded by an on-board first storage device, the operation log including CAN bus signals, sensor data and fault codes, and sliced by time. The system receives vehicle anomaly information submitted by users via mobile terminals or in-vehicle interactive interfaces, attaches the user's location and submission timestamp, and stores it in a second storage device. The vehicle operation log and vehicle anomaly information are stored on the blockchain, and the abnormal parts and types are identified through feature recognition. Based on the anomaly location and timestamp, the associated time window is located in the operation log, and the start and end times of the window are dynamically adjusted according to the anomaly type. The vehicle operation logs within the associated time window and the vehicle anomaly information after feature recognition are input into the pre-trained fault identification model and the fault analysis results are output. The fault analysis results include the vehicle operation logs within the associated time window and the on-chain address of the vehicle anomaly information. The fault analysis results are pushed through the interactive interface and synchronized to the maintenance work order system to generate pending messages.
[0005] Furthermore, the vehicle anomaly information includes at least two of the following: audio, video, images, and text descriptions regarding the abnormal location.
[0006] Furthermore, the identification of abnormal locations and types through feature recognition includes: Perform object detection on video or image data to identify abnormal areas; Perform spectral analysis on the audio data to extract characteristic frequency bands, and identify abnormal parts based on the characteristic frequency bands; Keyword extraction is performed on the text description to determine the anomaly type.
[0007] Furthermore, based on the aforementioned anomaly location and timestamp, the relevant time window is located in the operation log, including: The abnormal parts are mapped to nodes in the vehicle fault knowledge graph, and the associated nodes are obtained by forward and backward reasoning according to the vehicle fault knowledge graph. Locate the running log segment corresponding to the timestamp, and search for several running log segments with earlier timestamps starting from the current running log segment until all N running log segments with the associated node data anomalies are found; Take M1 log segments forward and M2 log segments backward from all the log segments with abnormal data from the associated nodes, and use N+M1+M2 of these log segments as the vehicle operation logs within the associated time window.
[0008] Furthermore, the start and end times of the window are dynamically adjusted according to the exception type, including: When the fault type of the knowledge graph reasoning is a mechanical fault, take M11 operation log segments forward and M21 operation log segments backward; When the fault type of the knowledge graph reasoning is an electrical fault, take M12 operation log segments forward and M22 operation log segments backward; When the fault type of the knowledge graph reasoning is a software fault, take M13 running log segments forward and M23 running log segments backward. M11 is less than M12 and less than M13, and M21 is less than M22 and less than M23.
[0009] Furthermore, the step of inputting the operation logs and processed vehicle anomaly information within the associated time window into the pre-trained fault identification model and outputting fault analysis results includes: The operation logs within the associated time window are fused with the vehicle anomaly information after feature recognition to generate a unified embedding vector. Fault identification model based on vehicle model matching; The vector is input into the fault identification model and the faulty component, cause, and handling suggestions are output to form the fault analysis result.
[0010] Furthermore, the method further includes: the first storage device is a mobile storage device, which is connected to the vehicle via an OBD interface or a CAN connector.
[0011] A second aspect of this application provides a maintenance device for industrial vehicles, comprising: The first storage module continuously records the vehicle operation log through the on-board first storage device. The operation log includes CAN bus signals, sensor data and fault codes, and is sliced by time. The user input module receives vehicle anomaly information submitted by the user via a mobile terminal or in-vehicle interactive interface, adds the user's location and submission timestamp, and stores it in a second storage device. The upload module stores the vehicle operation logs and vehicle anomaly information on the blockchain and identifies the anomaly location and anomaly type through feature recognition. The target log location module locates the associated time window in the operation log based on the abnormal location and timestamp. The start and end times of the window are dynamically adjusted according to the abnormal type. The fault analysis module inputs the vehicle operation logs within the associated time window and the vehicle anomaly information after feature recognition into the pre-trained fault recognition model and outputs the fault analysis results. The fault analysis results include the on-chain addresses of the vehicle operation logs within the associated time window and the vehicle anomaly information. The fault analysis results are pushed through the interactive interface and synchronized to the maintenance work order system to generate pending messages. A third aspect of this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, it causes the electronic device to perform the method described in the first aspect of this application.
[0012] A fourth aspect of this application provides a computer-readable storage medium for storing a computer program that, when run on a computer, causes the computer to perform the method described in the first aspect of this application.
[0013] In this embodiment of the application, an operation and maintenance method for industrial vehicles is adopted, which continuously records the vehicle operation log through an on-board first storage device. The operation log includes CAN bus signals, sensor data and fault codes, and is sliced by time. The system receives vehicle anomaly information submitted by the user via a mobile terminal or in-vehicle interface, attaches the user's location and submission timestamp, and stores it in a second storage device. The vehicle operation log and vehicle anomaly information are stored on the blockchain, and the anomaly location and type are identified through feature recognition. Based on the anomaly location and timestamp, a relevant time window is located in the operation log, and the start and end times of the window are dynamically adjusted according to the anomaly type. The vehicle operation log within the relevant time window and the feature-recognized vehicle anomaly information are input into a pre-trained fault identification model, and a fault analysis result is output. The fault analysis result includes the on-chain address of the vehicle operation log within the relevant time window and the vehicle anomaly information. The fault analysis result is pushed through the interactive interface and synchronized to the maintenance work order system to generate a pending message.
[0014] This application addresses the reliance of maintenance personnel on feedback from vehicle operators. By combining personnel feedback with vehicle logs, it uses artificial intelligence to quickly and accurately identify and push faults, making it easier for maintenance personnel to refer to AI diagnoses for subsequent maintenance. It also helps vehicle users understand the causes and solutions for reported problems, facilitating communication with maintenance personnel regarding maintenance methods. Attached Figure Description
[0015] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart of an operation and maintenance method for industrial vehicles according to an embodiment of this application.
[0016] Figure 2 This is a schematic diagram of an operation and maintenance method for industrial vehicles according to an embodiment of this application.
[0017] Figure 3 This is a schematic diagram of an electronic device according to an embodiment of this application. Detailed Implementation
[0018] 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.
[0019] 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.
[0020] like Figure 1The diagram shown is a flowchart illustrating a method for the operation and maintenance of industrial vehicles according to an embodiment of this application. Figure 1 It can be seen that the aforementioned operation and maintenance method for industrial vehicles includes the following steps: Step S101: Continuously record vehicle operation logs through the on-board first storage device. The operation logs include CAN bus signals, sensor data and fault codes, and are sliced by time.
[0021] Step S102: Receive vehicle anomaly information submitted by the user via a mobile terminal or in-vehicle interactive interface, attach the user's location and submission timestamp, and store it in a second storage device.
[0022] Step S103: Store the vehicle operation log and vehicle abnormal information on the blockchain, and identify the abnormal location and abnormal type through feature recognition.
[0023] Step S104: Based on the abnormal location and timestamp, locate the associated time window in the operation log. The start and end times of the window are dynamically adjusted according to the abnormal type.
[0024] Step S105: Input the vehicle operation log and the vehicle anomaly information after feature recognition within the associated time window into the pre-trained fault identification model and output the fault analysis result. The fault analysis result includes the on-chain address of the vehicle operation log and the vehicle anomaly information within the associated time window.
[0025] Step S106: Push the fault analysis results through the interactive interface and synchronize them to the maintenance work order system to generate pending messages. The above method utilizes data from both vehicle operation logs and personnel reports. These two types of data have different characteristics. Vehicle operation logs are more professional, timely, and continuous, while personnel reports are more easily understood and usually reflect easily detectable vehicle anomalies, but they often contain a degree of subjectivity and lag behind the actual occurrence of the anomaly. If these two types of data can be used in combination, it is possible to respond promptly to personnel reports of vehicle malfunctions without relying on them. This leads to more timely and effective fault diagnosis, which is beneficial for improving operational efficiency, extending vehicle lifespan, and enhancing the user's after-sales experience.
[0026] The on-chain storage of data from both aspects has a good anti-tampering effect. In some optional embodiments, maintenance data can also be stored on the chain. Vehicle operation logs, vehicle abnormal information and maintenance data are associated through the vehicle identification number. These data can be retrieved from the chain as vehicle operation records as needed, providing an effective data foundation for objectively evaluating maintenance services and even evaluating vehicle value in the future.
[0027] In some embodiments, in order to quickly modify existing vehicles to implement the above method, the first storage device is a portable storage device with built-in acquisition and communication programs for collecting vehicle operation logs and transmitting them externally.
[0028] In some embodiments, if the data acquisition program detects that the vehicle does not have a logging function, then a preset data acquisition and processing program is used in the first storage device to collect relevant vehicle operating data in real time. Specifically, the first storage device includes the following modules: CAN bus communication module: Used to connect to the vehicle's OBD interface or CAN bus. The device receives raw CAN frames through a CAN transceiver (such as MCP2515), and uses a preset DBC file to parse them into specific parameters (such as vehicle speed, driving status, fault information, etc.) to read vehicle speed, fault information, etc. in real time; it has a built-in configurable protocol library that supports CAN protocols of different brands of industrial vehicles (such as J1939, CANopen, etc.). Voltage monitoring module: It collects voltage changes of the vehicle power system through a high-precision analog-to-digital converter, supports multi-channel input to adapt to different voltage levels. In specific data collection, the voltage monitoring module samples the battery voltage at a fixed frequency (e.g., 10Hz) and eliminates noise through software filtering. Working time statistics module: Automatically records the vehicle's working time and standby time through the real-time clock (RTC) and vehicle ignition signal; Main control unit: Based on a microcontroller or embedded processor, responsible for data parsing, processing and storage; Storage module: It adopts removable storage media (such as SD card or USB flash drive), supports large-capacity data storage, and has data encryption function; Power management module: Supports dual modes of vehicle power supply and built-in battery, ensuring that the device can still work briefly to save data after the vehicle is turned off; Communication interface: Optional Bluetooth, WIFI or 4G module for wireless transmission.
[0029] After the above data is collected, a vehicle operation log is generated and stored in CSV format on an SD card in a timely manner for easy subsequent analysis. FRAM (ferroelectric memory) or supercapacitors are used for storage to ensure that the data is not lost in the event of a sudden power outage.
[0030] In some other preferred embodiments, the data acquisition program detects the vehicle's built-in logs and synchronizes the vehicle logs to the first storage device in real time. The connection, communication, and data storage methods between the first storage device and the vehicle are described in the above embodiments and will not be repeated here.
[0031] In some preferred embodiments, the vehicle anomaly information includes at least two of the following: audio, video, images, and text descriptions of the abnormal location.
[0032] For visually abnormal parts, video and pictures are suitable for recording. For auditory abnormal parts, audio and video are suitable for recording. The recorded content can include the vehicle itself and an explanation of the fault. If necessary, it can also be combined with text, such as recording the time, location and specific fault phenomena.
[0033] The above records can objectively record the anomalies when the fault occurs, so as to prevent the fault from being unable to be reproduced later. At the same time, it is easy to leave important information such as the location and time of the fault occurrence in the records, which is convenient for comparison with the vehicle log file later.
[0034] In some preferred embodiments, the step of identifying the abnormal location and abnormal type through feature recognition includes: Perform object detection on video or image data to identify abnormal parts. For example, if the video and images show a steering wheel oil leak, object detection can identify the abnormal part as the steering wheel. Perform spectrum analysis on the audio data to extract characteristic frequency bands, and identify abnormal parts based on the characteristic frequency bands. For example, you can identify whether the abnormal noise is from the brake pads or the engine by using the characteristic frequency bands. Keyword extraction is performed on the text description to determine the anomaly type. These anomaly types are categorized by fault mechanism into mechanical faults (e.g., bearing jamming, belt breakage), electrical faults (e.g., wiring harness aging, fuse blowing), software faults (e.g., CAN communication timeout, ECU crash), pressure faults (e.g., hydraulic hose rupture, control valve response delay), and environmental adaptation anomalies (mainly extreme environment adaptation failures, such as sudden battery performance degradation at -30℃, false alarms from high-altitude oxygen sensors). Using pre-trained natural language processing technology and vehicle maintenance domain knowledge rules, the text description content can be understood to identify the specific fault type.
[0035] In some preferred embodiments, locating the associated time window in the operation log based on the abnormal location and timestamp includes: The abnormal parts are mapped to nodes in the vehicle fault knowledge graph, and the associated nodes are obtained by forward and backward reasoning according to the vehicle fault knowledge graph. Locate the running log segment corresponding to the timestamp, and search for several running log segments with earlier timestamps starting from the current running log segment until all N running log segments with the associated node data anomalies are found; Take M1 log segments forward and M2 log segments backward from all the log segments with abnormal data from the associated nodes, and use N+M1+M2 of these log segments as the vehicle operation logs within the associated time window.
[0036] In some preferred embodiments, different fault types have different fault propagation speeds, observability, and system complexity, wherein: Mechanical failures transmit energy directly through rigid components. Abnormal signals can usually appear within milliseconds. Furthermore, mechanical failures generate transient impact signals, which are easy to detect through short-term analysis. At the same time, damage to mechanical parts may trigger chain reactions. Therefore, mechanical failures require the source of the failure to be located in the shortest possible time. For example, a damaged bearing can cause vibration energy to be transmitted from a local area to the entire transmission system within 10 seconds, and a broken belt can cause the speed of auxiliary equipment (such as a water pump) to drop to zero within 5 seconds.
[0037] Electrical faults (such as poor contact or insulation aging) often follow a gradual process. For example, increased contact resistance leads to localized heating and eventually breaks the circuit (typically taking 2-3 minutes). Furthermore, electrical faults require observation over multiple operating cycles to distinguish between transient interference and genuine faults. Additionally, vehicle electrical systems (such as dual ECU redundancy) may temporarily mask faults, necessitating an extended observation window.
[0038] Software failures (such as memory leaks and deadlocks) typically involve a gradual process from quantitative to qualitative change. For example, a memory leak can take 40-50 minutes from the first exception to a system crash. Furthermore, software behavior is influenced by multiple factors, requiring long-term observation of correlations and often necessitating the analysis of event chains (such as a function being called repeatedly, leading to a stack overflow). Therefore, long windows can provide a complete context.
[0039] For the reasons mentioned above, the start and end times of the window are dynamically adjusted according to the type of exception, including: When the fault type of the knowledge graph reasoning is a mechanical fault, take M11 operation log segments forward and M21 operation log segments backward; When the fault type of the knowledge graph reasoning is an electrical fault, take M12 operation log segments forward and M22 operation log segments backward; When the fault type of the knowledge graph reasoning is a software fault, take M13 running log segments forward and M23 running log segments backward. M11 is less than M12, which is less than M13, and M21 is less than M22, which is less than M23. In some specific embodiments, M11 and M21 are 30 seconds, M12 and M21 are 5 minutes, and M13 and M23 are 1 hour.
[0040] Similarly, based on the types of hydraulic faults and environmental adaptation faults, the M1 and M2 times corresponding to hydraulic faults are 2 min to 5 min, while the M1 and M2 times corresponding to environmental adaptation faults are 10 min to 1 h.
[0041] In some preferred embodiments, the step of inputting the operation log and processed vehicle anomaly information within the associated time window into a pre-trained fault identification model and outputting fault analysis results includes: The operation logs within the associated time window are fused with the vehicle anomaly information after feature recognition to generate a unified embedding vector. Fault identification model based on vehicle model matching; The vector is input into the fault identification model and the faulty component, cause, and handling suggestions are output to form the fault analysis result.
[0042] Based on the same inventive concept as the above-described method embodiments, this application also provides a maintenance device for industrial vehicles, comprising: The first storage module continuously records the vehicle operation log through the on-board first storage device. The operation log includes CAN bus signals, sensor data and fault codes, and is sliced by time. The user input module receives vehicle anomaly information submitted by the user via a mobile terminal or in-vehicle interactive interface, adds the user's location and submission timestamp, and stores it in a second storage device. The upload module stores the vehicle operation logs and vehicle anomaly information on the blockchain and identifies the anomaly location and anomaly type through feature recognition. The target log location module locates the associated time window in the operation log based on the abnormal location and timestamp. The start and end times of the window are dynamically adjusted according to the abnormal type. The fault analysis module inputs the vehicle operation logs within the associated time window and the vehicle anomaly information after feature recognition into the pre-trained fault recognition model and outputs the fault analysis results. The fault analysis results include the on-chain addresses of the vehicle operation logs within the associated time window and the vehicle anomaly information. The fault analysis results are pushed through the interactive interface and synchronized to the maintenance work order system to generate pending messages. It should be noted that although several units or sub-units of the device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided and embodied by multiple units. Based on the same inventive concept as the above method embodiments, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it enables the electronic device to implement the control method described in the above embodiments.
[0043] In one embodiment, the electronic device may be a server, and in this embodiment, the structure of the electronic device may be as follows: Figure 3 As shown, it includes a memory 2001, a communication module 2003, and one or more processors 2002. The memory 2001 is used to store computer programs executed by the processor 2002. The memory 2001 may mainly include a program storage area and a data storage area. The program storage area may store the operating system and programs required to run instant messaging functions, etc.; the data storage area may store various instant messaging information and operation instruction sets, etc. Memory 2001 may be volatile memory, such as random-access memory (RAM); memory 2001 may also be non-volatile memory, such as read-only memory, flash memory, hard disk drive (HDD), or solid-state drive (SSD); or memory 2001 may be any other medium capable of carrying or storing a desired computer program having the form of instructions or data structures and accessible by a computer, but is not limited thereto. Memory 2001 may be a combination of the above-mentioned memories. Processor 2002 may include one or more central processing units (CPUs) or digital processing units, etc. Processor 2002 is used to implement the above-mentioned audio data processing method when calling computer programs stored in memory 2001. The communication module 2003 is used to communicate with terminal devices and other servers. This application embodiment does not limit the specific connection medium between the memory 2001, communication module 2003, and processor 2002. This application embodiment... Figure 3 The memory 2001 and the processor 2002 are connected via a bus 2004, which is in... Figure 3 The connections between other components are illustrated with arrows and are for illustrative purposes only, not as limiting information. The Bus 2004 can be divided into address bus, data bus, control bus, etc. For ease of description, Figure 3The text uses only one arrow to describe it, but does not indicate that there is only one bus or one type of bus. Based on the same inventive concept as the above-described method embodiments, embodiments of the present invention also provide a computer-readable storage medium for storing a computer program. When the computer program is run on a computer, it enables the electronic device to implement the control method described in the above embodiments. The computer-readable storage medium can be a readable signal medium or a readable storage medium. A readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. Based on the same inventive concept as the above-described method embodiments, embodiments of the present invention also provide a computer program product, which includes a computer program that, when run on an electronic device, causes the electronic device to perform the steps of the control methods described above according to various exemplary embodiments of this application. The program product may take the form of any combination of one or more readable media. These computer program commands can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to produce a machine, such that the commands executed by the processor of the computer or other programmable data processing device generate a process for implementing... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes. Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.
Claims
1. A method for the operation and maintenance of industrial vehicles, characterized in that, The vehicle operation log is continuously recorded by the on-board first storage device. The operation log includes CAN bus signals, sensor data and fault codes, and is sliced by time. The system receives vehicle anomaly information submitted by users via mobile terminals or in-vehicle interactive interfaces, attaches the user's location and submission timestamp, and stores it in a second storage device. The vehicle operation log and vehicle anomaly information are stored on the blockchain, and the abnormal parts and types are identified through feature recognition. Based on the anomaly location and timestamp, the associated time window is located in the operation log, and the start and end times of the associated time window are dynamically adjusted according to the anomaly type. The vehicle operation logs within the associated time window and the vehicle anomaly information after feature recognition are input into the pre-trained fault identification model and the fault analysis results are output. The fault analysis results include the vehicle operation logs within the associated time window and the on-chain address of the vehicle anomaly information. The fault analysis results are pushed through the interactive interface and synchronized to the maintenance work order system to generate pending messages.
2. The method according to claim 1, characterized in that, The vehicle anomaly information includes at least two of the following: audio, video, images, and text descriptions of the abnormal location.
3. The method according to claim 2, characterized in that, The identification of abnormal locations and types through feature recognition includes: Perform object detection on video or image data to identify abnormal areas; Perform spectral analysis on the audio data to extract characteristic frequency bands, and identify abnormal parts based on the characteristic frequency bands; Keyword extraction is performed on the text description to determine the anomaly type.
4. The method according to claim 1, characterized in that, Based on the aforementioned anomaly location and timestamp, locate the associated time window in the operation log, including: The abnormal parts are mapped to nodes in the vehicle fault knowledge graph, and the associated nodes are obtained by forward and backward reasoning according to the vehicle fault knowledge graph. Locate the running log segment corresponding to the timestamp, and search for several running log segments with earlier timestamps starting from the current running log segment until all N running log segments with the associated node data anomalies are found; Take M1 log segments forward and M2 log segments backward from all the log segments with abnormal data from the associated nodes, and use N+M1+M2 of these log segments as the vehicle operation logs within the associated time window.
5. The method according to claim 4, characterized in that, The start and end times of the window are dynamically adjusted according to the exception type, including: When the fault type of the knowledge graph reasoning is a mechanical fault, take M11 operation log segments forward and M21 operation log segments backward; When the fault type of the knowledge graph reasoning is an electrical fault, take M12 operation log segments forward and M22 operation log segments backward; When the fault type of the knowledge graph reasoning is a software fault, take M13 running log segments forward and M23 running log segments backward. M11 is less than M12 and less than M13, and M21 is less than M22 and less than M23.
6. The method according to claim 1, characterized in that, The step of inputting the operation logs within the associated time window and the vehicle anomaly information after feature recognition into the pre-trained fault identification model and outputting the fault analysis results includes: The operation logs within the associated time window are fused with the vehicle anomaly information after feature recognition to generate a unified embedding vector. Fault identification model based on vehicle model matching; The vector is input into the fault identification model and the faulty component, cause, and handling suggestions are output to form the fault analysis result.
7. The method according to claim 1, characterized in that, The method further includes: the first storage device is a mobile storage device, which is connected to the vehicle via an OBD interface or a CAN connector.
8. A maintenance device for industrial vehicles, characterized in that, include: The first storage module continuously records the vehicle operation log through the on-board first storage device. The operation log includes CAN bus signals, sensor data and fault codes, and is sliced by time. The user input module receives vehicle anomaly information submitted by the user via a mobile terminal or in-vehicle interactive interface, adds the user's location and submission timestamp, and stores it in a second storage device. The upload module stores the vehicle operation logs and vehicle anomaly information on the blockchain and identifies the anomaly location and type through feature recognition. The target log location module locates the associated time window in the operation log based on the abnormal location and timestamp. The start and end times of the window are dynamically adjusted according to the abnormal type. The fault analysis module inputs the vehicle operation logs within the associated time window and the vehicle anomaly information after feature recognition into the pre-trained fault recognition model and outputs the fault analysis results. The fault analysis results include the on-chain addresses of the vehicle operation logs within the associated time window and the vehicle anomaly information. The fault analysis results are pushed through the interactive interface and synchronized to the maintenance work order system to generate pending messages.
9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it causes the electronic device to implement the method as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program that, when run on a computer, causes the computer to perform the method as described in any one of claims 1 to 7.