Port gantry crane maintenance method based on large-model multi-intelligence framework

Abstract

The invention relates to a port gantry crane maintenance method based on a large model multi-intelligent framework. The method comprises the following steps: acquiring a task request of a user; the task request is decomposed based on a preset large language model, a service workflow for equipment maintenance is generated, and executable sub-modules of the service workflow comprise an equipment state monitoring module, a fault diagnosis processing module and an equipment life prediction module; and for the executable submodule of the service workflow, calling a corresponding model, and taking an output result of the preset large language model based on the executable submodule as a context to generate response content. According to the invention, the large language model is introduced as a core decision engine, and the intelligent maintenance of the port gantry crane is realized in combination with a multi-intelligent architecture.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and particularly to a maintenance method for port portal cranes based on a large model multi-agent framework. Background Art

[0002] Existing mainstream frameworks (such as MetaGPT, Langchain-chatchat, Dify, etc.) generally have four core defects: First, the technical maturity is insufficient, manifested as poor framework compatibility, low running stability, and weak agent fault tolerance, and it is easy to cause downtime due to task load fluctuations; Second, the functional limitations are prominent, with single agent types and rigid cooperation mechanisms, making it difficult to support cross-modal tasks and dynamic decision-making; Third, the development and application thresholds are high, with imperfect secondary development interfaces, lack of debugging tools, and lack of adaptability to edge devices such as mobile terminals; Fourth, the industry adaptability is lacking, and general frameworks are difficult to meet the strict requirements of vertical fields for embedding specialized knowledge, coupling business processes, and security compliance.

[0003] In the context of the intelligent upgrade of the port industry, the above problems are particularly prominent. Port scenarios involve high-complexity tasks such as port machinery equipment monitoring and fault diagnosis, cargo scheduling, equipment cooperation, and safety monitoring, and a customized multi-agent framework with the capabilities of industry knowledge graph integration, real-time processing of multi-source heterogeneous data, and edge-cloud collaborative computing needs to be constructed. However, existing frameworks cannot be compatible with port-specific systems (such as the TOS terminal operating system), lack support for parsing heavy equipment IoT protocols, and are difficult to meet the requirements of low-latency and high-concurrency production environments, seriously hindering the large-scale implementation of typical applications such as intelligent inspection and automated scheduling, especially the maintenance applied to portal cranes.

[0004] Traditional methods for fault diagnosis of portal cranes rely on threshold alarms, and for equipment life prediction, they rely on simple statistical models, such as linear prediction based on running time or the number of operations, while ignoring the influence of actual working conditions. Life prediction requires the integration of multi-dimensional data, but existing systems may have deficiencies in data integration, resulting in prediction deviations. Summary of the Invention

[0005] The embodiments of this application provide a maintenance method for port portal cranes based on a large model multi-agent framework, integrating technologies such as large models, AI small models, information systems, private knowledge bases, and agents, and applying them to improve the operation efficiency and reliability of port equipment.

[0006] To achieve the above object, this application discloses a maintenance method for port portal cranes based on a large model multi-agent framework, including:

[0007] Obtain the task request of the user;

[0008] Decompose the task request based on a preset large language model to generate a service workflow for equipment maintenance. The executable sub - modules of the service workflow include: an equipment status monitoring module, a fault diagnosis and processing module, and an equipment life prediction module;

[0009] For the executable sub - modules of the service workflow, call the corresponding models, including:

[0010] The equipment status monitoring module calls an equipment status monitoring agent to obtain the working status data of the portal crane for anomaly identification or receives the warning information from the control system of the portal crane.

[0011] The fault diagnosis and processing module calls a private knowledge base for equipment fault diagnosis based on the fault type and cause of the portal crane and outputs the corresponding maintenance plan.

[0012] The equipment life prediction module calls an equipment life prediction agent to analyze the working status data and return the predicted life value;

[0013] The preset large language model generates response content based on the output results of the executable sub - modules as context.

[0014] In some embodiments, the equipment status monitoring agent is obtained by encapsulating an equipment status monitoring system and the warning interface of the control system of the portal crane. The equipment status monitoring agent is connected to the preset large language model. When the equipment status monitoring system identifies abnormal information or the control system feeds back warning information, it automatically sends the abnormal information or warning information to the preset large language model.

[0015] In some embodiments, the equipment status monitoring system includes:

[0016] Vibration sensors, used to collect vibration data of key parts of the portal crane;

[0017] Camera devices, used to collect the operating status and appearance of the portal crane to judge its health status, such as whether there is rust.

