A situation interaction method, device and storage medium for multi-scenario scheduling of a marine ship

Abstract

The present application belongs to the technical field of ship human-computer interaction, and particularly relates to a situation interaction method and device for multi-scenario scheduling of a sea ship and a storage medium. User interaction behavior data at a current and historical set time is obtained to obtain a current user behavior sequence, the current user behavior sequence is converted into current behavior features, the current user behavior sequence is matched with a known behavior mode library, and / or the current user behavior features are input into an intention prediction model to obtain a user intention prediction result, a next interaction behavior of the user is predicted based on the predicted user intention, interface collaborative control is actively performed based on the predicted next interaction behavior of the user to perform the corresponding next interaction behavior in advance, and relevant information or interface controls are prepared in advance before the user explicitly proposes a demand, thereby reducing unnecessary operation steps, effectively reducing the operation amount, reducing the operation load of a scheduling personnel, and improving interaction efficiency.

Description

Technical Field

[0001] This invention belongs to the field of ship human-machine interaction technology, specifically relating to a situational interaction method, device and storage medium for multi-scenario scheduling of ships at sea. Background Technology

[0002] With the continuous advancement of digitalization and intelligentization of modern maritime equipment, the ship's departure scheduling, track monitoring, operational environment awareness, and mission support capabilities have a decisive impact on combat effectiveness. The ship's operating environment is characterized by rapidly changing situations, complex environmental factors, and long scheduling links, requiring ship command and operations support personnel to comprehensively analyze and judge large amounts of data within a short period. Current ship scheduling and situation display systems are mainly based on traditional graphical user interfaces (GUIs), using keyboard and mouse operation, and displaying various information such as track, sea state, and equipment status through several fixed-format interface modules. For example, Chinese patent application CN114546548A discloses a shipboard human-machine interaction method under system collaboration, including a situational awareness interface, a network topology interface, a network settings interface, a battlefield management interface, a command and control hierarchy interface, a formation situational awareness interface, and a threat list interface. The situational awareness interface includes a main situational awareness map, a vertical situational awareness map, detailed information on enemy targets, combat mission planning, ship weapon configuration, and ship sensor configuration information. The network topology interface includes global network status, network event logs, and alarm information. The network settings interface includes a list of nodes that have not passed authentication, single-node network status, and network settings. The battlefield management interface includes basic situational awareness map control, combat intent settings, decision distance settings, hotspot area settings, combat mission plan selection, and nautical chart display. The command and control hierarchy interface includes a command and control hierarchy tree diagram, hierarchy adjustment buttons, friendly combat unit information, and formation situational awareness information.

[0003] The aforementioned shipboard human-machine interaction methods can reflect network architecture and status, clearly demonstrate command hierarchy, and facilitate commanders in adjusting formation composition and command structure, meeting basic situational awareness requirements. However, they only support information display and passively respond to user operations. Situational interaction relies on human experience, requiring dispatchers to manually filter, compare, and judge various information before executing the next operation. This necessitates frequent information filtering and function selection by dispatchers in complex scenarios, resulting in high user workload and low human-machine collaboration efficiency. With the increasing number of ships, the diversification of operational scenarios, and the explosive growth of information dimensions, shipboard operational efficiency remains low, making it difficult to meet real-time operational needs. Summary of the Invention

[0004] The purpose of this invention is to provide a situational interaction method, device and storage medium for multi-scenario scheduling of ships at sea, so as to solve the problems of high user operation load and low ship operation efficiency in existing ship situational interaction.

[0005] To address the aforementioned technical problems, the first aspect of this invention provides a situational interaction method for multi-scenario scheduling of naval vessels, comprising: Acquire contextual data, which includes user interaction behavior data in the scheduling and control of naval vessels. The current user behavior sequence is obtained based on current and historical user interaction behavior data at a set time, and the current user behavior sequence is converted into current behavior features. The current user behavior sequence is matched with a known behavior pattern library, and / or the current user behavior features are input into the intent prediction model to obtain the user intent prediction result. Based on the predicted user intent, the user's next interaction behavior is predicted. The known behavior pattern library stores known behavior patterns mined from historical user interaction behavior data. The intent prediction model is trained on a machine learning model using user interaction logs from historical tasks. Based on predictions of the user's next interaction behavior, the interface is proactively coordinated and controlled to execute the corresponding next interaction behavior in advance.

[0006] In one possible implementation, the pattern matching process involves calculating the matching degree between the current user behavior sequence and known behavior patterns in a known behavior pattern library. If the matching degree is greater than a matching threshold, the user's intent is predicted based on the known behavior pattern.

[0007] In one possible implementation, interface collaborative control includes interface actions, data preparation, and interaction path optimization; data preparation includes preloading data, which refers to acquiring prediction-related data in advance and loading the parameter panel in advance so that it responds instantly when the user views it; interface actions include actively expanding the view based on the prediction results and actively prompting functions; interaction path optimization refers to providing results directly without intermediate steps based on the prediction results.

[0008] In one possible implementation, the method further includes inputting a context vector into a context reasoning model and outputting an interface adjustment scheme; wherein the context vector is obtained by fusing context features; the context features include at least two of the following: task stage features, dynamic situation features, environmental risk features, and user behavior features; the task stage features include a ship task stage label determined based on the relationship between the current time and the task plan; the dynamic situation features include the ship motion change rate calculated based on ship navigation data; the environmental risk features include the current environmental risk level determined based on environmental data, including sea state and external threat level; the context reasoning model includes a rule engine and a machine learning model, wherein the context vector is first input into the rule engine, and if the context vector conforms to a specific rule, the corresponding interface adjustment scheme is output; otherwise, the context features are input into the machine learning model to output the interface adjustment scheme.

[0009] In one possible implementation, the method further includes anomaly detection, which is determined based on an anomaly detection model consisting of Kalman prediction, anomaly detection, and rule verification. Kalman prediction is used to predict the ship's position. If the residual between the predicted ship position and the actual monitored ship position is greater than or equal to the residual threshold, the motion feature vector of the track point is obtained as the trajectory feature vector. The trajectory feature vector is evaluated based on the historical normal trajectory feature set to determine whether the trajectory point is an anomaly and the severity level corresponding to the anomaly. Then, the anomaly type is judged based on preset rules, and finally an anomaly event object is generated. The anomaly event object includes the ship ID, anomaly type, occurrence time, location, and severity level.

[0010] In one possible implementation, the method further includes listening to user interactions on the view. When the user performs a selection or click operation on any view, the method queries the semantic mapping table for related data in other views using an index, and controls other views to jump to or highlight the related data based on the query results. The semantic mapping table establishes a mapping relationship between elements of different views, and the index fields include view type, element identifier, and a list of associated target view element identifiers. View types include track view, mission timeline view, ship status view, and environmental risk event view.

[0011] In one possible implementation, the method further includes determining the corresponding semantic level based on the detected current scaling ratio, automatically switching the display of information at the corresponding semantic level, and pre-storing data at different semantic levels in layers; the semantic levels include at least two of the following: global level, regional level, ship level, and parameter level; global level information includes the overall course of navigation in the sea area, ship distribution, and route planning; regional level information includes ship relationships, heading arrows, and local sea state changes within a local sea area; ship level information includes the specific course, speed changes, and mission phase of a single ship; and parameter level information includes ship-related engineering data.

[0012] In one possible implementation, the method further includes, if an out-of-view event is detected, calculating the azimuth angle and distance of the out-of-view event relative to the center of the view, determining an indicator style based on the type of out-of-view event, determining the position of the indicator on the view boundary based on the azimuth angle, determining indicator attributes based on the distance, and displaying the indicator on the view based on the indicator style, the position on the view boundary, and the attributes; the indicator style is an indicator shape or a combination of indicator shape and color, and the indicator attributes are color intensity or indicator size.

[0013] To address the aforementioned technical problems, a second aspect of the present invention provides a situational interaction device for multi-scenario scheduling of naval vessels, comprising a processor and a human-computer interaction interface, for implementing the steps of the method described above.

[0014] To address the aforementioned technical problems, a third aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described above.

[0015] The beneficial effects of this invention are as follows: This invention learns user interaction behavior patterns, mines known behavior patterns from historical user interaction behavior data, or uses user interaction logs from historical tasks to train a machine learning model to obtain an intent prediction model. Through pattern matching and / or model prediction, it predicts the potential operational intent of dispatchers in advance. Based on the predicted user intent, it predicts the user's next interaction behavior, thereby proactively providing decision support and interface assistance. It prepares relevant information or interface controls in advance before the user explicitly raises a request, thereby reducing unnecessary operation steps, effectively reducing the amount of operation, reducing the operational load of dispatchers, improving efficiency, and reducing the risk of missing key steps under high pressure, thus achieving true human-machine integrated decision support. Attached Figure Description

[0016] Figure 1 This is a flowchart of the intent prediction process of the present invention; Figure 2 This is a flowchart of the multi-source contextual information semantic fusion process of the present invention; Figure 3 This is a flowchart of the multi-view semantic linkage of the present invention; Figure 4 This is a flowchart of the semantic scaling process of the present invention; Figure 5 This is a flowchart of the out-of-view event notification method of the present invention; Figure 6 This is a flowchart of the interface adaptive layout adjustment process of the present invention; Figure 7 This is a flowchart of the abnormal event detection process of the present invention; Figure 8 This is a schematic diagram of the situational interaction device for multi-scenario scheduling of ships at sea according to the present invention. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of the present invention clearer, the specific embodiments of the present invention will be further described below with reference to the accompanying drawings.

[0018] This invention enables interactive intent recognition for proactive interface collaborative control, presents ship status through multi-view linkage, promptly detects risks through spatially directional out-of-view situational event prompts, adaptively adjusts the interface through contextual reasoning, displays information at different levels through semantic scaling, and determines the type and severity of anomalies through anomaly detection. It can provide commanders with sufficiently efficient, reliable, and intelligent situational awareness capabilities, thereby improving the overall operational efficiency and safety performance of situational interaction.

[0019] Implementation of Situational Interaction Methods for Multi-Scenario Dispatch of Ships at Sea This invention provides a situational interaction method for multi-scenario scheduling of maritime vessels, applied to maritime vessel operation and scheduling management scenarios. The method includes intent prediction, used to continuously analyze behavioral patterns during user-device interaction, predict the next intent, and collaboratively provide interface assistance. The intent prediction process is as follows: Figure 1 As shown, it includes the following steps: 1. Data acquisition and preprocessing.

