Container terminal cross-system collaboration automated diagnosis and decision system and method

Abstract

The application provides an automatic diagnosis and decision system for cross-system cooperation of a container terminal, comprising: an abnormal configuration module, an abnormal configuration module for constructing an abnormal information knowledge graph, a communication system, a data interface layer, a real-time monitoring module, a database / storage module, an abnormal detection unit, a prompt module and a feedback elimination module. The application also provides an automatic diagnosis and decision method for cross-system cooperation of a container terminal, which comprises: establishing an abnormal knowledge graph library, real-time monitoring and abnormal capture, intelligent generation of abnormal information, multi-end hierarchical pushing and abnormal processing and closed-loop elimination. The application is based on cross-system cooperation of a container terminal, abnormal diagnosis and auxiliary decision mechanism, through semantic recognition, intelligent learning, dynamic updating of multi-source data fusion and real-time, accuracy and optimized application range of the knowledge graph, the problems of data inconsistency, update delay and insufficient reasoning ability in the existing automatic container terminal management system architecture are overcome.

Description

Technical Field

[0001] This invention belongs to the field of port management software technology, and relates to information management of port equipment operations and artificial intelligence technology, specifically to an automated diagnosis and decision-making system and method for cross-system collaboration in container terminals. Background Technology

[0002] As the global shipping industry moves towards larger ships and smarter ports, automated container terminals have become the industry mainstream. The core of automated terminals lies in the deep collaboration between the terminal operating system and the equipment control system to direct three major categories of core equipment to complete the loading, unloading and horizontal transportation of containers.

[0003] However, in actual operations, the three systems mentioned above do not operate independently, but are in a strongly coupled state. A single operation command often spans multiple systems. For example, an unloading task requires the QCMS system to control the quay crane to grab the container, while the VMS system dispatches the vehicle to the lane below the quay crane accurately. The vehicle then transports the container to the yard, where the BMS system controls the rail-mounted gantry crane to grab it. In this complex interactive chain, even a small abnormality in any link can have a "butterfly effect," causing the entire workflow to be interrupted.

[0004] Existing automated control systems possess basic fault detection functions (such as PLC error reporting and motor overload alarms), but significant technical deficiencies still exist in actual operation:

[0005] 1. The alarm information is fragmented and semantically obscure:

[0006] Existing technologies typically directly output low-level error codes or hardware status bits; this information is too obscure for field operators and cannot intuitively reflect the impact on the work process; operators often know that "the equipment has stopped," but do not know whether it is "stopped due to a logical deadlock" or "stopped due to a mechanical failure";

[0007] 2. Lack of refined "abnormality level" control:

[0008] Existing systems often employ a binary processing logic: either operate normally or trigger an emergency stop. A patent application (CN202511174492.0) discloses an automated intelligent fault reporting system and method for a horizontal transport robot with an interactive user interface. This patent focuses on immediately triggering a high-level flashing warning and generating a "no-go zone" on a map to isolate the equipment when a "critical fault" is detected. This "one-size-fits-all" approach lacks flexibility; many anomalies (such as "truck identification timeout" or "brief path planning failure") do not require triggering the highest level of emergency stop or physical isolation, only system retry or minor intervention. Excessive high-level responses can lead to unnecessary operational delays and reduce overall clearance efficiency.

[0009] 3. The responsible party for handling the matter is unclear, and there is a lack of standardized "implementation guidelines":

[0010] In the traditional model, after an anomaly occurs, there are often information barriers between the central control room, information room, and equipment room. When an alarm pops up, the central control operator may mistakenly think it is an equipment failure and call a maintenance worker. When the maintenance worker arrives, he finds that the software logic is stuck, and then he needs to call the IT personnel. This "diagnosis-transfer-rediagnosis" process consumes a lot of valuable operation time. In addition, the handling methods are highly dependent on the experience of the personnel. For complex problems such as "IGV deadlock" or "spreader logic not reset", there is a lack of standardized "execution methods", which leads to huge differences in the handling results of different personnel, and even secondary accidents caused by misoperation. Summary of the Invention

[0011] In view of this, it is necessary to address the shortcomings and deficiencies in existing technologies by proposing an automated diagnostic and decision-making system and method for cross-system collaboration in container terminals. This would improve the intelligence level of equipment fault detection, analysis, and reporting based on the port equipment operation information management system, and enhance the efficiency and safety of port operation and maintenance management.

[0012] To achieve the above objectives, the present invention adopts the following technical solution:

[0013] This invention proposes an automated diagnostic and decision-making system for cross-system collaboration in container terminals. It communicates with a Quay Crane Management System (QCMS), a Vehicle Management System (VMS), and a Rail-Mounted Hoist Management System (BMS). The QCMS, VMS, and BMS control the operation of the quay cranes, horizontal transport vehicles, and rail-mounted gantry cranes in the container terminal, respectively, and report any task execution anomalies. Each of the quay cranes, horizontal transport vehicles, and rail-mounted gantry cranes is equipped with equipment monitoring hardware. The automated diagnostic and decision-making system also includes:

[0014] The exception configuration module is used to build an exception information knowledge graph, classify exception sources into quay crane system, rail gantry crane system and vehicle system, and match each exception with a corresponding exception level, preset handler role and standardized execution method library;

[0015] The communication system, deployed in the automated container terminal, communicates with the server in the data center;

[0016] The data interface layer includes a unified architecture communication module and a message transmission protocol module based on the dock industrial Ethernet, which are used to realize standardized data interaction between the control systems of various equipment and with the real-time monitoring module.

[0017] The real-time monitoring module is used to collect physical status data, execute operation commands, monitor equipment status during operation, and detect abnormal operation information of individual equipment through the monitoring hardware of each device, including the quay crane equipment, horizontal transport vehicle equipment, and rail gantry crane equipment, and transmit equipment status and abnormal codes through the communication system.

[0018] Includes a database / storage module for multidimensional related tables;

[0019] The anomaly detection unit is used to acquire abnormal data collected by the real-time monitoring module and abnormal data of task execution of the equipment control system, and store the relevant data in a database / storage module including multi-dimensional association tables;

[0020] The prompt module is used to generate and pop up an abnormal prompt interface in real time based on the multidimensional association table after an abnormality is identified. The interface integrates and displays the abnormality description, execution method guidance and processing cause analysis.

[0021] The feedback elimination module is used to monitor the abnormal processing status. After identifying that the corresponding operation logic has recovered or the fault signal has disappeared, it automatically closes the prompt and records the closed-loop processing log.

[0022] This invention further proposes an automated diagnostic and decision-making system for cross-system collaboration in container terminals, applied to an automated container terminal management system architecture. This architecture includes a real-time monitoring module, a communication system, a data interface layer, an equipment control system, an anomaly detection unit, and an alert module. The automated diagnostic and decision-making system includes:

[0023] The anomaly knowledge graph construction module is used to store information about anomaly levels, information about the person who should make the suggestion, and information about standard execution methods.

[0024] The intelligent diagnostic engine is used to match anomaly knowledge graphs with real-time data and generate decision recommendations.

[0025] This invention further proposes an automated diagnostic and decision-making method for cross-system collaboration in container terminals, the method comprising:

[0026] S1: Establish an anomaly knowledge graph database: Based on the architecture of an automated container terminal management system, the sources of operational anomalies are divided into quay crane management system, rail gantry crane management system and vehicle management system. Anomaly codes are set for each type of anomaly, and anomaly level, anomaly description, suggested execution method, remarks and suggested handler are defined.

[0027] S2: Real-time monitoring and anomaly capture: Real-time collection of the operational status data of the automated container terminal management system architecture and the operating status of individual equipment. When an inconsistency is detected between the operation task record and the physical feedback signal, the anomaly source data is captured.

[0028] S3: Intelligent generation of abnormal information: Based on the captured abnormal source data, the abnormal knowledge graph is retrieved and matched to generate comprehensive abnormal prompt information including abnormal description, abnormal level, execution method, remarks, suggested handler and reason for handling;

[0029] S4: Multi-terminal hierarchical push: Based on the role attributes of the suggested handler, the comprehensive abnormality prompt information is pushed and a pop-up prompt is displayed;

[0030] S5: Anomaly Handling and Closed-Loop Elimination: Monitors abnormal states. For anomalies that can be automatically recovered by the program, the prompt is automatically eliminated after the fault signal disappears. For anomalies that require manual intervention, after the person handling the issue executes the corresponding method and the system verifies that the system has returned to normal, the anomaly prompt is automatically eliminated.

[0031] This invention further proposes an automated diagnostic and decision-making method for cross-system collaboration in container terminals, the method comprising:

[0032] S100 monitors the operating status of quay crane equipment, rail-mounted gantry crane equipment, and vehicle equipment in real time, as well as abnormal events in the equipment control system.

[0033] S200 detects and classifies abnormal events, and determines the level of abnormality;

[0034] S300 generates standardized processing suggestions based on a pre-defined knowledge graph;

[0035] S400 outputs decision instructions to relevant systems or operators.

[0036] The present invention further proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the automated diagnosis and decision-making method for cross-system collaboration in container terminals as described above.

[0037] The present invention also proposes an electronic device, including a memory, a processor, and a computer program stored in the memory and executable by the processor, wherein the processor executes the computer program to implement the steps of the automated diagnosis and decision-making method for cross-system collaboration in container terminals as described above.

[0038] The beneficial effects of this invention are as follows:

[0039] This invention, based on cross-system collaboration, anomaly diagnosis, and decision support mechanisms in container terminals, overcomes the problems of data inconsistency, update delays, and insufficient reasoning capabilities in existing automated container terminal management system architectures by leveraging semantic recognition, intelligent learning, dynamic updates, multi-source data fusion, and the real-time, accuracy, and optimized application scope of knowledge graphs. It provides a more efficient, intelligent, accurate, and practical solution for anomaly diagnosis and decision support in automated port management, thereby improving the intelligence level and security of port management. Attached Figure Description

[0040] Figure 1 This refers to the pop-up interface of the central control group operator terminal involved in Embodiment 5 of the present invention;

[0041] Figure 2 This is a schematic diagram of the working principle of a preferred architecture of the automated diagnosis and decision-making system for cross-system collaboration in container terminals according to Embodiment 1 of the present invention.

[0042] Figure 3 The flowchart in Example 3 shows the automated diagnosis and decision-making method for cross-system collaboration in container terminals according to the present invention. Detailed Implementation

[0043] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be further described clearly and completely below in conjunction with the embodiments of this invention. It should be noted that the described embodiments are merely some embodiments of this invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0044] As used in this specification and the following claims, the words “a,” “an,” and “the” have the meaning of plural references unless the context clearly indicates otherwise.

[0045] Example 1

[0046] This embodiment proposes an automated diagnostic and decision-making system for cross-system collaboration in a container terminal. It communicates with the Quay Crane Management System (QCMS), Vehicle Management System (VMS), and Rail-Mounted Gym Management System (BMS). The QCMS, VMS, and BMS control the operation of the quay cranes, horizontal transport vehicles, and rail-mounted gantry cranes in the container terminal, and respectively report any task execution anomalies. Each of the quay cranes, horizontal transport vehicles, and rail-mounted gantry cranes is equipped with equipment monitoring hardware. The automated diagnostic and decision-making system also includes:

[0047] The exception configuration module is used to build an exception information knowledge graph, classify exception sources into quay crane system, rail gantry crane system and vehicle system, and match each exception with a corresponding exception level, preset handler role and standardized execution method library;

[0048] The communication system, deployed in the automated container terminal, communicates with the server in the data center;

[0049] The data interface layer includes a unified architecture communication module and a message transmission protocol module based on the dock industrial Ethernet, which are used to realize standardized data interaction between the control systems of various equipment and with the real-time monitoring module.

[0050] The real-time monitoring module is used to collect physical status data, execute operation commands, monitor equipment status during operation, and detect abnormal operation information of individual equipment through the monitoring hardware of each device, including the quay crane equipment, horizontal transport vehicle equipment, and rail gantry crane equipment, and transmit equipment status and abnormal codes through the communication system.

[0051] Includes a database / storage module for multidimensional related tables;

[0052] The anomaly detection unit is used to acquire abnormal data collected by the real-time monitoring module and abnormal data of task execution of the equipment control system, and store the relevant data in a database / storage module including multi-dimensional association tables;

[0053] The prompt module is used to generate and pop up an abnormal prompt interface in real time based on the multidimensional association table after an abnormality is identified. The interface integrates and displays the abnormality description, execution method guidance and processing cause analysis.

[0054] The feedback elimination module is used to monitor the abnormal processing status. After identifying that the corresponding operation logic has recovered or the fault signal has disappeared, it automatically closes the prompt and records the closed-loop processing log.

[0055] In some embodiments, the anomaly level is optimized to include level IV, which has different triggering logic; wherein levels I-III are silent anomalies that the program can automatically attempt to recover from, levels IV-V are blocking anomalies that require manual intervention, and different levels are matched with different visual salience.

[0056] In some embodiments, the preset processing personnel roles include at least an equipment room maintenance worker, an information room system operator, and a central control group operator; the prompting module automatically pushes information to the terminal of the corresponding role based on the type of anomaly source.