[0018] In some embodiments, the portal crane includes, but is not limited to, a slewing mechanism, a hoisting mechanism, and a traveling mechanism. The key parts include: the outer shaft of the slewing bearing and the input and output shafts of the reducer of the slewing mechanism, the drum bearing seat and the base of the wire rope pulley group of the hoisting mechanism, and the track contact surface and the drive shaft of the traveling wheel group of the traveling mechanism.

[0019] In some embodiments, the fault diagnosis and processing module is configured to:

[0020] Construct a private knowledge base for equipment fault diagnosis and integrate it into a preset large language model using the RAG technology to accurately answer operation and maintenance questions based on semantics;

[0021] The preset large language model obtains the fault types and causes of a portal crane, and calls the private knowledge base for equipment fault diagnosis based on the fault types and causes to output corresponding maintenance solutions.

[0022] In some embodiments, the construction of the private knowledge base for equipment fault diagnosis includes:

[0023] Integrate the operation manuals, fault cases, maintenance manuals, and expert experience of the portal crane, convert them into Markdown format through data cleaning, transform the text into high-dimensional vectors through a vectorization model, and store them in a vector database to obtain the private knowledge base for equipment fault diagnosis.

[0024] In some embodiments, the private knowledge base for equipment faults uses the obtained fault types and causes as retrieval vectors, calculates and returns the Top K candidate results based on the cosine similarity in the vectorization database, then uses a first-level sorting model to re-score the candidate results, filters out low-correlation data based on a Score threshold, generates a final sorted list for the preset large language model, and the preset large language model outputs highly readable maintenance suggestions. This solution can be automatically identified or assisted by on-site operation and maintenance personnel to ensure the accuracy and controllability of diagnosis.

[0025] In some embodiments, the equipment life prediction agent is obtained by encapsulating an equipment life prediction model. The equipment life prediction agent is connected to the preset large language model. The equipment life prediction model is pre-trained based on the historical vibration data of the key parts of the portal crane and performs data analysis based on real-time vibration data to output the predicted life value, realizing the dynamic assessment of the life of the key parts of the portal crane.

[0026] In some embodiments, the equipment life prediction model uses an LSTM-Transformer hybrid model.

[0027] In some embodiments, the service workflow is orchestrated using the process management tool Camunda, and logic units and execution units are respectively set in the equipment status monitoring module, fault diagnosis and processing module, and equipment life prediction module.

[0028] In some embodiments, the initialization Loguru library is loaded in the main function codes of the service workflow, the preset large language model, the equipment status monitoring module, the fault diagnosis and processing module, and the equipment life prediction module, and the log level is set to achieve efficient log management and debugging monitoring for the entire process of the port portal crane maintenance method.

[0029] Specifically, the Loguru version (≥0.7.0) is forcibly specified through requirements.txt to avoid compatibility issues. The log instance is initialized using a context manager to ensure that child processes inherit the main process log configuration. The configuration center (such as Consul) is integrated to achieve dynamic synchronization of cross-node log parameters.

[0030] Details of one or more embodiments of this application are presented in the following drawings and description to make other features, objectives, and advantages of this application more concise and understandable. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] The drawings described herein are used to provide a further understanding of this application and constitute a part of this application. The illustrative embodiments of this application and their descriptions are used to explain this application and do not constitute an improper limitation of this application. In the drawings:

[0032] Figure 1 is a schematic flow chart of a port portal crane maintenance method according to an embodiment of this application;

[0033] Figure 2 is a schematic structural diagram of an executable sub-module according to an embodiment of this application;

[0034] Figure 3 is a schematic structural diagram of a device status monitoring system according to an embodiment of this application;

[0035] Figure 4 is a schematic flow chart of the construction of a device fault diagnosis private knowledge base according to an embodiment of this application.

[0036] In the figure:

[0037] 1. Device status monitoring module; 2. Fault diagnosis and processing module; 3. Device life prediction module;

[0038] 11. Device status monitoring agent. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0039] In order to make the objectives, technical solutions, and advantages of this application clearer, the following describes and explains this application with reference to the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not used to limit this application. Based on the embodiments provided in this application, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of this application.

[0040] Obviously, the accompanying drawings in the following description are only some examples or embodiments of the present application. For those of ordinary skill in the art, without creative efforts, the present application can also be applied to other similar scenarios based on these drawings. In addition, it can also be understood that although the efforts made in such a development process may be complex and lengthy, for those of ordinary skill in the art related to the content disclosed in the present application, some design, manufacturing, or production changes based on the technical content disclosed in the present application are only conventional technical means and should not be understood as the content disclosed in the present application being insufficient.

[0041] When the term "embodiment" is mentioned in the present application, it means that the specific features, structures, or characteristics described in connection with the embodiment can be included in at least one embodiment of the present application. The appearance of this phrase at various positions in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. Those of ordinary skill in the art explicitly and implicitly understand that the embodiments described in the present application can be combined with other embodiments without conflict.