[0020] Contextual data is acquired, including user interaction behavior data in maritime ship scheduling and control. This data is recorded in user operation logs, which can be captured through the front-end interface (human-computer interaction interface). User interaction behaviors include clicks, switching, pauses, selections, and inputs, such as mouse click coordinates, view switching records, view pauses, and abnormal keyboard input query events. User interaction behavior data includes the frequency of interaction behaviors, the types of views the user focuses on, the order of view switching, and the distribution of mouse clicks. This data serves as the raw input for user behavior analysis.

[0021] Preprocessing includes smoothing and noise reduction. For example, irrelevant mouse movements are filtered out, retaining only valid click sequences.

[0022] 2. Based on current and historical user interaction data at a set time, obtain the current user behavior sequence and convert the current user behavior sequence into a current behavior feature vector.

[0023] To improve online matching efficiency, known behavioral patterns can be organized into a Trie tree, or a dynamic time window can be used to increase matching speed. For example, a sliding time window that records the N most recent user interactions can be used to determine the current user behavior sequence.

[0024] Since N is too small to represent the pattern, and too large to increase noise, this invention experimentally selects a sliding window of size N = 5-7 steps as the behavior sequence length to balance real-time performance and pattern stability.

[0025] For example, with N=5, the recorded user interaction behaviors are: "Click on the ship list → Switch to map view → View parameter panel → Switch to map view → Click on a waypoint". Whenever a user has a new interaction, the earliest interaction is discarded and the new interaction is added to form a new behavior sequence, and the current behavior feature vector is calculated. The behavior feature vector is updated after each user interaction to prepare for prediction.

[0026] Time-series user behavior data is transformed into behavioral feature vectors through feature extraction. These behavioral feature vectors include interaction frequency, dwell time, and query frequency.

[0027] 3. Perform pattern matching between the current user behavior sequence and a known behavior pattern library, and / or input the current behavior feature vector into the intent prediction model to obtain prediction results, including user intent prediction results.

[0028] First, the current user behavior sequence can be matched with a known behavior pattern library. If no known behavior pattern is matched, the current behavior feature vector can be input into the intent prediction model to obtain the prediction result.

[0029] Alternatively, the current user behavior sequence can be matched with a known behavior pattern library to obtain a prediction result, and the current behavior feature vector can be input into the intent prediction model to obtain a prediction result. The user intent prediction result can be determined by combining the two prediction results.

[0030] Pattern matching: The current user behavior sequence is matched against a known behavior pattern library in real time, and the matching degree is calculated. If the matching degree between the current user behavior sequence prefix and the known behavior pattern is greater than the matching threshold, it means that the current user behavior sequence is highly consistent with the known behavior pattern. Then, the user's intent is predicted based on the known behavior pattern, and the user's next interaction behavior is predicted based on the user's intent.

[0031] For example, if a user's behavior sequence detects that they switch to the risk event list multiple times in a short period of time, and the pattern matches the pattern "the user may be looking for risk events that have not yet appeared," then it is inferred that their intention is to pay attention to potential risks.

[0032] For example, if the pattern matching result indicates that "the user is repeatedly checking the ship's attitude and trajectory, possibly focusing on landing stability," then the predicted intent is "check landing parameters." It also suggests possible next steps, such as "the approach window is likely required."

[0033] The known behavior patterns in the known behavior pattern library are typical behavior patterns mined from historical user interaction data. Specifically, high-frequency subsequences can be identified by offline analysis of large amounts of user operation logs using sequence pattern mining algorithms (such as PrefixSpan), and then converted into intent patterns. Each pattern is associated with a hypothetical intent label, set by experts or based on task flow.

[0034] The known behavior pattern library can be updated regularly, for example, by mining new patterns from user operation logs every week or every 50 tasks, to ensure synchronization with the latest user habits.

[0035] Model prediction: Input the current behavior feature vector into the pre-trained intent prediction model to identify and predict intent, and output the user intent prediction result and the next interaction behavior.

[0036] The intent prediction model employs machine learning algorithms. To meet the requirements of real-time performance and interpretability, lightweight machine learning algorithms are preferred, such as first-order Markov chains or Hidden Markov Models (HMMs) to predict user intent and the next possible action. Alternatively, classification models such as decision trees or random forests can be used to predict the information categories that the user may be interested in based on the context of the current user interaction behavior.

[0037] A pre-trained intent prediction model is used to classify the current behavior feature vector and output the most likely intent label, i.e., the user intent prediction result. For example, a multi-class classifier can output labels such as "browse the situation overview", "check for anomalies", "view details of nearby conflicts" or "plan a new route".

[0038] Naive Bayes can be used to calculate the posterior probability of each predicted intent, and the predicted intent with the highest posterior probability can be selected as the final output user predicted intent.

[0039] Using user interaction logs from multiple historical tasks as samples, typical behavioral sequences from these samples are learned to train a machine learning model, resulting in an intent-trained model. For example, by clustering common user behavior sequence patterns, the behavioral pattern of "viewing flight path → checking attitude → paying attention to maintenance parameters" is identified, and the trained model recognizes this as an intent chain. When the next user interaction behavior sequence matches the first half of this chain, it can be predicted that the user may need subsequent maintenance parameter information.

[0040] 4. Based on the prediction of the user's next interaction behavior, proactively coordinate the interface to execute the corresponding next interaction behavior in advance.

[0041] Interface collaborative control includes interface actions, data preparation, and interaction path optimization.

[0042] Data preparation includes preloading data: acquiring prediction-related data in advance and preloading parameter panels for instantaneous user response. For example, if it's predicted that a user will view details of a specific ship, the ship's detailed information and performance data are silently read from the backend database, and the ship's parameter panel (which is hidden and ready) is preloaded so that it responds instantly when the user actually clicks on it. If it's predicted that the user will next monitor a risk event, i.e., switch to video monitoring view, the corresponding video stream is buffered beforehand.

[0043] Interface actions include interface prompts and automatic expansion, meaning that views are proactively expanded and functions are proactively prompted based on prediction results: if it is predicted that the user will need a certain view or function, it will proactively expand or prompt them. For example, if it is predicted that the user will monitor risk events next, a recommendation window will automatically pop up listing the risk events that have not yet been viewed for the user to click on with one click. If it is detected that the user switches between the situation map and the anomaly list multiple times, inferring that they are looking for the cause of the anomaly, the "Anomaly Details" panel will be automatically opened for them to view. When it is predicted that they may need to view the list of nearby vessels, a thumbnail window of the list will pop up at the edge of the interface as a recommendation. If it is predicted that the user may adjust the route, the route editing tool button will be highlighted or the planning interface will be opened directly for confirmation.

[0044] Optimize the interaction path: Based on prediction results, bypass intermediate steps and directly provide the result. For example, if we guess that the user wants to find the trajectory of a ship, we can automatically filter and highlight that ship's trajectory on behalf of the user. If we predict that the next action (user interaction behavior) is to click "zoom in on a certain area," we can pre-shift the map slightly (make minor adjustments) when the user moves the mouse to the edge of the map to match the user's intention.

[0045] Preferably, the present invention further evaluates the confidence level of the user intent prediction result and assigns a confidence score (such as confidence level or probability) to the user intent prediction result. If the confidence score is less than or equal to a confidence threshold, interface collaborative control is not actively performed, and active collaboration is abandoned to avoid disturbance; if the confidence score is greater than the confidence threshold, interface collaborative control is actively performed. For example, the confidence threshold is set to 0.8, and interface collaborative control is only actively performed when the confidence score of the user intent prediction result is greater than 0.8.

[0046] Confidence scoring and setting confidence thresholds are used to determine whether to prematurely execute UI collaborative actions, thus avoiding excessive interference. To prevent accidental premature execution of UI collaborative actions, a larger confidence threshold can be set. A certain delay is also allowed to observe further user behavior for confirmation; for example, the collaborative action is only executed if two consecutive steps are met, thus reducing interference from misguesses.

[0047] The intent prediction model also adaptively learns based on user feedback. After an interface-based collaborative action is executed, user acceptance is observed. If the user immediately uses the pop-up recommendation window, the prediction is correct; if the user closes or ignores it, the prediction has not met expectations. If the user's actual next action differs from the prediction, this is also recorded to enrich the sample and continuously improve prediction accuracy. For example, if the prediction is correct, the user directly uses the system-provided interface, reducing search and click steps; if the prediction is incorrect, the user can ignore or close the recommendation window, and feedback is recorded to improve the model. Based on this user feedback data, pattern weights or model parameters are adjusted to adapt to user preferences. If a certain intent is predicted multiple times but the user does not use it, the confidence weight of that pattern is reduced; conversely, if the user frequently uses the recommendations, the corresponding pattern weight is strengthened. Through continuous learning, the intent prediction model becomes increasingly aligned with individual user habits.

[0048] By learning user interaction patterns, the system anticipates dispatchers' potential operational intentions and provides interactive recommendations. It proactively offers decision support and interface assistance, preparing relevant information or interface controls before users explicitly state their needs. This intelligent human-machine collaborative interaction reduces unnecessary operational steps, allowing users to experience proactive assistance. For example, the interface automatically switches when needed, or recommended information is readily available, enabling tasks to be completed with fewer mouse clicks. This collaboration is naturally integrated into the human-machine interaction process, making the device more intelligent and user-friendly, rather than disruptive. Through long-term learning of the intent prediction model, the effectiveness of human-machine collaboration continuously improves, allowing the device to gradually understand the habits of specific dispatchers. During intensive tasks, the device's advance recommendations can effectively reduce the amount of operation by 20-30%, not only improving efficiency but also reducing the risk of missing critical steps under high pressure, achieving true human-machine integrated decision support.

[0049] 5. Combine current context vectors to help predict user intent.

[0050] The current context vector can be used to help predict user intent. It can also be combined with user preference profiles to further aid in predicting user intent. User intent can be predicted by combining user preference profiles, current context vectors, and current behavioral feature vectors. For example, when an urgent event (i.e., contextual data) is pushed to the backend, the system senses the urgency of the task and believes that the user needs to prioritize it. It will then issue reminders for a series of actions related to handling this task, thereby helping to predict user intent. Examples include: out-of-view warnings and adaptive page changes.