[0057] In some embodiments, optimized, such as Figure 2 As shown, the equipment monitoring hardware includes a programmable logic controller (PLC), a distributed sensor acquisition module, or / or an actuator drive unit deployed on the corresponding equipment body. It is used to collect equipment physical status data and execute operation action instructions, to obtain the equipment status during the operation, to capture single-machine equipment operation abnormalities, and to transmit equipment status and abnormal code information through a communication system.

[0058] The communication system includes network switches, network cables, fiber optic wireless communication modules, and / or a communication network system connected to a server in a data center, deployed in an automated container terminal.

[0059] The unified architecture communication module is specifically the OPCUA unified architecture communication module; the message transmission protocol module is specifically the MQTT message transmission protocol module.

[0060] Example 2

[0061] This embodiment proposes an automated diagnostic and decision-making system for cross-system collaboration in container terminals, applied to an automated container terminal management system architecture. This architecture includes a real-time monitoring module, a communication system, a data interface layer, an equipment control system, an anomaly detection unit, and an alert module. The automated diagnostic and decision-making system includes:

[0062] The anomaly knowledge graph construction module is used to store information about anomaly levels, information about the person who should make the suggestion, and information about standard execution methods.

[0063] The intelligent diagnostic engine is used to match anomaly knowledge graphs with real-time data and generate decision recommendations.

[0064] In some embodiments, the anomaly knowledge graph construction module is also used to dynamically generate and update a port knowledge graph based on the operational data of the automated container terminal management system architecture, combined with the semantic understanding capabilities of a large language model. The knowledge graph contains information on port equipment, operational processes, personnel roles, and operating procedures.

[0065] In some embodiments, the intelligent diagnostic engine includes:

[0066] The multi-source heterogeneous data fusion and analysis module is used to fuse and analyze multi-source heterogeneous data to obtain fusion analysis results.

[0067] The anomaly detection module is used to identify potential anomalies in the fusion analysis results of the multi-source heterogeneous data fusion analysis module, and to transform the obscure low-level equipment code into standard operating instructions that include "suggested handlers" and "execution methods".

[0068] The decision distribution module, based on the role definitions in the knowledge graph, directly distributes anomalies to the corresponding suggestion handlers, thereby achieving decentralized decision-making.

[0069] The closed-loop management and automatic elimination module is used to sense the intervention results and automatically close the alarm window, forming a closed-loop management system.

[0070] In a further optimized manner, the multi-source heterogeneous data fusion and analysis module performs fusion and analysis on multi-source heterogeneous data using a deep learning algorithm.

[0071] In a further optimized manner, the multi-source heterogeneous data fusion and analysis module is connected to the anomaly detection module, the decision distribution module, the closed-loop management and automatic elimination module, and the anomaly knowledge graph construction module, respectively. Based on the full-process data of anomaly handling recorded in the closed-loop management, the multi-source heterogeneous data fusion and analysis module performs self-learning updates on the anomaly knowledge graph and the operating rules of each module.

[0072] Furthermore, the self-learning update process of the multi-source heterogeneous data fusion and analysis module specifically includes:

[0073] Supplementing new anomaly knowledge: For new anomalies that have no matching records in the anomaly knowledge graph, their anomaly characteristics, work scenarios, and scope of impact are automatically extracted, temporary anomaly entries are generated and pushed to the team leader of the central control group, and automatically supplemented into the anomaly knowledge graph after manual review and confirmation.

[0074] Optimization of accountability and tracing rules: Automatically review the data of all nodes in the chain after the anomaly handling is completed. If the accountability deviation is found, automatically adjust the node responsibility mapping rules and cross-system root cause tracing logic in the knowledge graph.

[0075] Tier and push rules optimization: Statistically analyze the handling time, number of transfers, and scope of impact of historical anomalies, and dynamically adjust the judgment thresholds, corresponding push target roles, and handling timeout thresholds for anomalies of levels I-V;

[0076] Automatic recovery strategy optimization: Statistically analyze the success rate of automatic recovery from Level I-III silent anomalies, and dynamically adjust the number of automatic retries and the retry interval of the system;

[0077] Anomaly elimination threshold optimization: Based on historical anomaly "false recovery" records, the judgment conditions for anomaly elimination are automatically adjusted to avoid repeated triggering of anomalies.

[0078] To further optimize the system, the multi-source heterogeneous data fusion and analysis module performs batch self-learning daily during off-peak hours at the port. All rule updates and parameter adjustments must be manually reviewed and confirmed before they take effect.

[0079] Example 3

[0080] like Figure 3 As shown:

[0081] This embodiment proposes an automated diagnosis and decision-making method for cross-system collaboration in container terminals, which includes:

[0082] S1: Establish an anomaly knowledge graph database: Based on the architecture of an automated container terminal management system, the sources of operational anomalies are divided into quay crane management system, rail gantry crane management system and vehicle management system. Anomaly codes are set for each type of anomaly, and anomaly level, anomaly description, suggested execution method, remarks and suggested handler are defined.

[0083] S2: Real-time monitoring and anomaly capture: Real-time collection of the operational status data of the automated container terminal management system architecture and the operating status of individual equipment. When an inconsistency is detected between the operation task record and the physical feedback signal, the anomaly source data is captured.

[0084] S3: Intelligent generation of abnormal information: Based on the captured abnormal source data, the abnormal knowledge graph is retrieved and matched to generate comprehensive abnormal prompt information including abnormal description, abnormal level, execution method, remarks, suggested handler and reason for handling;

[0085] S4: Multi-terminal hierarchical push: Based on the role attributes of the suggestion handler (preferably, the suggestion handler includes the equipment room, information room, and central control group), the comprehensive anomaly prompt information is pushed and a pop-up prompt is displayed;

[0086] S5: Anomaly Handling and Closed-Loop Elimination: Monitors abnormal states. For anomalies that can be automatically recovered by the program, the prompt is automatically eliminated after the fault signal disappears. For anomalies that require manual intervention, after the person handling the issue executes the corresponding method and the system verifies that the system has returned to normal, the anomaly prompt is automatically eliminated.

[0087] In some optimized embodiments, the definition of exception logic for the quay crane management system class includes:

[0088] Driver's manual confirmation command failed: Driver's manual confirmation command failed;

[0089] Automatic matching of work container WI failed: Work container WI could not be found;

[0090] No task spreader with box: There is no work record, but the spreader is currently carrying a box. Manually unlock and place the box to the designated position.

[0091] The lifting device was unlocked, but there are incomplete work task records:

[0092] The lifting gear has been unlocked, but there are incomplete work tasks recorded, requiring manual confirmation that the loading and unloading operations are complete.

[0093] Instruction timed out: The instruction timed out.

[0094] In some embodiments, the definition of exception logic for the rail-mounted crane management system class includes:

[0095] Waiting for truck to arrive timeout: Waiting for truck to arrive timeout;