[0042] Unless otherwise defined, the technical terms or scientific terms involved in the present application should have the ordinary meaning understood by those with ordinary skills in the technical field to which the present application belongs. The words such as "a", "an", "one kind", "the" and the like involved in the present application do not represent a quantity limitation and can represent a single or plural number. The terms "including", "comprising", "having" and any variations thereof involved in the present application are intended to cover non-exclusive inclusion; for example, a process, method, system, product or device including a series of steps or modules (units) is not limited to the listed steps or units, but may further include unlisted steps or units, or may further include other steps or units inherent to these processes, methods, products or devices. The terms "connected", "coupled" and the like involved in the present application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. The term "plurality" involved in the present application refers to two or more. "And / or" describes the association relationship of associated objects and indicates that three relationships may exist. For example, "A and / or B" may represent: A exists alone, A and B exist simultaneously, and B exists alone. The character " / " generally represents an "or" relationship between the front and rear associated objects. The terms "first", "second", "third", etc. involved in the present application are only used to distinguish similar objects and do not represent a specific order for the objects.

[0043] Portal cranes mostly run along the crane tracks on the ground or on buildings for lifting and loading / unloading operations. One side of its running track is set on the ground, and the other side is set on a building higher than the ground.

[0044] This embodiment provides a maintenance method for a portal crane in a port based on a large model multi-agent framework. Figure 1 It is a flowchart of the maintenance method for a portal crane in a port based on a large model multi-agent framework according to an embodiment of the present application. As Figure 1 shown, the process includes the following steps:

[0045] S1: Obtain the task request of the user;

[0046] S2: Decompose the task request based on a preset large language model to generate a service workflow for equipment maintenance. The executable sub-modules of the service workflow include: an equipment status monitoring module, a fault diagnosis and processing module, and an equipment life prediction module; the task request includes a task description and task requirements. An example is as follows: Whether preventive maintenance is required for the portal crane.

[0047] S3: For the executable sub-modules of the service workflow, call the corresponding models, including:

[0048] The equipment status monitoring module calls an equipment status monitoring agent to obtain the working status data of the portal crane for anomaly identification or receive the early warning information from the control system of the portal crane.

[0049] The fault diagnosis and processing module calls a private knowledge base for equipment fault diagnosis based on the fault type and cause of the portal crane, and outputs the corresponding maintenance plan to assist maintenance personnel in the maintenance work of the operating equipment.

[0050] The equipment life prediction module calls an equipment life prediction agent to analyze the working status data and return the predicted life value;

[0051] The preset large language model generates response content based on the output results of the executable sub-modules. In the above embodiment, the preset large language model is Qwen2-72B, and the inference engine is configured as Ollama. Qwen2-72B runs based on the Ollama inference engine.

[0052] An example of step S2 is as follows:

[0053] Suppose the user inputs a task request: There is an obvious abnormal noise when the trolley of the portal crane moves. Is emergency repair required?

[0054] Use Qwen2-72B for entity recognition (extract key entities such as "trolley traveling mechanism" and "abnormal noise")

[0055] Intent classification (map to the composite intent of "fault diagnosis" + "status assessment")

[0056] Output a structured task description:

[0057]

[0058] In this embodiment, the large language model Qwen2-72B is introduced as the core decision-making engine, and combined with a multi-agent architecture to achieve intelligent maintenance of portal cranes in ports. When a user submits a task request, the system inputs this request into the large language model configured with the Ollama inference engine for semantic understanding and task decomposition, forming a maintenance service workflow containing multiple executable sub-modules. The device status monitoring module, through the connected status monitoring agents, real-time collects the working status data of the portal crane such as vibration, temperature, and current, or obtains the abnormal warning information sent by its control system, for identifying potential faults. The fault diagnosis and processing module, based on the device historical data and the fault private knowledge base, identifies the current fault type and possible causes, and then outputs repair suggestions. The device life prediction module calls the device life prediction agent, and uses the obtained operating status data to predict the remaining service life of the key components of the portal crane. The results of each sub-module will be fed back to the large language model, which will summarize and integrate the context, and output a readable comprehensive response.

[0059] In the above embodiment, the large language model Qwen2-72B can be replaced by other open-source models with a parameter quantity of not less than 65B, such as LLaMA-3-70B or BLOOMZ, etc., and the inference engine can also be deployed and optimized using frameworks such as DeepSpeed or vLLM.

[0060] In some of these embodiments, the device status monitoring agent is obtained by encapsulating the warning interfaces of a device status monitoring system and the control system of the portal crane. The device status monitoring agent is connected to the preset large language model. When the device status monitoring system identifies abnormal information or the control system feeds back warning information, it automatically sends the abnormal information or warning information to the preset large language model.