[0051] like Figure 2 As shown, the current context vector is determined by fusing context features extracted from the current context data. Ship operations involve multi-source data such as tracks, weather, missions, equipment, and users. These data have different formats and numerous dimensions. Therefore, this invention fuses the massive heterogeneous data involved in ship operations into a context vector.

[0052] Correspondingly, key characteristic indicators that can characterize the current situation are extracted from the real-time data of various source sensors and devices, namely current situation data. The situation data also includes at least one of ship navigation data, environmental data and mission plan data, and may also include ship maintenance support data.

[0053] Ship navigation data includes speed, heading, track position coordinates, and mission status indicators. Track position coordinates (latitude and longitude), speed, and heading are provided by AIS sensors; for example, each ship outputs current ship navigation data every second.

[0054] Environmental data, including sea state and external threat levels, includes wave height, wind speed, wind direction, humidity, and visibility levels. Sea state data can be provided by shipboard meteorological sensors or shore-based meteorological stations.

[0055] Task planning data, including task category, planned time schedule (i.e., task time window), task priority, and planned route, is provided by the task management system.

[0056] Ship maintenance data, including port berthing information, power system status, and electrical equipment status, is provided by the shipboard equipment monitoring system.

[0057] The aforementioned multi-source heterogeneous contextual data undergoes preprocessing, including time synchronization, spatial coordinate unification, data filtering and cleaning, and normalization. Preprocessing eliminates dimensional differences and noise interference, ensuring that data from different sources can be directly fused and compared.

[0058] Time synchronization: Aligning the timestamps of contextual data to a unified timeline. Specifically, using a unified system clock to timestamp data from different sources aligns asynchronous data streams. For example, using the Network Time Protocol (NTP) to synchronize the time of various data sources, maintaining a buffer, and interpolating / aligning sensor data to a common timeline in second-level or finer time steps. For data with significant frequency differences, linear interpolation or last-value holding is used to fill gaps, ensuring a value in every time unit.

[0059] Spatial coordinate unification: Unify the geospatial coordinates of contextual data to a unified coordinate system. This could involve converting all data to WGS84 latitude and longitude or a projected coordinate system. While the WGS84 geographic coordinate system is used by default to represent global locations, for ease of map projection calculations, WGS84 latitude and longitude can be further converted to local planar projected coordinates (such as Mercator projection or UTM coordinates). For example, for dispatching data centered on a specific sea area, the Mercator projection along the central meridian of that area can be selected, converting latitude and longitude to planar metric coordinates for map display and distance calculations. The ship's own local coordinates (such as those relative to its own coordinate system) are also converted to a globally unified coordinate system to facilitate data alignment across multiple ships.

[0060] Data filtering and cleaning: Noise and outliers in sensor data are filtered out. For example, Kalman filtering is used to smooth the latitude and longitude of the track position, filtering out GPS jitter. A sliding window is used to apply mean or median filtering to instantaneous spikes in sea state data. Clearly unreasonable data points (such as sudden negative velocity or exceeding physical limits) are marked as outliers and either removed or replaced with neighboring values. Missing ship navigation data is filled using interpolation or the last valid value.

[0061] Normalization: Converting data from different sources to a unified unit and dimension. For example, speed is standardized to knots, distance to nautical miles, and temperature to degrees Celsius. Then, numerical features are standardized for subsequent fusion calculations. For example, Min-Max normalization or Z-score normalization can be used to scale each feature to the 0-1 range. The Min-Max normalization method is as follows: Given a parameter with a physically reasonable range [min, max], the standardized value = (original value - min) / (max - min). For example, speed 0-60 knots is normalized to 0~1, and wave height 0-15 meters is normalized to 0~1. For parameters without a fixed range (such as wind direction 360°), periodic processing (such as sin / cos encoding) can be used.

[0062] Preprocessing may also include structured encapsulation: organizing the data obtained above into a unified data structure to obtain a comprehensive situational data object. For example, a comprehensive situational data object (global status snapshot) can be generated every second, including fields such as ship IDs and navigation status lists, current environmental parameter values, task queue status, and user operation status summary. Alternatively, multiple synchronously updated data tables (track table, environment table, task table, and user operation status table, etc.) can be maintained and linked by timestamps.

[0063] The preprocessed contextual data adopts a unified time base, a unified spatial reference, is free of significant noise anomalies, and has a consistent data format. The standardized preprocessed data is broadcast to downstream modules via a data bus interface. A publisher / subscriber model is used, with the context fusion module subscribing to the required data topics (such as flight track data and environmental data), and pushing new data to subscribers whenever it arrives. This ensures that the context fusion module can obtain the latest fusion input in a timely manner. Simultaneously, the data storage submodule writes key data to the database for offline analysis or anomaly backtracking.

[0064] Semantic features are extracted from the preprocessed contextual data to obtain a contextual feature set. The contextual feature set is then fused to obtain a contextual vector. Contextual features include at least one of the following: task stage features, dynamic situation features, environmental risk features, and user behavior features.

[0065] The mission phase characteristics are ship mission phase labels determined based on the relationship between the current time and the mission plan, including cruise, return to port, combat, and standby. For example, if the current time is within the time period of ship A's planned mission route, its mission phase is marked as "performing a mission"; if it has exceeded the planned return time, it is marked as "delayed return".

[0066] Dynamic situational characteristics include the rate of change of ship motion calculated based on ship navigation data. This rate of change includes the rate of change of course and the abrupt change in speed. Dynamic situational characteristics also include inter-ship situational relationships, which include the rate of change of distance between a ship and its nearest neighbor, used to detect emergency maneuvers or relative motion situations. The rate of change of course is the angle of change of course over a first set time interval (e.g., the angle of change of course within the last 5 seconds, i.e., rate of change of course = |current course - average course over the last 5 seconds|, which needs to be normalized before calculation). The abrupt change in speed is the difference between the current speed and the average speed over a second set time interval.

[0067] Environmental risk characteristics are based on the current environmental risk level determined by environmental data. This includes: determining the sea state risk level based on wave height and wind speed; determining the wave fluctuation risk level based on the wave height change rate over a third set time period; and determining the visibility risk level based on visibility data. For example, when the wave height is greater than the first height threshold and the wind speed is greater than the first wind speed level threshold, the sea state is considered high-risk. When the wave height change rate over the third set time period exceeds the wave height change rate threshold, the sea state is considered high-wave fluctuation risk. When visibility is lower than the visibility threshold, the sea state is considered low-visibility risk. For example, if the first height threshold is set to 4 meters and the first wind speed level threshold is set to level 7, a wave height > 4 meters and a wind speed > level 7 indicates a high-risk sea state. When the wave height change rate over the past 5 minutes exceeds the wave height change rate threshold, the sea state is considered high-wave fluctuation risk. When visibility is less than 1 kilometer, the sea state is considered low-visibility risk. The environmental risk level can also be a weighted sum of various environmental variables to form a 0-1 environmental risk index.

[0068] User behavior characteristics are semantic descriptions of a user's current interaction state. Examples include the user's recent focus (the currently viewed primary view), operation frequency, and operation rhythm. The currently viewed primary view is the view module ID where the user spends the most time, and operation frequency can be quantified as the number of clicks per unit of time. These reflect the user's attention focus and interaction pressure.

[0069] The extraction of various contextual features can be achieved through rules or simple algorithms. These contextual features are mid-to-high-level features with semantic meaning; for example, a high rate of change in heading indicates a situation of frequent maneuvers. The contextual feature set can be used for log display, allowing operations and maintenance personnel to intuitively understand the current situation perceived by the system (assisting in debugging and optimizing rules). The extracted contextual features are combined to construct a contextual feature set, which is then further fused into a contextual vector. The contextual vector is a fixed-length numerical vector that condenses the key information of the current scheduling situation. For example, the contextual vector is formed by numerical encoding of [task = cruise, risk = 0.8, user attention = track map, dynamic situation = frequent maneuvers, ...].

[0070] To improve real-time performance, all context features can be concatenated to form a context vector, or weights can be assigned to different categories of context features and then weighted to obtain the context vector. The dimensionality is determined based on the number of features (the context vector in this invention is approximately 20-30 dimensions, with important feature dimensions selected through optimization).

[0071] For example, contextual features can be concatenated in a fixed order to form a contextual vector. First, the dimensions and composition of the contextual vector are determined: 3-dimensional task-related features (one-hot encoding of task stages + task delay indicators, etc.), 3-dimensional environmental risk features, 3-dimensional user behavior features, and several dimensions of dynamic situational features. Each group is normalized and then concatenated to obtain the contextual vector. For example, when calculating the contextual vector using weighted fusion, task stage features are encoded, such as using one-hot encoding (cruising = 100…0, returning = 010…0, etc.). Environmental risk features are obtained by weighted summation of multiple environmental parameters. User behavior features can be converted into user operation intensity. Initial weights can be set based on experience (e.g., task stage features, environmental risk features, and user behavior features each account for 0.4 / 0.3 / 0.3 weights), and the weights are adjusted through learning during operation.

[0072] To balance the importance of information from different sources, an adaptive weighting mechanism from machine learning is used to obtain the context vector. For example, a multi-head attention mechanism is used to automatically learn the weights of context features from each source, assigning higher weights to important context features. For instance, if the current task stage is combat, task-related features have higher weights, followed by user behavior features; conversely, in training mode, user behavior features are more important. Specifically, the extracted context features are input into a multi-head attention fusion layer, where each head processes one type of feature (task / environment / user, etc.) and calculates a weighted representation. Finally, the parts are concatenated and passed through a fully connected layer to obtain a fixed-length context vector. This method originates from multi-source context awareness research and can effectively integrate heterogeneous context information into a unified representation.

[0073] If machine learning methods are employed, trained weights can be used to perform linear combinations or nonlinear dimensionality reduction on each dimension to highlight key information. For example, principal component analysis (PCA) can be used to compress contextual features and remove redundant and related information. For real-time systems, this invention primarily focuses on deterministic rule fusion to ensure interpretability and efficiency.

[0074] To ensure that the situation vector reflects the current state in real time, it can be updated periodically. The period can be set according to the device's performance, for example, recalculating once per second. Alternatively, the situation vector can be updated immediately when any significant situational feature change meets the update requirements, such as when the speed change exceeds a set threshold or when the mission phase changes.