[0096] Truck identification error: Truck identification error;

[0097] The work box is not powered off: The work box is not powered off. Terminate the task or wait for power to be disconnected.

[0098] Equipment with no task but carrying a box: If the equipment has no task but carrying a box, put the box down.

[0099] In some embodiments, the definition of exception logic for the vehicle management system class is optimized to include:

[0100] The vehicle's location is locked by the quay crane or rail-mounted gantry crane, and a route cannot be planned: The vehicle's application for a safe area failed, and a planned route to leave is not allowed;

[0101] Bicycle traffic control code error: There is a conflict with the locking zone of other vehicles ahead, and you are not allowed to leave wait V146;

[0102] Lock button operation timeout: The time spent disassembling and assembling the lock pin is too long;

[0103] Route planning failed: The vehicle is in a restricted area. Please check the destination location "Target Location" and the restricted area list "Restricted Area Number".

[0104] In some embodiments, the automatic elimination prompt determination logic in step S5 is as follows: the system checks the status bit of the abnormal source in a polling manner, and triggers the abnormal clearing instruction only when the status code returned by the abnormal source changes from "fault" to "restored to normal" and the associated subsequent operation instruction has been successfully issued.

[0105] In some embodiments, specifically in step S1, the complex dock operation is broken down into three core subsystems, and features of typical anomalies are extracted:

[0106] Quay crane management system: This covers conflicts between physical actions and logical commands. For example, if the spreader status shows "unlocked" but the system task shows "loaded container to be unloaded," the system determines this as a signal inconsistency anomaly.

[0107] Rail-mounted gantry crane management system: This category covers yard safety and interaction logic. For example, if a rail-mounted gantry crane has no automated tasks, but the spreader status shows "heavy load," the system determines that the equipment is not carrying containers, causing an anomaly.

[0108] Vehicle Management System: Covers route planning and deadlock. For example, if a vehicle remains stationary at a specific coordinate for more than a preset time T, and the traffic code displays "deadlock," a route planning failure message will be triggered.

[0109] In some embodiments, specifically, in step S1, a multidimensional association table is also generated:

[0110] Construct the database structure as follows, including serial number, exception code, occurrence time, exception system, device type, device number, exception description, exception level, remarks (execution method), processing reason, processing time, and suggested handler; and add filter-query items, including processing status, occurrence time, exception system, exception level, and suggested handling.

[0111] In some embodiments, specifically in step S4, when the system detects an "abnormal vehicle traffic control code":

[0112] Trigger: The vehicle system detects a conflict between the vehicle's locking zone and that of another vehicle ahead;

[0113] Push notification: The system immediately pushes the information to the "central control group". The prompt window not only displays "Single vehicle traffic control code abnormal", but also notes: "Conflict with the locking zone of other vehicles ahead, wait V112";

[0114] Execution: After the central control operator discovers the issue, they click the "V112" button in the window, which will automatically redirect them to the location of the vehicle and handle the anomaly according to the notes.

[0115] Therefore, step S4 changes the traditional model of "sending to the central control unit first and then contacting the corresponding group according to the fault situation" and implements role-based precise push.

[0116] In some embodiments, specifically in step S5, for automatic program recovery, the following is executed: For anomalies caused by low-level issues or network fluctuations (such as "VMS path planning temporarily failed"), once the system detects that the device status has returned to normal and subsequent instructions have been successfully issued, the system automatically eliminates the anomaly prompt without requiring manual clicking, thus reducing manual operation;

[0117] For manual intervention issues, the procedure is as follows: For anomalies such as "power not disconnected" or "manually changed position", the person who suggested handling the issue must operate according to the "execution method". The system will then perform a secondary verification and confirm that the fault characteristics have disappeared before the anomaly can be eliminated and the automated workflow can be restored.

[0118] Furthermore, the automated diagnosis and decision-making method for cross-system collaboration of container terminals in Example 3 is based on the automated diagnosis and decision-making system for cross-system collaboration of container terminals in Example 1 or Example 2.

[0119] Example 4

[0120] This embodiment proposes an automated diagnosis and decision-making method for cross-system collaboration in container terminals, which includes:

[0121] S100 monitors the operating status of quay crane equipment, rail-mounted gantry crane equipment, and vehicle equipment in real time, as well as abnormal events in the equipment control system.

[0122] S200 detects and classifies abnormal events, and determines the level of abnormality;

[0123] S300 generates standardized processing suggestions based on a pre-defined knowledge graph;

[0124] S400 outputs decision instructions to relevant systems or operators.

[0125] In some embodiments, during S100, real-time data is acquired from multiple data sources and standardized based on a unified object model.

[0126] Specifically, the unified object model is a unified object model for the entire operation chain of an automated terminal, which is a standardized data modeling system covering four core dimensions: equipment entities, operation nodes, abnormal events, and personnel roles; the unified object model specifically includes:

[0127] The equipment entity model is used to define the general and specific attributes of the three major categories of core equipment: quay cranes, IGVs, and rail-mounted gantry cranes. The general attributes include the equipment's unique identifier, equipment type, system to which it belongs, operating status, geographical coordinates, and communication status. The specific attributes include the spreader status and lifting height of the quay crane, the battery level and traffic control code of the IGV, and the bay number and load status of the rail-mounted gantry crane.

[0128] The operation node model is used to minimize decomposition: the entire operation process of a single container at an automated terminal (unloading / loading) is broken down into the smallest indivisible execution nodes (unloading operation is broken down into 12 core nodes, loading operation is broken down accordingly, each node corresponds to a unique operation action, bound system / equipment, timing threshold, and the execution boundary and triggering conditions of each node are clearly defined):

[0129] The exception event model is used to define a unified data structure for exception events. The data types defined by it include exception code, exception level, exception source type, occurrence time, associated device ID, associated job node ID, associated task number, and scope of impact.

[0130] The personnel role model is used to define the permission attributes, scope of responsible equipment, scope of responsible work nodes, and level of handling authority for five types of roles: equipment room maintenance personnel, information room system personnel, central control group operators, team leaders, and supervisors.

[0131] In some embodiments, the method further includes, between S100 and S200: S1001, knowledge graph construction: dynamically generating and updating a port knowledge graph by combining the semantic understanding capabilities of a large language model, and then executing S300.

[0132] In some embodiments, during S200, a deep learning algorithm is used to perform fusion analysis on multi-source heterogeneous data to identify potential anomalies.

[0133] In some embodiments, during S300, the underlying device code is converted into standard operating instructions containing the corresponding suggestion handler and the corresponding execution method.

[0134] In some embodiments, during process S400, based on the role definitions in the knowledge graph, anomalies are directly distributed to the corresponding suggestion handlers, thereby achieving decentralized decision-making.