[0061] The service interface after encapsulating the device status monitoring agent of the above embodiment is configured with: server address, port address, project name, interface name. Locate the interface service based on its warning information parsing string. The string includes an abnormal identifier. When the abnormal identifier is 1, it indicates that the device is abnormal; when the abnormal identifier is 0, it indicates that the device is operating normally.

[0062] In some of these embodiments, the device status monitoring system 11 includes those disposed on the portal crane:

[0063] Vibration sensors, used to collect the vibration data of key parts of the portal crane;

[0064] Camera devices, used to collect the operating status and appearance of the portal crane to judge its health status, such as whether there is rust.

[0065] In some of these embodiments, the portal crane includes, but is not limited to, a slewing mechanism, a hoisting mechanism, and a traveling mechanism. The key parts include: the outer shaft of the slewing bearing of the slewing mechanism and the input shaft and output shaft of the speed reducer, the drum bearing seat of the hoisting mechanism, the base of the wire rope pulley block, and the track contact surface and the drive shaft of the traveling wheel set of the traveling mechanism.

[0066] In the above embodiments, by integrating the equipment status monitoring system at the key parts of the portal crane, the linkage acquisition of status data and the warning signal of the control system is realized. The equipment status monitoring agent is constructed through the encapsulated equipment status monitoring system and the warning interface of the control system, and is connected to the preset large language model as an independent module to participate in the task process management. When the equipment status monitoring system identifies data anomalies such as over-limit vibration and abnormal image information, or the control system returns a warning message of abnormal equipment operation, the system immediately packages this information and synchronously transmits it to the large language model for further processing, analysis, or triggering subsequent diagnosis and maintenance work. The equipment status monitoring system is mainly composed of two types of sensing components: one type is vibration sensors installed at key mechanical parts (such as the outer shaft of the slewing bearing, the speed reducer shaft, the drum bearing seat, etc.) for capturing high-frequency change data; the other type is camera devices deployed at key positions for real-time image acquisition and appearance detection, such as identifying anomalies like rust, cracks, or coating peeling. After the multi-dimensional data is fused, it can comprehensively characterize the equipment status and achieve early fault warning.

[0067] This embodiment improves the automatic status perception ability of the port portal crane. Through the integrated design of the equipment status monitoring agent, it can seamlessly connect vibration, image information, and the warning data of the control system, realizing unified data management and efficient upload. The deep integration of the agent and the large language model supports the model to quickly identify and reason about abnormal signals, shortening the response cycle and reducing the probability of missed detection. The deployment of multi-source sensors enhances the accuracy and breadth of status perception, helping to identify the risks of equipment fatigue, wear, or failure at an early stage, and improving the timeliness and effectiveness of preventive maintenance. The system structure is modular, facilitating subsequent expansion and maintenance, and having good engineering feasibility and deployment flexibility.

[0068] In the above embodiments, the vibration sensor can be a piezoelectric, MEMS, or fiber optic vibration sensor, and the type is selected according to the vibration frequency range of the installation site; the imaging device can be an industrial camera with night vision and anti-interference functions, and image processing can be supplemented with an edge computing module to achieve local preliminary recognition. The equipment status monitoring system can also be extended with temperature sensors, pressure sensors, or oil analysis modules to enhance the dimension of status perception. The position of the imaging device can be flexibly configured in high-frequency failure areas or maintenance blind spots. The equipment status monitoring agent can be composed of edge computing nodes or integrated embedded devices, and wired or wireless communication methods, such as Ethernet, 5G, or LoRa, are selected according to the deployment scenario for data upload. The warning interface can use industrial communication protocols such as OPC UA and Modbus TCP to support compatibility with the control systems of different brands of portal cranes.

[0069] In some of the embodiments, the fault diagnosis and processing module is configured to:

[0070] Construct a private knowledge base for equipment fault diagnosis and integrate it into a preset large language model using the RAG technology to accurately answer operation and maintenance questions based on semantics; when the task request includes questions such as "What is the fault of the portal crane? How is it caused? How to solve the XX fault?", the large model will give answers according to the content of the knowledge base.

[0071] After receiving the abnormal information or warning information, the preset large language model starts the fault cause diagnosis, obtains the fault type and cause of the portal crane, and calls the private knowledge base for equipment fault diagnosis based on the fault type and cause to output the corresponding maintenance plan; the fault cause diagnosis work can be to notify the operation and maintenance personnel to conduct on-site fault investigation based on the abnormal information and warning information, or when the portal crane monitoring system or control system triggers abnormal information, the large language model starts the fault diagnosis process, identifies the equipment type, abnormal phenomenon, and infers the possible fault type and cause, and the identification results are confirmed by the operation and maintenance personnel.