[0075] Contextual semantic fusion provides a unified foundation of current situational data, enabling subsequent functions to make decisions based on the same contextual understanding. This achieves unified encoding of contextual features such as task stage, environmental conditions, and user status, facilitating real-time adaptive adjustments to the interface and alarms. Through the aforementioned semantic fusion model, massive amounts of heterogeneous data can be transformed into contextual semantic representations that can be used for reasoning and decision-making, possessing the ability to understand the current comprehensive situation.

[0076] 6. Multi-view semantic linkage.

[0077] In existing ship dispatching systems, different types of information are scattered across multiple views such as track charts, task lists, and operation panels. Users need to frequently switch windows to remember information, and the fragmentation of cross-view data leads to slow situational awareness, resulting in high cognitive load and susceptibility to misjudgments. Therefore, the situational interaction method for multi-scenario dispatching of ships in this invention also includes multi-view semantic linkage to achieve coordinated display of multiple views in the ship dispatching interface. Each relevant view is updated synchronously during user interaction, thereby eliminating information silos. That is, when a user selects information in any view, other relevant views can automatically locate the corresponding content, thus providing a consistent global situational awareness. Through multi-view association, the cognitive load of cross-view information comparison is reduced. The multi-view semantic linkage process is as follows: Figure 3 As shown, it includes: Listen to user interactions on the view. When a user makes a selection or click on any view, query the semantic mapping table for related data in other views, and control other views to navigate to or highlight the related data based on the query results.

[0078] View types include track view, mission timeline view, ship status view, and environmental risk event view. User selection or click operations on any view include, but are not limited to: clicking a ship track point in the track view, selecting a time interval in the mission timeline view, selecting a ship entry in the ship status view, and selecting an abnormal event in the environmental risk event view. These operations are captured by the front-end UI controls and passed to the linkage mechanism.

[0079] The semantic mapping table is pre-established according to business rules during device initialization, and can be dynamically maintained during operation, recording the semantic correspondence relationships across views. It can be implemented by using a hash table or a database to create an index, and the search efficiency is preferably in the millisecond level to support real-time linkage. The message linkage delay needs to be controlled within 100 milliseconds to ensure user perception synchronization. The semantic mapping table establishes mapping relationships for elements in different views, such as storing the corresponding relationships of "track node ID → timestamp → ship status → environmental event number" in the mapping table. For example, the index fields of the data structure of the semantic mapping table include view type, element identifier, and a list of associated target view element identifiers. The unique identifier format for each type of view element (such as the track point ID format and the risk event identifier format) needs to be uniformly defined to ensure the consistency of cross-module identification. The linkage mechanism receives user operation events (including operation type and corresponding element identifier), queries the other target view element IDs associated with this element identifier in the semantic mapping table according to the operation view type and the corresponding element identifier, generates corresponding view update instructions based on the query results. Each view update instruction contains the target view identifier and the operations / parameters to be executed. After receiving the view update instructions, each target view performs the corresponding update to achieve synchronous jump and highlighting display of other views.

[0080] For example, if the user operation is to click on the track point with ID = Pt128, the corresponding information is: Pt128 is mapped to the time T = 10:35:20 on the timeline (track point timestamp), and the ship ID = Ship07 in the ship status view (the ship to which this point belongs), etc. View update instructions are generated based on the query results, such as "task timeline view → locate to T = 10:35:20" and "ship status view → highlight Ship07". The view update instructions are broadcast and sent through the bus or directly called by the centralized controller to the corresponding view interface. After receiving the instructions, each target view performs the corresponding update: the task timeline view scrolls to select this time point or segment according to time T (a pointer can appear on the timeline); the ship status view searches for the current status data according to the ship ID and highlights it (such as flashing the background of the row of this ship). If the target view is not currently open, it will be automatically switched to this view or the associated information will be presented in a pop-up window to ensure that the user can immediately see the relevant content. Record the occurrence of cross-view linkage (for example, record it in the user operation log for intention prediction analysis). If no association is found (a very rare situation, such as data out-of-sync), a no-association prompt can be given.

[0081] To improve the real-time performance of linkage, when a user operation is monitored, the other target view element IDs associated are found in the semantic mapping table, and a linkage event is generated based on the query results. The front end propagates the linkage event (including view update instructions) through the event bus. Each view locates and renders relevant information according to the element identifier in the event content to complete multi-view linkage. The entire process ensures that the contents of multiple views are always synchronized through a unified semantic index.

[0082] Multi-view semantic linkage allows users to automatically find and display relevant information in other views while operating in one place, avoiding the need for manual searching and comparison across multiple windows. From the user's perspective, after operating on one view, other views automatically switch to the corresponding content. For example, when a user clicks on an inflection point on a track chart, the timeline on the right automatically jumps to that time, and the table view below locates the ship's status row at that moment, forming a synchronized presentation of multiple perspectives. In effect, this significantly reduces the time cost of switching between cross-view perceptions and improves the consistency and accuracy of situational understanding.

[0083] 7. Semantic scaling.

[0084] The situational interaction method for multi-scenario scheduling of ships at sea, as proposed in this invention, also presents information at different granular levels according to the zoom ratio when the user views the view, helping the user to quickly switch between macro-level situation and micro-level details.

[0085] Zooming operations include scrolling with the mouse wheel, zooming with two fingers on the touchscreen, or tapping the zoom button. Zooming operations cause a change in the zoom ratio Z. Assuming the initial map zoom Z=1, a new Z value (magnification) is obtained when zooming is triggered. For example... Figure 4 As shown, the corresponding semantic level is determined based on the detected current zoom level, and the information at the corresponding semantic level is automatically switched and displayed. Semantic levels include at least two of the following: global, regional, ship-level, and parameter-level. Global-level information includes macroscopic information such as the overall course of navigation in the sea area, ship distribution, and route planning. Regional-level information includes information such as ship relationships within a local sea area, heading arrows, and local sea state changes. Ship-level information includes detailed information such as the specific course, speed changes, and mission phases of individual ships. Parameter-level information includes ship-related engineering data, such as propulsion system parameters, steering gear angles, and vibration stress data.

[0086] By designing scaling ranges for different semantic levels, the semantic level to which the current scaling ratio belongs is determined. For example, 1.2, 2.0, and 3.0 are selected as thresholds for each range, and these thresholds are determined through interface testing to ensure that information at each level appears at an appropriate scale, avoiding premature or delayed display. For instance, when Z < 1.2, global-level information is presented; when 1.2 ≤ Z < 2.0, regional-level information is presented; when 2.0 ≤ Z < 3.0, ship-level information is presented; and when Z ≥ 3.0, engineering parameter-level information is presented. ZWhen crossing thresholds of 1.2, 2.0, and 3.0, semantic level switching is required. For example, when a user zooms in from a global view to a local view (Z increases from 1.1 to 1.5), if Z exceeds the 1.2 threshold, a detailed list of ships, heading vectors, and local weather information for that area is automatically loaded from the server or cache, replacing or supplementing the original global information. The information rendering engine adjusts the display elements (such as icon size and label content) according to the activated level template. When the user continues to zoom in to the ship level, the above process is repeated to load more granular individual ship data. This ensures a smooth transition during zooming, with old information fading out and new information highlighting during level switching, maintaining interface consistency.