[0135] In some embodiments, the method further includes:

[0136] S500, executed after S400, automatically eliminates: the system can sense the intervention results and automatically close the alarm window, forming a closed-loop management.

[0137] In a further optimized manner, the automated diagnosis and decision-making method for cross-system collaboration of container terminals in Example 4 is based on the automated diagnosis and decision-making system for cross-system collaboration of container terminals in Example 1 or Example 2.

[0138] Example 5

[0139] Example 5 is an optimized design of any one of the technical solutions in Example 3;

[0140] In S1, a node-responsible entity mapping system needs to be constructed for the entire operation chain:

[0141] This step provides the root cause and responsibility basis for accurate push notifications. The core is to break through the limitations of single-device early warning, realize the source tracing of anomalies at the operation node level across three major systems, and avoid the error in assigning responsibility caused by chain anomalies.

[0142] Minimal Decomposition of Work Nodes: The system pre-defines a minimum work unit node mapping table for the entire terminal operation chain, breaking down the entire automated terminal single-container operation process (unloading / loading) into indivisible minimum execution nodes (unloading operation is broken down into 12 core nodes, loading operation is broken down accordingly, each node corresponds to a unique work action, bound system / equipment, timing threshold, and clearly defines the execution boundaries and triggering conditions of each node). The core parameters are as follows, taking unloading operation as an example, see Table 1 below:

[0143]

[0144] Table 1

[0145] In step S1, a responsibility entity mapping system needs to be pre-defined:

[0146] Each smallest node is pre-assigned a "primary responsible role, secondary responsible role, responsible system, and department to which the equipment belongs," with the core binding logic being unambiguous:

[0147] Abnormal equipment hardware operation (such as spreader lock failure, motor overload, trolley malfunction): Primary responsibility = corresponding professional maintenance personnel in the equipment room

[0148] System command / logic / software exceptions (such as command issuance failure, task status conflict, path planning logic error): Primary responsibility = Information Room System Officer

[0149] Anomalies in work scheduling / on-site interaction / traffic control (such as vehicle lock-up, lane conflict, truck arrival delay): Primary responsibility = Central control group operator

[0150] Preset rules for assigning responsibility to cross-system boundary nodes:

[0151] For the boundary nodes of the three major systems of quay crane-IGV and IGV-rail gantry crane, the timing verification benchmark and responsibility determination logic are clearly defined in advance: based on the preset cross-system timing coupling model, whichever node first deviates from the preset rules in terms of state / timing is determined to be the main responsible party for that node, thus completely avoiding cross-system shirking of responsibility.

[0152] In step S2, it is necessary to perform in-process core - cross-system full-link root cause tracing after the anomaly is triggered (core responsibility determination).

[0153] The source tracing and accountability execution logic system communicates in real time with the three core systems: QCMS, VMS, and BMS. The sampling frequency is 100ms / time, collecting the execution status, instruction issuance time, and node feedback time of each job node in real time. The process for triggering source tracing and accountability is as follows:

[0154] When the execution time of a node exceeds the preset timeout threshold, or when the node's feedback status is inconsistent with the work instruction requirements, the abnormal node number is immediately locked, and the responsible system and responsible equipment number bound to the node are extracted.

[0155] Trace back the execution status of the three preceding related nodes to confirm whether the anomaly is a chain reaction of the preceding nodes (for example, if the N4 node's IGV arrives at the designated location too early, it is necessary to trace whether the N3 node's quay crane arrived at the container placement location in advance and whether the VMS issued the scheduling instruction in advance to rule out the influence of the preceding nodes).

[0156] Ultimately, the system identifies the sole source of the anomaly, pre-determines the responsible party, and matches them with pre-defined roles, providing a basis for subsequent accurate data delivery.

[0157] In step S3, precise matching is required - configuration of push rules based on anomaly level and role permissions (quantification of grading parameters):

[0158] This step refines the quantitative rules binding push notifications to the existing I-V level classification, achieving "tiered push notifications, permission matching, and no unnecessary interference." The core classification and push notification parameters are as follows, see Table 2 below:

[0159]

[0160] Table 2

[0161] In step S3, the following logic needs to be executed: After the system completes the source tracing and responsibility determination of the anomaly, it matches the above-mentioned classification standards to determine the anomaly level, and strictly follows the principle of "priority to the main push role and backup to the copy role" to push the corresponding anomaly information only to the terminal of the role with the authority to handle it, completely replacing the traditional broadcast alarm and avoiding interference from invalid information.

[0162] In step S4, the dynamic semantic generation and one-click processing of the content to be pushed are linked:

[0163] This step enables the linkage between personalized push content and action handling, completely solving the pain points of obscure semantics in underlying error codes and lack of guidance for operator handling;

[0164] In step S4, dynamic semantic generation logic needs to be executed:

[0165] The system pre-sets multiple sets of semantic error templates. Each template corresponds to a unique error code, error source, and responsible role. The template includes fixed fields and dynamic real-time data fields. When generating push content, the system populates the real-time device data and workflow data at the time of the error, including device number, real-time location coordinates, stall duration, conflict object number, job task number, and execution status of the preceding node, completely replacing the obscure error code at the underlying level.

[0166] In step S4, permission embedding and linkage need to be handled with a single click:

[0167] The pop-up window interface contains a one-click processing button corresponding to the standardized execution method. The button is only open to the responsible role with the appropriate permissions, and the visibility of the button and the operation permissions of different roles are completely isolated. When the responsible role clicks the one-click processing button, the system automatically sends the processing instruction to the corresponding equipment control system, eliminating the need for the operator to switch between multiple system interfaces and operate manually, thus greatly shortening the processing time.

[0168] For example: Description (Route planning failed) + Remarks (Route planning failed) + Abnormal system (VMS) + Execution method (Central control group draws restricted area, equipment room tow truck) + Suggested person to handle (Central control group / equipment room);

[0169] Description (Button lock operation timeout) + Remarks (IGV button lock operation timeout) + Abnormal System (VMS) + Execution Method (Notify personnel to perform button lock operation in a timely manner; the abnormality will be automatically cleared upon receiving the button lock signal) + Suggested Handler (Central Control Group)

[0170] Description (charger malfunction) + Remarks (no vehicle warning detected when robot sensor extended) + Abnormal System (VMS) + Execution Method (Inspect the charger in the equipment room and reset it after the fault is resolved) + Recommended Person in Charge (Equipment Room).

[0171] In the management process of some embodiments, such as (Management Example 1):

[0172] During the unloading operation, the IGV scheduling at node N4 timed out. The system identified the source of the anomaly as a deadlock in the IGV-V102 path of the vehicle system, with an anomaly level of IV. The pop-up message pushed to the operator terminal of the central control group is as follows: Figure 1 As shown, the details are as follows:

[0173] [Error Code] 400002 [Occurrence Time] 2026-03-29 10:58:54 [Error System] VMS [Device Number] IGV-V102 [Error Description] Route planning failed [Remarks] The destination location is locked to another vehicle. If the problem cannot be resolved automatically for an extended period, please manually intervene and tow the vehicle. IGVs that may cause this vehicle to lock up include: V020, V029, V102, and V092.

[0174] [Abnormality Level] Level IV [Recommended Personnel] Central Control Group Operator;

[0175] [Standardized Implementation Methods]:

[0176] 1) Click on the [Device Number] to jump to the real-time vehicle map and view the location of the conflicting vehicles;

[0177] 2) After confirming there are no security risks, click

Generate Restricted Zone

[0178] 3) Click on "One-Click Resend Scheduling Command" to trigger IGV to replan its route.

[0179] The [Handling Buttons] (visible only to the central control operator) include: one-click jump to the real-time vehicle map, generate a restricted area, one-click resend dispatch instructions, and abnormal transfer (can only be transferred to the information room system operator).

[0180] In step S5, a closed-loop tracking mechanism for the push status and a timeout reassignment mechanism are required:

[0181] This step improves the closed-loop management of the entire push notification process, addressing the pain points of no response and no tracking after an abnormal push notification. Specific logic:

[0182] While the system pushes out abnormal information, it starts a timeout timer for handling the abnormality. The timer threshold is bound to the abnormality level: 300s for level III abnormalities, 120s for level IV abnormalities, and 60s for level V abnormalities.

[0183] When the timer reaches the timeout threshold and the responsible role has not yet confirmed the handling of the anomaly, the system will automatically trigger an escalation and reassignment, pushing the anomaly information to the direct supervisor's terminal of the responsible role, while retaining the original responsible role's push permissions.

[0184] The system tracks the entire process of anomaly handling in real time, and each handling action is recorded in a closed-loop log, including the person handling the action, the time of handling, the action taken, the result of handling, and the system verification status.

[0185] Only when the system verifies that the abnormal source status has returned to normal and the associated job node has restarted execution, is the abnormal handling closed loop determined, the push pop-up closed, and the full process tracking completed.

[0186] In step S6, post-event learning is required: review of the accountability results and self-learning optimization.

[0187] For novel anomalies with no matching records in the knowledge graph, the system defaults to temporarily assigning the responsibility to the "central control team leader". It first pushes an early warning information, and the team leader completes the preliminary root cause determination before transferring it to the corresponding responsible entity. At the same time, it records the characteristics of the anomaly and the determination of responsibility, and automatically adds it to the anomaly knowledge graph.

[0188] In step S6, a post-handling responsibility verification is required: after the anomaly is handled and the workflow returns to normal, the system automatically verifies the entire chain of data, responsibility determination results, and handling process of this anomaly to confirm whether the root cause determination and the matching of the responsible party are accurate.

[0189] In step S6, the knowledge graph needs to be optimized through self-learning: if the review finds a deviation in the determination of responsibility, or if a new type of abnormality is added to the determination of responsibility record, the system will automatically optimize the node-responsibility mapping rules and the source tracing logic, update the abnormality knowledge graph, continuously improve the accuracy of determination of responsibility, and avoid the recurrence of the same type of abnormality in determination of responsibility.

[0190] In the management process of some embodiments, such as (Management Example 2):

[0191] At an automated terminal, 8 quay cranes, 24 IGVs, and 16 rail-mounted gantry cranes were operating simultaneously. IGV-V112 experienced a Level IV deadlock anomaly, which was linked to unloading operation task number XS202405200468.

[0192] Relevance determination: Only the single-box workflow of XS202405200468 is a related workflow, while the 126 parallel work tasks bound to the other 23 IGVs are all unrelated workflows;

[0193] Execution: All non-related workflows are executed normally and are not affected in any way; related workflows are only suspended at node N4 (IGV in place), while the status of all preceding nodes N1-N3 is retained, and the quay cranes remain in the suspended position for container placement, without the need to restart the unloading task.

[0194] Outcome: The control room operator completed the anomaly handling within 90 seconds. After the IGV arrived, the system automatically verified that the status was normal and directly triggered the N5 node (quay crane container release) to proceed, and the workflow continued to advance. Compared with the traditional "one-size-fits-all" shutdown mode, this anomaly did not cause other operational delays, and the efficiency of single-vessel operations increased by more than 45%.

[0195] In the management process of some embodiments, such as (Management Example 3):

[0196] Closed-loop verification and experience self-learning are required for handling workflow anomalies.

[0197] When the charging pile reports an operation timeout and no matching record is identified in the graph, the temporary responsibility for this new type of anomaly is assigned to the "central control team leader". First, an early warning message is sent, and the team leader completes the preliminary root cause determination before transferring it to the corresponding responsible entity, namely the "equipment room". After receiving the information, the equipment room proposes a solution: "After confirming that the charger is not faulty and the environment is safe, click the charger resend button".

[0198] Once the anomaly handling is completed, the system performs a secondary check on all nodes in the workflow to confirm that the status and timing of all nodes have returned to normal and the workflow is proceeding smoothly, thus determining that the anomaly is closed.

[0199] At this point, all the characteristic data, handling methods, handling results, and impact data on the workflow of this anomaly will be stored in the anomaly knowledge graph database.

[0200] During the early morning off-peak hours each day, the system performs self-learning on all anomaly knowledge graphs for the day, optimizing anomaly level judgment rules, push rules, and automatic handling logic, automatically optimizing the number of retries and identification thresholds, improving the success rate of automatic recovery, and reducing manual intervention.

[0201] This invention focuses on the tightly coupled workflow of three core systems in automated terminals: quay cranes, horizontal transport, and rail-mounted gantry cranes. It achieves precise source tracing, hierarchical responsibility determination, role-based targeted notifications, and seamless workflow recovery for cross-system anomalies, rather than relying on independent hardware safety warnings for single devices. This invention provides dynamic alerts and precise notifications, addressing the pain points of traditional "broadcast" alarms, such as ineffective interference, ambiguous responsibility, and low response efficiency, as well as the limitations of general warnings for single devices. It does not address cross-system role-based targeted notifications, hierarchical dynamic alerts, permission-matching notification rules, or closed-loop handling mechanisms. The clear identification of the responsible party for anomaly handling in this invention is based on cross-system workflow root cause tracing, pre-set node-responsibility mapping rules, and anomaly level and handling permission matching—a fully quantified, traceable, and unambiguous automated judgment mechanism. This completely solves the pain points of ambiguous responsibility, buck-passing, and time-consuming order transfers in traditional models.

[0202] Example 6