[0072] In some of the embodiments, the constructing of the private knowledge base for equipment fault diagnosis includes:

[0073] Integrate unstructured data such as the operation manual, fault cases, maintenance manual, and expert experience of the portal crane, convert it to Markdown format through data cleaning, convert the text into high-dimensional vectors through a vectorization model, and store it in a vector database to obtain the private knowledge base for equipment fault diagnosis.

[0074] Among the above unstructured data, it at least includes the following content: fault type, characteristic frequency, and maintenance plan. Taking the bearing outer ring spalling as an example of the fault type, its characteristic frequency is 72.3Hz ± 5%, and its corresponding maintenance plan is: replace the bearing SKF 22318, which requires 16 man-hours. The above example is only for understanding the composition of the knowledge base and is not limited thereto.

[0075] In some of these embodiments, the private knowledge base of equipment faults calculates and returns the Top K candidate results based on the cosine similarity of the obtained fault type and fault cause as retrieval vectors in the vectorized database, and then uses a first-level ranking model to re-score the candidate results. Based on a Score threshold, low-correlation data is filtered to generate a final sorted list for the preset large language model, and the preset large language model outputs a highly readable maintenance plan. This solution can be automatically recognized or assisted by on-site operation and maintenance personnel to ensure the accuracy and controllability of diagnosis. For example but not limited to, when receiving "abnormal vibration during the operation of the hoisting mechanism, with occasional metal friction sounds", it is matched in the private knowledge base of equipment faults, and a case such as "the cage of the high-speed shaft bearing is broken" is matched, with a similarity of 89%. Then, the maintenance plan is output: immediately stop the machine and replace the input shaft bearing, which requires hoisting equipment cooperation, and the estimated time-consuming is 6 hours.

[0076] This embodiment significantly improves the intelligent level and response speed of port equipment fault diagnosis. The RAG mechanism enables the large language model to have the ability to dynamically obtain professional knowledge, avoids its "hallucination" problem, and ensures the accuracy and professionalism of the reply. Through the construction of the private knowledge base of equipment faults, all common fault scenarios of portal cranes can be covered, improving the coverage rate of diagnosis and the pertinence of the plan. The vectorized retrieval combined with the re-ranking mechanism ensures high recall and high precision, enhancing the adaptability of the system in complex and diverse fault backgrounds. This system also has good maintainability, supports the continuous update and expansion of the knowledge base, and is convenient for combining the latest maintenance experience and equipment model differences.

[0077] In some of these embodiments, the fusion weight is also configured to adjust the fusion ratio of text retrieval and other features (such as equipment type, fault code) to optimize the relevance of the retrieval results.

[0078] In the above embodiments, the vectorization model uses bge-m3 to map the text into 768-dimensional vectors, capture semantic similarity, and support cross-modal retrieval, such as matching fault descriptions with historical cases. The vectorized database uses Chroma, the re-ranking model uses bge-m3-reranker, the fusion weight configuration is 0.3, the Top K configuration is 10, and the Score threshold configuration is 0.5.

[0079] In some of these embodiments, the device life prediction agent is obtained by encapsulating a device life prediction model. The device life prediction agent accesses the preset large language model. The device life prediction model is pre-trained based on the historical vibration data of the key parts of the portal crane and performs data analysis based on the real-time vibration data to output the predicted life value, realizing the dynamic assessment of the life of the key parts of the portal crane.

[0080] In another embodiment, the device life prediction model can also predict the fault type and fault time based on the vibration data. For example, based on the vibration spectrogram of the vibration data collected in the working state data combined with the maintenance record text, the CLIP model is used for cross-modal matching. The CLIP model is a multi-modal pre-trained neural network that is pre-trained using a large amount of paired image and text data to learn the alignment relationship between images and texts. In this embodiment, the vibration spectrograms of the healthy state, fault state, and different fault types are trained with the corresponding fault cases, maintenance manuals, and text of expert experience, so that the vibration data and text data can be directly matched.

[0081] In the above embodiments, the device life prediction model is encapsulated as a REST service using the FastAPI encapsulation method. The preset large language model dynamically calls this service through the MCP protocol, inputs the working state data, and outputs the service life, predicted fault type, and predicted fault time.

[0082] The service interface after encapsulating the device life prediction agent in the above embodiments is configured with: server address, port address, project name, and interface name. The preset large language model obtains the information fed back by the interface data in real time and performs fault prevention and maintenance on the working equipment based on its predicted service life, predicted fault type, and predicted fault time.