[0087] This design ensures that semantic information is automatically added or removed when zooming to different semantic levels, without requiring manual switching by the user. Map content changes automatically based on the zoom level; for example, more detailed indicators appear when zoomed in, and summary symbols are used when zoomed out. Semantic scaling is achieved by predefining different information layers or drawing rules for each level. GIS multi-layer technology is used to store data of varying precision. When a zoom event is triggered, the corresponding layer is activated and other layers are disabled based on the current Z-axis, enabling information to update adaptively with scale. If the information to be displayed is cached in the preprocessing stage, it can be retrieved directly; otherwise, a background service is called to retrieve it on demand. For example, higher-resolution nautical chart data for the area can be obtained through a GIS service interface, and the most recent trajectory details of relevant ships can be retrieved through a database query. Then, the visualization rendering module is called to draw these newly added information layers on the map (such as displaying partial segments of each ship's track and marking heading arrows, drawing local weather symbols at the boundaries of the area, etc.). Simultaneously, information at the previous level is processed: if switching from a global level to a regional level, it may be necessary to remove or dilute global layer information (such as hiding markers of other distant ships and only retaining ships within the region to avoid clutter). For the new hierarchical levels, adjust the symbol styles and layouts of the maps. For example, at the regional level, medium-sized icons might be used to display ships, with name labels added; at the ship level, large icons would be used with detailed data labels. Apply visual coding schemes for different scaling levels using style templates, adjusting text label density to avoid being too dense or too sparse. If necessary, semantic scaling animations can be used for smooth transitions: for example, gradually adding or removing elements, rather than switching abruptly, to maintain visual continuity.

[0088] To ensure performance, data at different levels can be pre-stored in layers. For example, the global layer contains a large amount of data but is simplified (only key waypoints are retained), while the local layer contains detailed data but has a limited scope. This way, only the necessary portion of the current layer is processed at a time. Map rendering is accelerated using the GPU, allowing for the simultaneous rendering of multiple layers. Through this semantic scaling, the system achieves progressive detail display of points of interest with scale, matching information density to the view range and effectively improving the efficiency and completeness of users' browsing of situational information.

[0089] If zooming leads to focusing on information at a specific ship level, the information range of other related views can be adjusted synchronously. For example, when the map focuses on the parameters of a single ship, the timeline view is also filtered to only include the time event range of that ship, ensuring consistency across multiple views. In this case, the linked events are triggered by zooming. Due to dynamically loaded information, reasonable caching and preloading strategies need to be set to ensure no noticeable lag when zooming near a threshold. For example, adjacent level data can be preloaded, and preparation for the next level data can begin when Z approaches the threshold, achieving a level switching time of less than 0.5 seconds. Through semantic zooming, the system can improve information retrieval efficiency by approximately 35%.

[0090] 8. Off-field event detection and spatial pointing prompts.

[0091] The situational interaction method for multi-scenario dispatching of naval vessels of the present invention also includes out-of-view event detection and spatial direction indication. This enhances the dispatcher's ability to perceive important situational events outside their field of vision. Even if a critical event occurs outside the current map view, the system can provide clear direction and distance indications, ensuring that the user does not miss any potential threats or important information.

[0092] like Figure 5 As shown, when an event is detected, such as an anomaly or other event, each event includes attributes such as location (coordinates), type, and importance. It is determined whether the event location is outside the current view's visible range; if so, it is classified as an out-of-view event. The azimuth and distance of the out-of-view event relative to the view center are calculated. The indicator style is determined based on the out-of-view event type, the indicator's position on the view boundary is determined based on the azimuth, and the indicator attributes are determined based on the distance. Based on the indicator style, its position on the view boundary, and its attributes, the indicator is displayed on the view, pointing to the location of the out-of-view event; for example, the indicator is placed at the intersection of the azimuth and the viewport boundary.

[0093] Indicator styles are defined by their shape (such as a ring indicator or a pointing arrow) or a combination of shape and color, differentiating different event types based on their style. For example, an arrow can be dynamically drawn at the edge of the screen, pointing towards the event relative to the center of the current viewport. The arrow's position is determined by its location along the edge, pointing towards the location of the target outside the screen. If the event is in the lower right corner of the viewport, an arrow pointing towards that corner will be displayed at the lower right edge. Indicator attributes are color intensity or indicator size. The farther away the indicator, the lower its color intensity or size; the closer the indicator, the higher its color intensity or size. Distance-attenuated color / size encoding is used, calculating the color / size attenuation value based on the distance. Color intensity is represented by transparency or saturation. For example, color saturation or transparency can be used to indicate the distance to the target. The farther away the indicator, the lighter the color; the closer the indicator, the brighter the color. This allows users to roughly judge the distance of the event from the current field of view based on the visual intensity of the indicator. For example, distance can be mapped to color brightness: solid bright red for distances within 1 kilometer of the field of view, and semi-transparent red for distances beyond 5 kilometers, to create a distance attenuation effect (the specific mapping function can be adjusted linearly or logarithmically). For indicators requiring dynamic effects, such as blinking rings or bouncing icons, a timer is used to control the periodic changes of the graphic's alpha channel.

[0094] For example, track deviation events are indicated by a red arrow, continuously pointing in the direction of deviation. Sudden sea state events are indicated by a flashing blue ring. The center of the ring is located at the corresponding edge of the screen, and the semi-transparent blue ring flashes at a certain frequency, indicating a severe sea state warning. Proximity conflict events are indicated by double arrows or special icons (such as a red exclamation mark) pointing in two directions, alerting to two ships approaching and clashing. Equipment malfunctions are indicated by yellow triangles (e.g., if an engine failure occurs outside the field of view, a yellow triangle points in that direction). These indicators are color- and shape-coded to provide clear directional and type information without obstructing the main view.

[0095] For example, obtain the coordinates of an event (latitude, longitude, or projected coordinates) and compare them with the boundary coordinates of the current map view. If the event's x-coordinate (event.x) is less than the view's x-coordinate... min or greater than x max Or the y-coordinate of the event (event.y) is less than y min or greater than y maxIf the event is outside the field of view, then it is considered an event outside the field of view. For events outside the range, their azimuth and distance are further calculated. The azimuth angle θ = arctan2(event.y - center.y, event.x - center.x) gives the angle of the event relative to the center of the view. The distance D = sqrt((event.x - center.x)^2 + (event.y - center.y)^2), or can be calculated directly from the geographic coordinates to determine the great circle distance.

[0096] Determine the indicator's position on the view edge based on the azimuth angle: Calculate the intersection of the azimuth angle and the rectangular boundary, and position the indicator on the boundary (top / bottom / left / right). For example, when the azimuth angle is [-45°, 45°], it's on the right edge; 45°-135°, it's on the top edge, and so on. The offset distance is calculated using tan to determine the specific coordinates of the intersection point. Set the arrow direction: The arrow-shaped indicator will point outwards from the view, consistent with the θ direction, so that the user intuitively feels that the direction the arrow points is the event direction. Adjust the indicator's color intensity / size based on distance: For example, define a maximum indicated distance D_max. If D>=D_max, use the lightest color / smallest size; if D is small, use a bright color / larger icon. A linear scale can be used: color_intensity = max(0, 1 - D / D_max). As mentioned above, the default D_max=10 km, then an event 5 km away would have color_intensity=0.5, equivalent to semi-transparency. Generate the corresponding type of indicator graphic element, assign it attributes such as color and transparency, and then draw it on the overlay canvas of the UI layer. The arrow's direction rotates according to its azimuth to align with the event's direction, and its length and transparency scale with distance. Users can see arrows or symbols indicating an event occurring in a certain direction at the edge of their field of vision, along with their color / blinking indicators of importance and distance.

[0097] If multiple events are in similar directions, their positions can be adjusted to avoid complete overlap (e.g., offset by a few pixels or display multiple arrows in a fan-shaped distribution). Indicators can be accompanied by simple label text, such as distance values ​​or a brief event type (however, too much text may be distracting; detailed information can be displayed only when the mouse hovers over the target). For example, if an enemy target approaches 5 kilometers outside the right-hand view of the map: The event's location is detected as exceeding the right boundary; its bearing at the current center is calculated to be 10° east of south, at a distance of 5 kilometers. A red arrow pointing in that direction is drawn 10° below the right edge of the map, and because 5 kilometers is a considerable distance, the arrow is made semi-transparent red. A brief label (e.g., "Enemy ship approaching") can also pop up next to the arrow, providing a summary. As the target moves, the arrow's position can slide along the edge, always pointing in the latest direction.

[0098] The indicator position and attributes are continuously updated. If an event enters the viewport (e.g., the user drags the map to include the event), the corresponding edge indicator is removed. Specifically, every fixed frame (e.g., 50ms), the event's position is checked to see if it has been updated (the orientation changes if the target moves), if it has entered the viewport (if it becomes visible due to map dragging or zooming, the corresponding indicator needs to be removed), and its animation status. For events that are still valid outside the viewport, their arrow direction and attributes are updated in real time to ensure the indicator accurately reflects the latest event dynamics.

[0099] Indicators allow users to interact with them by clicking or hovering. For example, clicking the edge arrow allows the map to pan / zoom to that location for detailed viewing. In this case, an event listener is bound to the element when the indicator is drawn, passing the click action to the map control to move the view center to the event coordinates, allowing users to jump to the location with a single click.

[0100] To avoid excessive prompts causing clutter, a prompt filtering strategy can be set using the event importance field: for example, prompts can be generated only for events of higher importance (such as high-priority events or events that are close together), while events of lower importance that are outside the viewport can be temporarily not prompted or only listed in the event list. If there are many events, a combined prompt technique can also be used, such as using a single arrow to represent multiple events in similar directions and indicating their number, to avoid excessively dense edge arrows.

[0101] When defining the visible boundary of the current viewport, the range can be expanded to provide early warning of targets approaching the edge (e.g., warning starts when the target is 10% outside the visible range). For warnings requiring flashing (such as a sea state warning ring), a flashing frequency can be set, such as 1 Hz (flashing once per second), to balance attracting attention and avoiding excessive interference. Employing the off-screen warning technology of this invention, critical off-screen information is brought back into the user's attention, compensating for the limitations of the limited screen field of view. This allows users to grasp the location of off-screen events without panning the view, significantly reducing the probability of missing emergency events, improving the integrity of overall situational awareness, and reducing the missed detection rate of important events by approximately 40%.

[0102] 9. The interface layout is adjusted to adapt to different user needs.

[0103] Traditional ship dispatch interfaces have a fixed layout, where important information is not highlighted in different scenarios, while secondary information occupies a large amount of space. This forces dispatchers to manually filter information, resulting in low efficiency. Therefore, to enable the interface to automatically adjust its layout and information priority according to the current mission context, ensuring that the most critical information is highlighted when it is most needed, reducing the burden of manual interface adjustments, and improving the efficiency of users in obtaining information at different mission stages, this invention also uses context vectors for adaptive interface layout adjustment.

[0104] The process of adapting the interface layout is as follows Figure 6As shown, this includes: inputting context vectors into a contextual reasoning model and outputting an interface adjustment scheme. The contextual reasoning model includes a rule engine and a machine learning model. First, the context vectors are input into the rule engine. If the context vectors conform to specific rules, the corresponding interface adjustment scheme is output; otherwise, the contextual features are input into the machine learning model, which outputs the interface adjustment scheme.

[0105] The set of contextual features that constitute the contextual vector can be determined based on the domain analysis of ship scheduling tasks. For example, about 10 features in three major categories, namely task stage features, environmental risk features, and user behavior features, can be selected as input dimensions, which not only covers the main influencing factors but also controls the complexity of the model.

[0106] The rule engine predefines a series of IF-THEN rules and corresponding layout templates. When a context vector matches a specific rule, it outputs a corresponding UI adjustment scheme. Based on the output UI adjustment scheme, the UI is adaptively adjusted, and the adjusted UI layout is updated and presented in real time by the front-end rendering engine. The rule engine stores several core rules, covering common scenarios. Too many rules may cause conflicts and need to be weighed; therefore, 20-30 core context rules can be defined.

[0107] For example, if the rule is met: "IF Mission Phase = Return to Base AND Sea State = Good AND User Concern = Landing Stability THEN Enlarge the aircraft attitude curve window and display the approach slope graph", then the corresponding solution is generated: "Enlarge the attitude view and highlight the approach-related parameters". If multiple rules are met, the most suitable interface adjustment solution is selected based on priority. The output interface adjustment solution can be a collection of interface adjustment operations, including adjusting the size and proportion of each view window, rearranging the layout order, highlighting high-priority information, weakening secondary information, and popping up key situational awareness prompts, etc.

[0108] Adjust view size: Modify the size and position parameters of each window using the front-end layout manager. For example, increase the height of the attitude curve view by 20% and correspondingly shrink other view areas. Responsive layout frameworks can be used, such as adjusting CSS grid templates or GUI layout tree node properties. Rearrange layout order: For example, move important views to more prominent positions (e.g., move them from secondary tabs to the main screen), or move a window to the main screen in a multi-screen system. Highlight / fade information: Adjust the style of interface elements to make key information more prominent. For example, change the font color or background to highlight important values, or add flashing prompts; conversely, reduce the brightness of secondary areas or make them semi-transparent to weaken their presence. Push operation suggestions: If the solution includes recommended operations, display prompts on the interface. For example, a small panel pops up prompting "It is recommended to check the fuel status of ship XX," with a button for one-click navigation. Another example is automatically popping up the "Approach Monitoring" window during the return phase, which is also a form of push suggestion.

[0109] For example, during the ship's return phase, if it is detected that the user is frequently viewing the ship's attitude curve and the mission is approaching landing, an instruction will be output to highlight landing-related information. The attitude curve view will be automatically enlarged and an approach parameter view will be added to the side to facilitate the user's monitoring of landing stability.

[0110] When no matching rule exists in the rule engine, contextual features are input into a pre-trained machine learning model, which outputs suggested interface adjustments. The machine learning model is trained using historical usage data. Shallow decision trees or Bayesian networks can be used. If a decision tree model is used, the tree depth can be limited to ensure real-time inference (e.g., depth not exceeding 3 layers); if a Naive Bayesian network is used, the conditional probabilities of each feature need to be estimated. The machine learning model can also be used to prioritize and supplement rules, as well as calibrate rule trigger thresholds and adjustment ranges.

[0111] To ensure a smooth transition during interface adjustments, animation transitions can be used. For example, window resizing can be animated and completed within 0.5 seconds to avoid abrupt changes that might startle the user. Key prompts can be accompanied by a fade-in effect. Ensure that interface adjustments do not affect the user's current operation (e.g., if the user is dragging a map, delay the layout change until the user completes their operation).

[0112] It also features a manual intervention correction mechanism: if the automatic adjustment is unsatisfactory, the user can manually adjust the interface, and this behavior is recorded to optimize interface adjustment decisions in similar future scenarios. Specifically, the content of the automatic adjustment and the user's subsequent reaction (such as whether the user accepts it or immediately manually reverts it) are recorded and fed back to the contextual reasoning model for optimization. For example, if it is found that users frequently cancel a certain automatic adjustment, the rule may be adjusted or its priority lowered.

[0113] Contextual reasoning and interface updates are executed periodically, or when the context changes significantly (context vector update), such as once per second by default or immediately when the task phase changes, to balance responsiveness and overhead. When automatic layout adjustments conflict with user-defined adjustments, a user-first principle is adopted: if a user is detected dragging / adjusting the interface, automatic adjustments are paused, and the user's manual layout is not interfered with for a period of time. Intervention is only attempted when a new context changes significantly. Through adaptive interface adjustments, the fit between the interface and the task context can be significantly improved, increasing operational efficiency and shortening the workflow by approximately 25%.

[0114] 10. Abnormal event detection.

[0115] During real-time ship operations, abnormal changes may occur in the trajectory and parameters, such as sudden deviations from the planned route, excessively close proximity between two ships, or sudden changes in critical parameters. Failure to detect these anomalies in a timely manner will jeopardize mission and safety. Existing devices lack intelligent monitoring methods, requiring manual visual monitoring, which is prone to missed detections. Meanwhile, while complex deep learning models can detect anomalies, they are computationally intensive and difficult to run in real-time at the front end. Therefore, this invention also includes low-computational-cost real-time detection of multiple anomaly modes. Through lightweight and efficient algorithms, it identifies anomalies such as trajectory deviations, attitude abnormalities, and collision risks, proactively detecting abnormal trajectories and states during ship operations, providing early warnings to dispatchers, and compensating for the slow response of existing devices to abnormal situations.

[0116] Anomaly detection is based on an anomaly detection model comprised of Kalman prediction, outlier detection, and rule validation. The anomaly detection process is as follows: Figure 7 As shown, it includes: A Kalman model is established for each ship's state to predict its trajectory and position in real time. Specifically, Kalman prediction is used to predict the ship's position at the current time (k+1 time) based on the ship's state (including position and velocity) at the previous time (k time). The actual monitored ship position is obtained at k+1 time, and the residual between the predicted and actual monitored ship positions is calculated. The filtering process iterates continuously, outputting the residual in real time for each ship. If the residual is greater than or equal to a residual threshold, it indicates an abnormal deviation from the trajectory, marking a potential trajectory anomaly; if the residual is less than the residual threshold, the motion is considered within the expected range. The residual threshold is determined statistically from historical normal trajectory data, such as by the 3σ principle, or by ensuring that more than 95% of normal deviations fall within the threshold (e.g., selecting residuals exceeding three times the normal standard deviation). Kalman filtering can filter out measurement noise and provide smooth predictions; therefore, the residual mainly reflects non-random abnormal deviations.

[0117] Preferably, the residual threshold is dynamically adjusted based on the ship's navigation status, where the navigation status is characterized by the rate of change of course and the rate of change of speed. The adjustment principles include: When the rate of change of heading is less than the first threshold and the rate of change of speed is less than the second threshold, the navigation is determined to be in a stable state, and the residual threshold is reduced to improve the sensitivity of anomaly detection.

[0118] When the rate of change of heading exceeds the third threshold or the rate of change of speed exceeds the fourth threshold, it is determined to be a severe maneuver, and the residual threshold is increased to reduce the false alarm rate.

[0119] Furthermore, the residual threshold is corrected according to the ship's speed gear. When the speed is higher than the set speed threshold, the residual threshold is amplified.

[0120] When the residual is greater than or equal to the residual threshold, the trajectory segment with the residual greater than or equal to the residual threshold is extracted, and the motion feature vector of the track point in the trajectory segment (such as the average heading variation, speed change, acceleration, deviation angle from the planned route, and closest distance to nearby ships in the last m seconds) is obtained as the trajectory feature vector. The motion feature vector and the current environmental variables (such as wave height, track fluctuations in large waves may increase the normal residual) can also be used together as the trajectory feature vector.

[0121] Anomaly detection can employ the K-Nearest Neighbors (KNN) algorithm. Based on a set of historical normal trajectory features, the algorithm evaluates trajectory feature vectors to determine whether a trajectory point is an anomaly and the severity level of the anomaly. Specifically, a normal motion pattern library is constructed from the set of historical normal trajectory features. The trajectory feature vector is compared with this library, and the distance between the feature vector and each sample in the library is calculated. The K nearest neighbors are identified. If the distance between the feature vector and all its neighbors is greater than an anomaly threshold, the corresponding trajectory point is considered an outlier (i.e., an anomaly). In this invention, K=5 is selected, and the anomaly threshold is determined based on the distribution of normal data (e.g., ε is taken as the 95th percentile of the average distance of normal samples). If the average distance from the feature vector to the five nearest normal samples is greater than the anomaly threshold, the corresponding trajectory point is considered an anomaly. KNN anomaly detection requires no training process, is suitable for online detection, and can identify novel anomalous trajectories that do not belong to historical regular patterns.

[0122] To further improve accuracy and classify anomaly types, preset rules are introduced to determine anomaly types. These include: Track deviation anomaly: If the residual is consistently greater than the residual threshold and the yaw angle is greater than the deviation threshold, then a track deviation anomaly is determined to have occurred. A residual consistently greater than the threshold means that the residual is greater than the residual threshold n times consecutively, or the time the residual is greater than the residual threshold exceeds a set anomaly time (e.g., 1 second).

[0123] Abnormal attitude: Check the ship's roll / pitch angle parameters. If they exceed the corresponding roll / pitch angle safety threshold (e.g., roll > 30°), then mark it as an abnormal attitude.

[0124] Unsafe approach (collision hazard anomaly): Calculate the distance between this ship and other nearby ships. If the distance to the nearest ship is less than the safe distance threshold and the ship continues to approach, for example, if the distance between this ship and the nearest ship is less than the safe distance threshold for a set period of time, then the collision hazard anomaly is determined.

[0125] Abnormal parameter mutation: Monitor key aircraft parameters (such as engine speed, air speed and temperature). If a parameter changes in a single step beyond a set threshold (such as transient change > 20%), it is judged as an abnormal parameter mutation.

[0126] Abnormal maneuvering: If the flight path frequently sways left and right, it may be due to abnormal maneuvering caused by a servo malfunction.

[0127] These rules are based on professional experience, have low computational cost and high real-time performance, and can further filter false alarms and assign semantics to anomalies detected by KNN. Rule verification can also be combined with statistical models, such as setting conditional probability thresholds to comprehensively judge the confidence of anomalies based on multiple parameters. Rule discrimination can be performed in parallel, assigning a Boolean flag to each possible anomaly. The final anomaly event includes anomaly type labels (multiple) and anomaly scores. If KNN does not detect an anomaly but a rule detects it independently (such as a collision hazard that may not manifest as a residual), an anomaly event is still generated. To prevent instantaneous errors, this invention introduces a time confirmation mechanism. Only when the residual is continuously abnormal and the yaw angle is greater than the deviation threshold is the trajectory considered to have significantly deviated from the planned route for a long period of time, and confirmed as a track deviation event, thus avoiding false alarms caused by single-point noise. For collision hazard anomalies, an alarm is only triggered when the distance is continuously below the threshold for several seconds. This can be achieved by maintaining an anomaly state machine, where each potential anomaly enters a "pending confirmation" state, and then transitions to "confirmation" after meeting the required duration or multiple determinations.

[0128] Generate anomaly event objects: For each confirmed anomaly, create an event object, including the ship ID, anomaly type, occurrence time, location, and severity level, and may also include a brief description (e.g., "track deviated from xx meters"). This object is sent to the out-of-view anomaly alert and rendering, and can also be sent to the log and alarm systems. If the anomaly is resolved (e.g., the ship returns to its normal trajectory), a resolution notification is also generated.

[0129] The abnormal event detection model can be optimized based on feedback. For example, if a ship frequently makes false alarms due to large deviations in severe sea conditions, its Kalman residual threshold can be temporarily increased or a sea state factor can be added to relax the criteria. Rules can also be dynamically adjusted, such as adjusting the collision distance threshold based on traffic flow density.

[0130] Kalman model parameters: These include the state vector definition (e.g., [x, y, vx, vy]), process noise covariance Q, and measurement noise covariance R matrix. These can be set according to the AIS data accuracy; for example, the position measurement error R is set based on a GPS accuracy of 3-5 meters. Residual threshold: Determines the sensitivity for initial anomaly detection, determined by referring to historical deviation distributions; for example, 50 meters is used to determine track deviation. Feature window length: The time window for KNN feature extraction, selecting data from the most recent 10 seconds to balance timeliness and stability. KNN K value and distance metric: For example, K=5, and the distance metric uses standard Euclidean distance or Mahalanobis distance (the latter can consider feature correlation). Rule thresholds: Such as a safe distance of 500m, an attitude angle of 30°, etc., given by industry standards or experience.

[0131] Because it uses Kalman blobs + KNN + rules instead of complex neural networks, the computational overhead is low. Kalman blobs have a negligible basic computational cost of O(state dimension^2) per ship per cycle, and KNN is extremely fast at calculating the distances of 5 neighbors in a small dimension of the feature space. Actual tests show that even with 100 ships tracking simultaneously, judgments can be completed in milliseconds. Therefore, it can run in real-time on conventional hardware in the command center without GPU acceleration. This improves the timeliness of risk identification; tests show that the accuracy of anomaly detection is improved by 18-25% (specifically referring to the early detection rate of various anomalies), giving commanders valuable reaction time.

[0132] The results of the above steps are presented uniformly on the human-computer interaction interface and fed back to the user in a closed loop. Specifically, all information that needs to be presented to the user from the preceding steps, including multi-view linkage results, semantic zoom results, out-of-view prompts, adaptive interface adjustments, recommended windows or preloaded content based on intent prediction, and abnormal event detection events, are rendered centrally. The human-computer interaction interface summarizes all of these outputs and calls the visualization engine to present the final effect on the interface. The presentation methods of various results are as follows: Information highlighting / coloring: Information that needs to be highlighted (such as abnormal ships and key parameters) is marked with a highlight color on the interface. For example, if a ship's track is abnormal, the ship's track curve will be turned into a flashing red on the map, and the ship's name will be highlighted in red in the ship list.

[0133] Edge pointing arrows: Arrows and other tooltips displayed outside the viewport are drawn directly on the map's edge overlay layer. If there are multiple arrows, they will all be displayed together.

[0134] Pop-up risk warnings: For serious anomalies or important recommendations, a warning box will pop up in the center or corner of the interface. For example, "Ship A's track has deviated from its course by 500m," and users can click to view details. The warning box is designed not to obscure the main map and can disappear automatically or require user confirmation.

[0135] Dynamic view switching: Based on the results of multi-view linkage and interface adaptive adjustments, the changes in views or layouts that need to be switched are reflected through interface animations. For example, the interface automatically jumps to a certain tab or screen display. For instance, after the user clicks the arrow tooltip, the map pans to the corresponding location.

[0136] Automatic Recommendation Window: If the intention prediction recommendation window takes effect, a new window or menu will appear on the interface. For example, the "Approach Parameters" window will appear automatically, or a menu item will be automatically expanded.

[0137] The final result is a complete information loop displayed on the human-computer interface. At this point, the user has a clear understanding of the overall situation: multi-view collaboration provides information from different perspectives, semantic scaling displays appropriate granular details, screen edge warnings alert users to external threats, the interface layout is optimized for the current task, and abnormal alerts pop up promptly and are easy to handle. This invention also pre-prepares the information needed for the next step. All these results are intuitively presented on the interface, allowing users to make direct decisions and take action.

[0138] In addition to visual presentation, sound or vibration feedback can be used for user notifications and alerts. This invention primarily describes visual presentation, such as flashing icons or red exclamation marks on a graphical interface, to focus the user's attention on important outputs.

[0139] After seeing these results, users will respond, perhaps by clicking on highlighted objects to view details, handling abnormal alerts, adopting or ignoring recommended information, etc. Any user action based on this information (user feedback) is captured, and the output is adjusted according to this feedback, as well as data updated or new scenarios and interactions triggered, starting the next cycle and forming a closed-loop model of perception-decision-action-re-perception. For example, if a user clicks "confirm processing" for an abnormal alert, this series of actions can be detected during intent prediction. The next time a similar abnormality occurs, the presentation method can be selected more accurately, ultimately achieving a "human-machine fusion closed loop." The output is continuously adjusted based on user actions, while user actions are optimized based on prompts; the two influence each other and jointly complete the scheduling decision.

[0140] Implementation of Situational Interaction Device for Multi-Scenario Dispatch of Ships at Sea This invention provides a situational interaction device for multi-scenario scheduling of naval vessels, such as... Figure 8 As shown, the device specifically includes a memory, a processor, a system bus, a computer program stored in the memory, and a human-computer interaction interface. The processor and the memory communicate and interact with each other through the system bus. This device is used to implement a situational interaction method for multi-scenario scheduling of ships at sea. The specific implementation process of this method has been described in detail in the embodiment of the situational interaction method for multi-scenario scheduling of ships at sea, and will not be repeated here.

[0141] Specifically, the device is based on a situational interaction architecture for multi-scenario scheduling of ships at sea, including a data acquisition module, a data storage module, a situational fusion module, an interactive presentation module, an out-of-view event prompt module, an interface adaptive adjustment module, a user intent prediction module, an abnormal event detection module, and a visualization presentation module. Each module works collaboratively through data flow and event flow.

[0142] The visualization module displays all information presented to the user on the human-computer interaction interface and provides closed-loop feedback of interaction results to the corresponding modules. Since multiple display updates may be processed simultaneously, it's crucial to ensure smooth UI thread operation. Therefore, techniques such as double-buffered drawing or progressive rendering can be used to complete large-scale updates in batches. During presentation, key prompts are drawn first, followed by secondary updates, ensuring important information is visible first. If the same object has multiple state changes, such as a ship simultaneously experiencing an anomaly and needing its trajectory highlighted, a single visual identifier should be used to avoid duplication. For example, an anomaly marker could be attached when highlighting the trajectory, avoiding repeated flashing.

[0143] To accommodate different dispatcher preferences, some prompts and automatic windows can be toggled for customized display.

[0144] The data acquisition module is used for multi-source data acquisition and preprocessing. It aggregates various types of raw data, cleans and synchronizes them, and outputs a standardized data stream / data set, providing a unified data foundation for subsequent stages. The data acquisition module broadcasts the standardized output data to downstream modules via a data bus interface. Adopting a publisher-subscriber model, the context fusion module subscribes to the required data topics (such as flight track data or environmental data), and pushes new data to subscribers whenever it arrives. This ensures that the context fusion module and others can obtain the latest fusion input in a timely manner. Simultaneously, the data storage module writes key data to the database for offline analysis or anomaly backtracking.

[0145] The context fusion module extracts context features from the standardized data output by the data acquisition module and fuses these features to obtain a context vector. The context fusion module includes a feature extraction submodule, a data preprocessing submodule, a weighted fusion submodule, and a context update and distribution submodule. The feature extraction submodule extracts context features with mid-to-high-level semantics from multi-source data; the input is a standardized data stream, and the output is context features. The data preprocessing submodule performs time synchronization, coordinate unification, and normalization on each context feature; its input is the original context features, and its output is standardized context features. The weighted fusion submodule fuses multi-source context features into a unified context vector; its input is the multi-source context features, and its output is the context vector. The context update and distribution submodule updates the context vector and distributes it to consumer modules (i.e., modules using the context vector) via shared memory or messages. It receives the context vector output by the weighted fusion submodule and broadcasts the context vector to the corresponding modules. Because the context vector update cycle is short (e.g., 1 second), the latest value is overwritten, and a snapshot of the current context vector is obtained when needed, or its update event is subscribed to (a notification is triggered with each update). In addition, the context feature set can be used for log display, allowing operations and maintenance personnel to intuitively understand the context perceived by the current device (assisting in debugging and optimization rules).

[0146] The interactive presentation module is used to implement semantic interaction across multiple views. It includes an interaction control submodule and a view submodule. The interaction control submodule receives UI event input, i.e., listens for user selection / click actions on any view, parses the action events, queries the semantic mapping table, and publishes interaction events based on the query results. The semantic mapping table stores the semantic relationships between multiple views, implemented using a hash table or database index, supporting millisecond-level queries, and returning a list of related data indexes based on the query request. Each view submodule is responsible for the visualization of specific types of information, performing UI transitions or highlight rendering based on the content of the interaction events. The view submodules expose interaction interfaces, such as `jumpToTime(t)` or `highlightShip(id)`, which are called by the interaction mechanism using an event-method call mapping, managed through a unified bus or controller. Updates are triggered asynchronously and non-blockingly to avoid freezing the UI. There are no strict requirements on the order of cross-view updates; they generally occur almost in parallel.

[0147] The interactive presentation module also implements semantic scaling. It includes a focus-based semantic scaling submodule, a data service submodule, and an information rendering engine. The focus-based semantic scaling submodule receives user zoom operations, calculates the current zoom ratio, determines the semantic level, triggers level switching, calls the data service submodule to load the corresponding level information, and notifies the information rendering engine to update the view. The data service submodule stores information layers of different levels (such as global, regional, ship, and parameter), supports on-demand loading and preloading, receives requests from the focus-based semantic scaling submodule, and returns the corresponding level's dataset. The information rendering engine receives instructions from the focus-based semantic scaling submodule, retrieves the corresponding level data from the data service submodule, adjusts display elements (such as icons, labels, and styles) according to the current level template, performs smooth rendering, and updates the view presentation.

[0148] The semantic scaling submodule focuses on obtaining scaling events and parameters through the interface provided by the map control. It then uses internal logic to determine which data and rendering interfaces to call. When interacting with the data service submodule, it uses the data access API (or GraphQL to query data within a specific range). When interacting with the information rendering engine, it calls the layer management API (such as map.showLayer('regional_ships')). Scaling events are typically frequent and continuous; the module internally controls the data loading frequency through a throttle mechanism, such as triggering a data update only every certain scaling factor or every 100ms, to avoid excessive calls.

[0149] The out-of-view event prompt module includes an event detection submodule, a visibility determination submodule, an indication calculation submodule, and a prompt rendering engine (Overlay layer). The event detection submodule receives event input from the abnormal event detection module or a data source to monitor ship situational events (such as anomalies, threats, and missions), generates event objects containing location, type, and severity, and outputs them to the visibility determination submodule. The visibility determination submodule determines whether the received event object is within the current view range and outputs a "view-in / out" judgment result. The indication calculation submodule receives the event object and view parameters, calculates the azimuth and distance of the event relative to the center of the view, determines the prompt's rendering parameters (style and attributes), and outputs them to the prompt rendering engine. The prompt rendering engine draws the prompt on the UI overlay layer and supports dynamic updates and interactions. For example, the calculated prompt is drawn on the UI's Overlay layer, and arrows or rings are drawn at the edges of the map view using Canvas or SVG. If multiple events are in similar directions, their positions can be slightly adjusted to avoid complete overlap (e.g., stagger them by a few pixels or display multiple arrows in a fan-shaped distribution).

[0150] The out-of-view event prompt module connects to the abnormal event source via an event queue interface to ensure that new events trigger prompt generation in a timely manner. Graphic overlay with the UI is achieved through a front-end drawing interface (Canvas API or the Overlay interface provided by the map SDK). The out-of-view event prompt module subscribes to map view change events; once map view parameters change (pan / zoom), the map control notifies this module to refresh the calculation, achieving real-time updates to the prompt position.

[0151] The adaptive interface adjustment module comprises a contextual reasoning model, a layout adjustment engine, and a user feedback recording submodule. The contextual reasoning model outputs the optimal layout adjustment scheme based on the contextual vector. The layout adjustment engine receives the layout adjustment scheme and calls the UI framework interface to dynamically adjust the interface layout. The user feedback recording submodule listens for user actions, records the user's acceptance level of the adaptive adjustment, and feeds this information back to the contextual reasoning model for model optimization. It can also determine the layout adjustment scheme based on the current contextual vector and possible auxiliary inputs (such as the result of the most recent interface adjustment).

[0152] Layout adjustments are typically accomplished by calling UI framework interfaces. For example, `UIManager.resize("attitudeView", newSize)` resizes components; `UIManager.move("attitudeView", "mainPane")` moves components to the main panel. These actions need to be completed quickly and rendered synchronously; otherwise, users will notice a significant lag. Alternatively, the size and position parameters of each viewport can be modified through a front-end layout manager. For instance, a responsive layout framework can be used, such as adjusting the CSS grid template or GUI layout tree node properties to increase the height of the attitude curve view by 20% and correspondingly shrink other viewports.

[0153] The adaptive interface adjustment module is tightly integrated with the front-end UI, allowing direct manipulation of UI element attributes via the browser DOM interface (for web interfaces) or GUI framework APIs (for desktop applications). ContextVector is typically pushed from the backend to the frontend script, or requested periodically by the frontend, where inference and adjustments are then performed to reduce communication latency. Simple rule-based judgments for the inference model may also be implemented on the frontend. The entire process is transparent to the user, requiring no special interactive input.

[0154] The user intent prediction module includes a behavior logging submodule, a feature extraction submodule, an intent prediction submodule, and an interface collaboration execution submodule. The behavior logging submodule receives front-end UI events, continuously records user interactions, and outputs user behavior sequences (such as clicks, switches, and pauses). The feature extraction submodule extracts the current behavior feature vector from the current user behavior sequence. The intent prediction submodule includes pattern matching and / or an intent prediction model, used to perform pattern matching between the current user behavior sequence and a known behavior pattern library, and / or input the current behavior feature vector into the intent prediction model to obtain prediction results, including user intent prediction and prediction of the user's next interaction behavior. The interface collaboration execution submodule receives the prediction results and calls UI interfaces to perform collaborative operations such as preloading, pop-up recommendations, or highlighting. Pop-ups are created by calling the UI component factory, and preloading is achieved through asynchronous requests via data interfaces.

[0155] The anomaly detection module includes an anomaly detection model and an anomaly generation and push submodule. The anomaly detection model comprises Kalman prediction, anomaly detection, and rule validation. Kalman prediction predicts the ship's position at the current time (time k+1) based on the ship's state (including position and velocity) at the previous time (time k). It calculates the residual between the predicted current ship position and the actual monitored current ship position. When the residual is greater than or equal to a residual threshold, trajectory segments with residuals greater than or equal to the residual threshold are extracted, and their motion feature vectors are extracted as trajectory feature vectors. Anomaly detection assesses the degree of anomalousness of trajectory feature vectors in the historical normal trajectory feature space. A set of historical normal trajectory features is constructed as a normal motion pattern library. The trajectory feature vector is compared with the normal pattern library, and the distance between the trajectory feature vector and each sample in the normal motion pattern library is calculated. The K nearest neighbors are identified. If the distance between the trajectory feature vector and all its neighbors is greater than the anomaly judgment distance threshold, the corresponding trajectory point is determined to be an outlier (i.e., an anomaly).

[0156] The rule validation module receives KNN output and real-time data, confirms and classifies anomalies according to domain rules, and outputs the anomaly type and level. The anomaly event generation and push submodule receives the rule validation results, encapsulates the confirmed anomalies into event objects, and pushes them to the off-view event prompt module and the visualization presentation module for alarm notification.

[0157] The exception event detection module runs independently on the backend by default, notifying the frontend of the results via an event bus or callback interface. Due to the potential need for rapid response, exception events are also pushed to the UI thread. Exception events are also saved to a database or file for later analysis.

[0158] Computer-readable storage medium implementation The present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps in the method described in the embodiment of the situational interaction method for multi-scenario scheduling of naval vessels.

[0159] This invention provides a foundation for data acquisition and cleaning, empowers the system with contextual fusion, improves information display efficiency through multi-view linkage and semantic scaling, ensures global perception through out-of-view prompts, enables intelligent human-machine collaboration through interface adaptation and intent prediction, safeguards safety through anomaly detection, and finally presents a unified view with closed-loop feedback, forming an organically integrated intelligent interaction process. Practical verification shows that this invention minimizes cognitive loss caused by fragmented multi-view systems, improves information acquisition and decision-making efficiency, and demonstrates feasibility and significant effectiveness in engineering. Compared to traditional systems, cross-view operation time is reduced by approximately 30%, information retrieval efficiency is improved by approximately 35%, the rate of missed detection of critical events is reduced by approximately 40%, interface operation steps are reduced by approximately 25%, early detection of anomalies is improved by approximately 20%, and user workload is reduced by more than 20%. These performance improvements fully demonstrate the innovation and practicality of this invention in the field of multi-view situational interaction for ship scheduling.

Claims

1. A situational interaction method for multi-scenario scheduling of naval vessels, characterized in that, include: Acquire contextual data, which includes user interaction behavior data in the scheduling and control of naval vessels. The current user behavior sequence is obtained based on current and historical user interaction behavior data at a set time, and the current user behavior sequence is converted into current behavior features. The current user behavior sequence is matched with a known behavior pattern library, and / or the current user behavior features are input into the intent prediction model to obtain the user intent prediction result. Based on the predicted user intent, the user's next interaction behavior is predicted. The known behavior pattern library stores known behavior patterns mined from historical user interaction data; the intent prediction model is obtained by training a machine learning model using user interaction logs from historical tasks. Based on predictions of the user's next interaction behavior, the interface is proactively coordinated and controlled to execute the corresponding next interaction behavior in advance.

2. The situational interaction method for multi-scenario scheduling of naval vessels according to claim 1, characterized in that, The pattern matching process involves calculating the matching degree between the current user behavior sequence and known behavior patterns in the known behavior pattern library. If the matching degree is greater than the matching threshold, the user's intent is predicted based on the known behavior pattern.

3. The situational interaction method for multi-scenario scheduling of ships at sea according to claim 1 or 2, characterized in that, Interface collaborative control includes interface actions, data preparation, and interaction path optimization; data preparation includes preloading data, which refers to acquiring prediction-related data in advance and loading the parameter panel in advance so that it can respond instantly when the user views it; interface actions include actively expanding the view based on the prediction results and actively prompting functions. Interactive path optimization refers to providing results directly without intermediate steps based on prediction results.

4. The situational interaction method for multi-scenario scheduling of naval vessels according to claim 1, characterized in that, The method further includes inputting a context vector into a context reasoning model and outputting an interface adjustment scheme. The context vector is obtained by fusing context features. Context features include at least two of the following: task phase features, dynamic situation features, environmental risk features, and user behavior features. Task phase features include ship task phase labels determined based on the relationship between the current time and the task plan; dynamic situation features include the ship motion change rate calculated based on ship navigation data; environmental risk features include the current environmental risk level determined based on environmental data, including sea state and external threat levels. The context reasoning model includes a rule engine and a machine learning model. First, the context vector is input into the rule engine. If the context vector conforms to a specific rule, the corresponding interface adjustment scheme is output; otherwise, the context features are input into the machine learning model to output the interface adjustment scheme.

5. The situational interaction method for multi-scenario scheduling of ships at sea according to claim 1, characterized in that, The method also includes anomaly detection, which is determined based on an anomaly detection model consisting of Kalman prediction, anomaly detection, and rule verification. Kalman prediction is used to predict the ship's position. If the residual between the predicted ship position and the actual monitored ship position is greater than or equal to the residual threshold, the motion feature vector of the track point is obtained as the trajectory feature vector. The trajectory feature vector is evaluated based on the historical normal trajectory feature set to determine whether the trajectory point is an anomaly and the severity level corresponding to the anomaly. Then, the anomaly type is judged based on preset rules, and finally an anomaly event object is generated. The anomaly event object includes the ship ID, anomaly type, occurrence time, location, and severity level.

6. The situational interaction method for multi-scenario scheduling of ships at sea according to claim 1, characterized in that, The method also includes monitoring user interactions on the views. When a user performs a selection or click operation on any view, the method queries related data in other views through an index in the semantic mapping table, and controls other views to jump or highlight the related data based on the query results. The semantic mapping table establishes a mapping relationship between elements of different views, and the index fields include view type, element identifier, and a list of associated target view element identifiers. View types include track view, mission timeline view, ship status view, and environmental risk event view.

7. The situational interaction method for multi-scenario scheduling of naval vessels according to claim 1, characterized in that, The method also includes determining the corresponding semantic level based on the detected current scaling ratio, automatically switching the display of information at the corresponding semantic level, and pre-storing data at different semantic levels in layers; The semantic hierarchy includes at least two of the following: global, regional, ship-level, and parameter-level. Global information includes the overall course of navigation in the sea area, ship distribution, and route planning. Regional information includes ship relationships, heading arrows, and local sea state changes within a local sea area. Ship-level information includes the specific course, speed changes, and mission phases of a single ship. Parameter-level information includes ship-related engineering data.

8. The situational interaction method for multi-scenario scheduling of naval vessels according to claim 1, characterized in that, The method also includes, if an out-of-view event is detected, calculating the azimuth angle and distance of the out-of-view event relative to the center of the view, determining the indicator style according to the out-of-view event type, determining the position of the indicator on the view boundary according to the azimuth angle, determining the indicator attributes according to the distance, and displaying the indicator on the view based on the indicator style, the position on the view boundary, and the attributes. The indicator style is the indicator shape or a combination of indicator shape and color, and the indicator attribute is the color intensity or indicator size.

9. A situational interaction device for multi-scenario dispatching of naval vessels, comprising a processor and a human-computer interaction interface, characterized in that, The steps for implementing the method according to any one of claims 1-8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the method according to any one of claims 1-8.

Images