[0203] This embodiment proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the automated diagnosis and decision-making method for cross-system collaboration in container terminals as described in either Embodiment 3 or Embodiment 4.

[0204] This embodiment also proposes an electronic device, including a memory, a processor, and a computer program stored in the memory and executable by the processor. When the processor executes the computer program, it implements the steps of the automated diagnosis and decision-making method for cross-system collaboration in container terminals as described in either Embodiment 3 or Embodiment 4.

[0205] The processor can have various specific implementations. For example, it may include one or more combinations of a central processing unit (CPU), GPU, NPU, TPU, or DPU, etc., and this application embodiment does not impose specific limitations. The processor can also be a single-core processor or a multi-core processor. The processor can be a combination of a CPU and hardware chips. The aforementioned hardware chips can be application-specific integrated circuits (ASICs), programmable logic devices (PLDs), or combinations thereof. The aforementioned PLDs can be complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), generic array logic (GALs), or any combination thereof. The processor can also be implemented using logic devices with built-in processing logic, such as FPGAs or digital signal processors (DSPs).

[0206] The memory involved in this embodiment can be volatile memory or non-volatile memory, or it can include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DRRAM).

[0207] In one example, the electronic device may also include a communication interface and a bus; the processor, memory, and communication interface of the electronic device are connected via the bus and communicate with each other; the communication interface is mainly used to realize communication between various modules, devices, units, and / or devices in the embodiments of this application; the bus includes hardware, software, or both, coupling the components of the electronic device together; for example, and not as a limitation, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, etc. Bus, Serial Advanced Technology Attachment (SATA) bus, Video Electronics Standards Association Local (VLB) bus, or other suitable bus, or a combination of two or more of these; where appropriate, a bus may include one or more buses; although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0208] It should be understood that the client (terminal) involved in this invention can be an electronic device running a third-party application. The electronic device can be a terminal device or a server. Specifically, the terminal device can include any electronic device such as a mobile phone, computer, virtual reality (VR) device, tablet computer, augmented reality (AR) device, laptop computer, etc., and this application embodiment does not limit this.

[0209] The present invention can be practiced by combining one or more machine-readable storage media containing code according to the invention with suitable standard computer hardware to execute the code contained therein. Apparatus for implementing various embodiments of the invention may include one or more computers (or one or more processors within a single computer) and a storage system containing or having network access to computer programs encoded according to the various methods described herein, and the method steps of the invention may be performed by modules, routines, subroutines, or sub-parts of a computer program product.

[0210] Furthermore, the present invention can be implemented using hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware, or microcode, program code or code segments (e.g., a computer program product) that perform the necessary tasks can be stored in a machine-readable medium. The processor can perform the necessary tasks. In the above embodiments, it can be implemented wholly or partially using software, hardware, firmware, or any combination thereof. When implemented using a software program, it can be implemented wholly or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function described in the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access, or it can include one or more data storage devices such as servers or data centers that can be integrated with media. The available medium can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

[0211] The system, device, and storage medium in this invention are based on multiple aspects of the same inventive concept as the method in the foregoing embodiments. The implementation process of the method has been described in detail above, so those skilled in the art can clearly understand the structure and implementation process of the system, device, and storage medium in this embodiment based on the foregoing description. For the sake of brevity, it will not be described again here.

[0212] In some embodiments, the system may be configured as a distributed system, wherein one or more components of the system are distributed across one or more networks of a cloud computing system.

[0213] The present invention also includes the following advantages:

[0214] 1. Semanticization of global anomalies: Transform obscure low-level device code into standard operating procedures that include "suggested handler" and "execution method," solving the problem of operators being "at a loss" when faced with alarms;

[0215] 2. Decentralized decision-making: By precisely defining the "suggestion handler", exceptions are directly distributed to the person who can solve the problem, avoiding the communication losses caused by the central controller in the traditional model;

[0216] 3. Lowering the technical threshold: The provided "execution method" is equivalent to a built-in real-time instruction manual, which greatly shortens the fault response time;

[0217] 4. Emphasis on "workflow logic": Many existing patents are about "hardware fault alarms", while this invention emphasizes "unsmooth operation logic" (such as task stagnation and state conflicts), which is a pain point of automated terminal software systems;

[0218] 5. Emphasize "automatic elimination": Highlight the closed-loop characteristic of the system that can sense the intervention results and automatically close the pop-up window, which is different from the traditional manual alarm elimination system.

[0219] 6. By establishing an anomaly knowledge graph that includes "anomaly level (Level I-V)," "suggested handler (equipment / information / central control)," and "standard execution method," the system can move from "passive alarm" to "proactive decision guidance," thereby significantly improving the automated terminal's ability to cope with system instability.

[0220] 7. Solve the technical problems of fragmented, semantically obscure, unclear responsible parties, and difficulty in reusing handling experience in the coupled operation environment of multiple systems (quay cranes, rail-mounted gantry cranes, and horizontal transport) of automated container terminals;

[0221] 8. Semanticization of global anomalies: Transform obscure low-level device code into standard operating procedures that include "suggested handler" and "execution method," solving the problem of operators being "at a loss" when faced with alarms;

[0222] 9. Precise assignment and routing: Solve the problem of invalid interference caused by the traditional "broadcast" alarm transmission, and realize the precise routing of abnormal information to the equipment room, information room and central control group;

[0223] 10. Tiered Flexible Control: Through refined tiered management from Level I to Level V, the system addresses the unnecessary loss of operational efficiency caused by the "one-size-fits-all" shutdown approach of existing technologies, enabling differentiated responses to anomalies at different levels.

[0224] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of this patent should be determined by the appended claims.

Claims

1. An automated diagnostic and decision-making system for cross-system collaboration in a container terminal, communicating with a Quay Crane Management System (QCMS), a Vehicle Management System (VMS), and a Rail-Mounted Crane Management System (BMS); the QCMS, VMS, and BMS respectively control the operation of quay crane equipment, horizontal transport vehicle equipment, and rail-mounted crane equipment in the container terminal, and respectively report task execution anomalies; the quay crane equipment, horizontal transport vehicle equipment, and rail-mounted crane equipment are all equipped with equipment monitoring hardware, characterized in that... This automated diagnostic and decision-making system also includes: The exception configuration module is used to build an exception information knowledge graph, classify exception sources into quay crane system, rail gantry crane system and vehicle system, and match each exception with a corresponding exception level, preset handler role and standardized execution method library; The communication system, deployed in the automated container terminal, communicates with the server in the data center; The data interface layer includes a unified architecture communication module and a message transmission protocol module based on the dock industrial Ethernet, which are used to realize standardized data interaction between the control systems of various equipment and with the real-time monitoring module. The real-time monitoring module is used to collect physical status data, execute operation commands, monitor equipment status during operation, and detect abnormal operation information of individual equipment through the monitoring hardware of each device, including the quay crane equipment, horizontal transport vehicle equipment, and rail gantry crane equipment, and transmit equipment status and abnormal codes through the communication system. Includes a database / storage module for multidimensional related tables; The anomaly detection unit is used to acquire abnormal data collected by the real-time monitoring module and abnormal data of task execution of the equipment control system, and store the relevant data in a database / storage module including multi-dimensional association tables; The prompt module is used to generate and pop up an abnormal prompt interface in real time based on the multidimensional association table after an abnormality is identified. The interface integrates and displays the abnormality description, execution method guidance and processing cause analysis. The feedback elimination module is used to monitor the abnormal processing status. After identifying that the corresponding operation logic has recovered or the fault signal has disappeared, it automatically closes the prompt and records the closed-loop processing log.