[0083] In some of these embodiments, the equipment life prediction model adopts an LSTM-Transformer hybrid model, combines the advantages of both in time series modeling, and performs high-precision modeling and prediction on the equipment operation data. In the training stage of the model, the historical vibration data of the key parts (such as the reducer shaft, drum bearing, track contact surface, etc.) of the slewing mechanism, hoisting mechanism and traveling mechanism of the portal crane are used as training samples. Feature sequences are extracted through a sliding window method, and a decay coefficient is introduced or positional encoding is used to enhance the global perception ability of the time series. Specifically, in the feature engineering stage, to capture the long-term and short-term change trends in the time series, a sliding window mechanism is adopted to divide the continuous vibration data sequence. The sliding window length (such as 128, 256 or 512 time steps) and the step size (such as 1 or 2 sampling points) are set according to the data sampling frequency and the fault evolution speed, so as to extract the state change features within a continuous time period. The data within each window is normalized before training to ensure that the model is insensitive to amplitude changes and enhance the generalization ability. To improve the model's perception ability of different time points in the sequence, a positional encoding mechanism (Positional Encoding) is introduced. Among them, for the Transformer part, a sine-cosine encoding scheme is adopted, and a unique position vector is introduced for each time step, so that the model can still learn the time dependence relationship without a cyclic structure; for the LSTM part, a time decay factor is introduced in the input layer to simulate the forgetting effect of information, so that the model pays more attention to the impact of the recent state on the current life.

[0084] After the model is deployed, the equipment life prediction agent receives the sensor vibration data from the equipment status monitoring module in real time, inputs it into the trained model for inference calculation, and outputs prediction results including the remaining useful life (RUL) estimate, degradation trend, confidence interval, etc. The above results are synchronously fed back to the large language model for task response generation or decision support, and can trigger subsequent maintenance warnings or task rearrangement.

[0085] By introducing the LSTM-Transformer hybrid architecture, it not only ensures the sensitive response of the model to short-term fluctuations, but also improves the modeling ability for long-term trend changes. Life prediction no longer depends on static rules or manual experience judgment, but is based on the equipment's own operation data, and the prediction results are more personalized and adaptable.

[0086] In some of these embodiments, the service workflow is orchestrated using the process management tool Camunda. Logic units and execution units are respectively provided in the device status monitoring module, the fault diagnosis and processing module, and the device life prediction module. The logic unit is responsible for controlling the business logic of the workflow, and the execution unit is used to execute specific steps. The logic unit for the business logic of the workflow includes: start, end, reply, conditional branch, iteration, question classification, etc. For example, in the device status monitoring stage, if the monitored data exceeds the set threshold, the logic unit triggers a conditional branch to jump to the "abnormal diagnosis" path; if it is normal, the process can end or return to the waiting state. The execution unit is used to execute specific processing actions, such as data acquisition call, model inference execution, knowledge base retrieval, prediction value output, etc. Each execution unit can be docked with external interfaces (such as device status monitoring agents, device fault privatized knowledge bases, device life prediction agents, etc.) to achieve the automation of actions and the return of results, and the execution status is fed back to the logic unit to judge the next task node.

[0087] This embodiment effectively realizes the standardization, automation, and visualization of the equipment maintenance process. Using Camunda as the core of process control enables the system to have the ability of flexible process configuration, and can quickly orchestrate or adjust each task node according to different operation and maintenance requirements. The architecture with the separation of the logic unit and the execution unit enhances the modular design and responsibility decoupling of the system, improving maintainability and scalability. The logic unit centrally manages the process path, and the execution unit focuses on execution efficiency, which can improve the overall system operation performance and the response speed of fault handling. Through the process monitoring function supported by Camunda, the traceability of the process execution status and the positioning of abnormal nodes can also be realized, which is beneficial to system operation and maintenance management and continuous optimization.

[0088] In another embodiment, the present application designs test cases for performance testing in view of the hallucination and instruction non-compliance problems that are prone to occur in large language models. For the problem of instruction non-compliance, an answer relevance test is carried out: test cases are formulated to measure whether the model output can accurately and comprehensively respond to the input information, and whether there is a situation of answering the wrong question or answering off-topic. For the hallucination problem, test cases are designed: to detect whether the LLM generates false or inaccurate information and whether it will generate content that does not conform to known facts.

[0089] In some of these embodiments, the initialization Loguru library is loaded in the main function codes of the service workflow, the preset large language model, the device status monitoring module, the fault diagnosis and processing module, and the device life prediction module, and the log level is set to achieve efficient log management and debugging monitoring for the entire process of the port portal crane maintenance method.

[0090] Specifically, the Loguru version (≥0.7.0) is forcibly specified through requirements.txt to avoid compatibility issues, and the context manager is used to initialize the log instance to ensure that child processes inherit the main process log configuration. The configuration center (such as Consul) is integrated to achieve dynamic synchronization of cross-node log parameters.

[0091] In the above embodiments, the log levels are set to include 7 levels, namely CRITICAL, ERROR, WARNING, INFO, DEBUG, TRACE, and NOTSET. Among them, CRITICAL represents a quantified log importance value of 50, indicating the most serious error, usually used when the program cannot continue to run; ERROR represents a quantified log importance value of 40, indicating a runtime error. The program can continue to run, but some functions may be affected. However, it should be noted that when ERROR-level logs continuously appear, the alarm rule is triggered; WARNING represents a quantified log importance value of 30, indicating a warning message, hinting at potential problems, but not affecting the normal operation of the program; INFO represents a quantified log importance value of 20, indicating general information, used to record the normal operation status of the program; DEBUG represents a quantified log importance value of 10, indicating debug information, used in the development and debugging stages to record detailed program operation information. The runtime level hot switch is implemented through the environment variable LOG_LEVEL, and the DEBUG mode is supported to start and stop immediately; TRACE represents a quantified log importance value of 5, which is a unique log level of the Loguru library, more detailed than DEBUG, and is used to record more fine-grained debug information; NOTSET represents a quantified log importance value of 0, indicating that the log level is not set, usually used to represent the lowest level of log recording.

[0092] The embodiment of this application uses the sliding window algorithm to count the occurrence frequencies of logs at all levels and dynamically adjusts the sampling rate. The time window = 5 minutes.

[0093] In the above embodiments, the preset large language model, device status monitoring agent, device fault diagnosis private knowledge base, and device life prediction agent are standardized configured. The specific configuration items are respectively:

[0094] For large language models, its configuration parameters include: model name model, credential information credentials when accessing the interface, Prompt list prompt_messages, model parameters model_parameters, streaming output flag stream, user behavior user, and model return content results. The data type of the model name model is: string; the data type of the credential information credentials when accessing the interface is: object; the data type of the Prompt list prompt_messages is: array; the data type of the model parameters model_parameters is: object; the data type of the streaming output flag stream is: bool, and when its value is True, it indicates streaming output; the data type of the user behavior user is: string, which is used to record user behavior; the data type of the model return content results is: array list array.

[0095] For the private knowledge base of device fault diagnosis, its interface configuration includes: parameter post, parameter knowledge_detail, parameter query, parameter knowledge_setting, parameter results. Parameter post represents the knowledge base service URL and port, and its data type is string; parameter knowledge_detail represents basic information such as knowledge base ID and introduction, and its data type is string; parameter query represents the user's query content, and its data type is string; parameter knowledge_setting is used for the configuration of the knowledge base, and its data type is object; parameter results is of object type and represents the knowledge base retrieval result.

[0096] The above-mentioned access methods of the device status monitoring agent, device life prediction agent and the preset large language model can be accessed through a standardized interface or an API Key.

[0097] In another embodiment, in order to improve the compatibility and scalability of the large model multi-agent framework, a multi-platform compatibility design of the framework's software and hardware is carried out, so that it can run on various terminals such as the server side, mobile side, Internet of Things, and Web side, and fit multiple software systems such as Windows, Linux, and Android, broadening the scope of application of the framework. Among them, the server side is deployed in a GPU supercomputer cluster, and the Web side is open for users to use, enhancing usability. Users can also configure a local server or API on the Web side of the large model multi-agent framework to ensure the adaptability and scalability of the large model multi-agent framework. Specifically:

[0098] Use Docker container technology to quickly configure the large model multi-agent framework, package the framework source code and its dependencies to ensure it can run on different operating systems;

[0099] Regarding the part of end-side compatibility design, the large model multi-agent framework supports various model quantization and compression methods, such as GPTQ, GGUF, etc., which can quantize and compress the weights of large models, reduce the volume of model weights, and improve the model response speed while ensuring the model accuracy;

[0100] The large model multi-agent framework of the embodiments of this application supports inference tasks for various types of large model weights, is compatible with model weight formats such as.safetensors,.ckpt,.pth,.gguf,.bin, ONNX format, etc., is compatible with various model weight conversion interfaces of torch and tf, supports format conversion between.ckpt,.pth, ONNX,.gguf, and supports distributed inference, enabling multi-card parallel inference, improving the compatibility of the framework with large models with hundreds of billions of parameters, and enhancing the large model inference speed.

[0101] In another embodiment, the front end of the large model multi-agent framework of the embodiments of this application adopts a responsive design, and the interface layout is set as a fluid grid layout, defining the width of interface elements according to percentages to flexibly expand and contract according to the screen width, enabling the page to automatically adjust the layout according to different screen sizes and resolutions to adapt to the screens of different terminals.

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