2. The automated diagnostic and decision-making system for cross-system collaboration in container terminals according to claim 1, characterized in that, The anomaly level includes level IV, which has different triggering logic. Levels I-III are silent anomalies that the program can automatically attempt to recover from, while levels IV-V are obstructive anomalies that require manual intervention, and different levels are matched with different visual saliences. The preset personnel roles include at least equipment room maintenance personnel, information room system administrators, and central control group operators; The notification module automatically pushes information to the terminal of the corresponding role based on the type of the anomaly source.

3. An automated diagnostic and decision-making system for cross-system collaboration in a container terminal, applied to an automated container terminal management system architecture, the architecture including a real-time monitoring module, a communication system, a data interface layer, an equipment control system, an anomaly detection unit, and an alert module, characterized in that, This automated diagnostic and decision-making system includes: The anomaly knowledge graph construction module is used to store information about anomaly levels, information about the person who should make the suggestion, and information about standard execution methods. The intelligent diagnostic engine is used to match anomaly knowledge graphs with real-time data and generate decision recommendations.

4. The automated diagnostic and decision-making system for cross-system collaboration in container terminals according to claim 3, characterized in that, The anomaly knowledge graph construction module is also used to dynamically generate and update port knowledge graphs based on the operational data of the automated container terminal management system architecture, combined with the semantic understanding capabilities of large language models. The knowledge graphs contain information on port equipment, operational processes, personnel roles, and operating procedures. The intelligent diagnostic engine includes: The multi-source heterogeneous data fusion and analysis module is used to fuse and analyze multi-source heterogeneous data to obtain fusion analysis results. The anomaly detection module is used to identify potential anomalies in the fusion analysis results of the multi-source heterogeneous data fusion analysis module, and to transform the obscure low-level equipment code into standard operating instructions that include "suggested handlers" and "execution methods". The decision distribution module, based on the role definitions in the knowledge graph, directly distributes anomalies to the corresponding suggestion handlers, thereby achieving decentralized decision-making. The closed-loop management and automatic elimination module is used to sense the intervention results and automatically close the alarm window, forming a closed-loop management system.

5. An automated diagnostic and decision-making method for cross-system collaboration in container terminals, characterized in that, The method includes: S1: Establish an anomaly knowledge graph database: Based on the architecture of an automated container terminal management system, the sources of operational anomalies are divided into quay crane management system, rail gantry crane management system and vehicle management system. Anomaly codes are set for each type of anomaly, and anomaly level, anomaly description, suggested execution method, remarks and suggested handler are defined. S2: Real-time monitoring and anomaly capture: Real-time collection of the operational status data of the automated container terminal management system architecture and the operating status of individual equipment. When an inconsistency is detected between the operation task record and the physical feedback signal, the anomaly source data is captured. S3: Intelligent generation of abnormal information: Based on the captured abnormal source data, the abnormal knowledge graph is retrieved and matched to generate comprehensive abnormal prompt information including abnormal description, abnormal level, execution method, remarks, suggested handler and reason for handling; S4: Multi-terminal hierarchical push: Based on the role attributes of the suggested handler, the comprehensive abnormality prompt information is pushed and a pop-up prompt is displayed; S5: Anomaly Handling and Closed-Loop Elimination: Monitors abnormal states. For anomalies that can be automatically recovered by the program, the prompt is automatically eliminated after the fault signal disappears. For anomalies that require manual intervention, after the person handling the issue executes the corresponding execution method, the system verifies and restores normal operation, and the anomaly prompt is automatically eliminated.

6. The automated diagnosis and decision-making method for cross-system collaboration in container terminals according to claim 5, characterized in that, The definition of exception logic for the quay crane management system class includes: Driver's manual confirmation command failed: Driver's manual confirmation command failed; Automatic matching of work container WI failed: Work container WI could not be found; No task spreader with box: There is no work record, but the spreader is currently carrying a box. Manually unlock and place the box to the designated position. The lifting device was unlocked, but there are incomplete work task records: The lifting gear has been unlocked, but there are incomplete work tasks recorded, requiring manual confirmation that the loading and unloading operations are complete. Instruction timed out: The instruction timed out.

7. An automated diagnostic and decision-making method for cross-system collaboration in container terminals, characterized in that, The method includes: S100 monitors the operating status of quay crane equipment, rail-mounted gantry crane equipment, and vehicle equipment in real time, as well as abnormal events in the equipment control system. S200 detects and classifies abnormal events, and determines the level of abnormality; S300 generates standardized processing suggestions based on a pre-defined knowledge graph; S400 outputs decision instructions to relevant systems or operators.

8. The automated diagnosis and decision-making method for cross-system collaboration in container terminals according to claim 7, characterized in that, During the S100 process, real-time data is acquired from multiple data sources and standardized based on a unified object model; Between S100 and S200, the method further includes: S1001, knowledge graph construction: combining the semantic understanding capabilities of the large language model, dynamically generating and updating the port knowledge graph, and then executing S300; During the S200 process, deep learning algorithms are used to fuse and analyze multi-source heterogeneous data to identify potential anomalies. During the S300 process, the underlying device code is transformed into standard operating instructions that include the corresponding suggestion handlers and corresponding execution methods; During the S400 process, based on the role definition in the knowledge graph, anomalies are directly distributed to the corresponding suggestion handlers, thereby achieving decentralized decision-making; The method also includes: S500, executed after S400, automatically eliminates: the system can sense the intervention results and automatically close the alarm window, forming a closed-loop management.

9. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by the processor, it implements the steps of the automated diagnosis and decision-making method for cross-system collaboration in container terminals as described in any one of claims 5-8.

10. An electronic device, characterized in that: It includes a memory, a processor, and a computer program stored in the memory and executable by the processor, wherein the processor executes the computer program to implement the steps of the automated diagnostic and decision-making method for cross-system collaboration in container terminals as described in any one of claims 5-8.

Images