[0103] The technical features of the above-described embodiments can be combined arbitrarily. For the sake of brevity of description, not all possible combinations of the technical features in the above-described embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope described in this specification.

[0104] The above-described embodiments only represent several implementation manners of this application, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the invention patent. It should be pointed out that for those of ordinary skill in the art, without departing from the concept of this application, several modifications and improvements can still be made, and these all belong to the protection scope of this application. Therefore, the protection scope of this application patent should be subject to the appended claims.

Claims

1. A maintenance method for a portal crane in a port based on a large model multi-agent framework, characterized in that, Including: Obtain the user's task request; Decompose the task request based on a preset large language model to generate a service workflow for equipment maintenance. The executable sub-modules of the service workflow include: an equipment status monitoring module, a fault diagnosis and processing module, and an equipment life prediction module; For the executable sub-modules of the service workflow, call the corresponding models, including: The equipment status monitoring module calls an equipment status monitoring agent to obtain the working status data of the portal crane for anomaly identification or receive the early warning information from the control system of the portal crane; The fault diagnosis and processing module calls a private knowledge base for equipment fault diagnosis based on the fault type and cause of the portal crane and outputs the corresponding maintenance plan; The equipment life prediction module calls an equipment life prediction agent to analyze the working status data and return the predicted life value; The preset large language model generates response content based on the output results of the executable sub-modules as context.

2. The maintenance method of the portal crane in the port based on the large model multi-agent framework according to claim 1, characterized in that, The equipment status monitoring agent is obtained by encapsulating an equipment status monitoring system and the early warning interface of the control system of the portal crane. The equipment status monitoring agent is connected to the preset large language model. When the equipment status monitoring system identifies abnormal information or the control system feeds back early warning information, it automatically sends the abnormal information or early warning information to the preset large language model.

3. The maintenance method of the portal crane in the port based on the large model multi-agent framework according to claim 2, characterized in that The equipment status monitoring system includes those arranged on the portal crane: Vibration sensors for collecting vibration data of key parts of the portal crane; Imaging devices for collecting the operating status and appearance of the portal crane.

4. The maintenance method of a port portal crane based on a large model multi-agent framework according to claim 3, characterized in that The fault diagnosis and processing module is configured to: Construct a private knowledge base for equipment fault diagnosis and integrate it into the preset large language model using the RAG technology to achieve accurate answers to operation and maintenance problems based on semantics; The preset large language model obtains the fault type and cause of the portal crane, calls the private knowledge base for equipment fault diagnosis based on the fault type and cause, and outputs the corresponding maintenance plan.

5. The maintenance method of a portal crane in a port based on a large model multi-agent framework according to claim 4, characterized in that, The construction of the private knowledge base for equipment fault diagnosis includes: Integrate the operation manual, fault cases, maintenance manual and expert experience of the portal crane, convert them into Markdown format through data cleaning, convert the text into high-dimensional vectors through a vectorization model, and store them in a vector database to obtain the private knowledge base for equipment fault diagnosis.

6. The maintenance method of the portal crane in the port based on the large model multi-agent framework according to claim 4, characterized in that, The private knowledge base for equipment faults calculates and returns the Top K candidate results based on the cosine similarity of the obtained fault type and cause as the retrieval vector based on the vector database, and then uses a re-ranking model to score the candidate results again, filters out low-correlation data based on a Score threshold, and generates a final sorted list to the preset large language model.

7. The maintenance method of a port portal crane based on a large model multi-agent framework according to claim 3, characterized in that, The equipment life prediction agent is obtained by encapsulating an equipment life prediction model. The equipment life prediction agent is connected to the preset large language model. The equipment life prediction model is pre-trained based on the historical vibration data of key parts of the portal crane and analyzes the data based on the real-time vibration data to output the predicted life value.

8. The maintenance method of the portal crane in the port based on the large model multi-agent framework according to claim 7, characterized in that, The equipment life prediction model uses an LSTM-Transformer hybrid model.

9. The maintenance method of a portal crane in a port based on a large model multi-agent framework according to any one of claims 1 to 8, characterized in that, The service workflow is orchestrated using the process management tool Camunda, and logic units and execution units are respectively set in the device status monitoring module, the fault diagnosis and processing module, and the device life prediction module.

10. The maintenance method of a port portal crane based on a large model multi-agent framework according to any one of claims 1 to 8, characterized in that, The initialization Loguru library is loaded in the main function codes of the service workflow, the preset large language model, the device status monitoring module, the fault diagnosis and processing module, and the device life prediction module, and the log level is set.

Images