A ship internet of things multi-protocol edge access intelligent diagnosis data analysis method and system

Abstract

The application discloses a kind of ship internet of things multi-protocol edge access intelligent diagnosis collection analysis method and system, belong to ship internet of things technical field.The present application is aimed at the problems of existing ship equipment access dispersion, protocol is heterogeneous, diagnosis capacity is insufficient, and poor reliability of ship-shore transmission, and the multi-type equipment access and hierarchical instance binding are completed by ship end edge access module, and the uniform data model is generated by weighted scoring protocol identification and standardization conversion;In combination with priority queue and exponential backoff breakpoint continuation mechanism, the reliable transmission of data under the weak network of ship-shore is guaranteed;Two-stage diagnosis mechanism of rule engine prescreening and AI weighted inference is used, and the diagnosis conclusion and full-link traceable evidence chain are output, and finally data services are provided externally through multi-type standardized interface.The present application can be used as the data support base of intelligent ship, and the efficiency of ship equipment access, data availability and intelligent operation and maintenance level are improved.

Description

Technical Field

[0001] This invention relates to the field of ship Internet of Things (IoT) technology, specifically to a method and system for intelligent diagnostic data analysis of multi-protocol edge access in ship IoT. Background Technology

[0002] With the accelerated digital and intelligent transformation of global shipping, the number of sensing, navigation, power, electrical, safety, and environmental monitoring devices carried by ships, as the core carriers of shipping, continues to grow. Typical equipment includes Automatic Identification System (AIS), BeiDou / GNSS positioning equipment, gyrocompasses, autopilots, depth sounders, speed logs, main propulsion systems, power distribution systems, PLC control equipment, navigation radar, fire alarm systems, visibility monitoring equipment, and various industrial sensors. These devices continuously generate massive amounts of real-time data during operation, covering multi-dimensional information such as navigation status, equipment operating conditions, alarm events, and operation logs. This data forms the core data foundation for ship operation monitoring, equipment fault early warning, navigation safety analysis, remote supervision, and intelligent operation and maintenance.

[0003] Currently, ship equipment data acquisition generally adopts a customized access mode of "single device, single protocol, single system". The communication protocols, interface forms and data formats of different devices are significantly different. The system needs to develop access logic separately for each type of device, resulting in high access costs, low expansion efficiency and high maintenance difficulty. Summary of the Invention

[0004] To address the aforementioned technical problems, this invention provides a method for intelligent diagnostic data analysis of multi-protocol edge access in ship-to-ship networking. The execution entities are an edge computing gateway deployed on the ship and a shore-based data platform. The specific implementation process is as follows: S1. Receive raw message data output by various types of ship equipment through multiple physical communication channels, identify the characteristic information of the current acquisition channel, match it with the preset ship equipment instance library to complete the equipment instance binding, and generate a globally unique equipment identifier for each device. S2. Based on the message characteristics and channel configuration information of the original message, identify the corresponding communication protocol type, store the original message and call the parsing rules of the corresponding protocol to extract the message fields, perform legality verification and standardization conversion on the parsed field data, and generate standardized device data that conforms to the unified data model. S3. Write standardized equipment data into the ship's local time-series storage unit for caching and monitor the ship-shore communication link status in real time. When the communication link is normal, upload the data to the shore platform. When the communication link is abnormal, write the data into the message queue to be sent. After the communication is restored, resume the transmission according to the time priority. S4. The rule engine performs multi-dimensional anomaly matching and judgment on standardized device data. When an anomaly rule is hit, an alarm event is generated. The alarm state machine manages the state transition of the alarm event throughout its entire lifecycle. S5. When an alarm event occurs or an active diagnosis request is received, the AI ​​diagnosis module is invoked to extract multi-source related data centered on the abnormal moment to construct the device operation feature vector. Combined with the fault knowledge base and historical fault samples, comprehensive reasoning is performed to generate a diagnosis conclusion and a traceable chain of diagnostic evidence. S6. Distribute standardized equipment data, alarm events, diagnostic conclusions, and operation records to external systems through multiple types of standardized interfaces, providing a unified data access point for upper-layer business systems.

[0005] Preferred method: Step S1 includes: S1.1 receiving the original message; S1.2 channel feature extraction and similarity matching; S1.3 hierarchical device binding; S1.4 dynamic verification and update.

[0006] Preferred method: Step S2 includes: S2.1 Automatic identification of protocol type; S2.2 Storage of raw message; S2.3 Parsing of protocol fields; S2.4 Data verification and standardization conversion.

[0007] Preferred method: Step S3 includes: S3.1 Local time-series storage; S3.2 Communication status detection and queue scheduling; S3.3 Exponential backoff retry, when data transmission fails, an exponential backoff strategy is used for retry; S3.4 Breakpoint resume and deduplication verification, when the communication link is restored, the breakpoint resume unit uploads cached data in batches from the earliest to the latest according to the principle of "first-in, first-out".

[0008] Preferred method: Step S4 includes: S4.1 multi-dimensional rule engine judgment; S4.2 alarm level calculation; S4.3 alarm state machine closed-loop management, and full life cycle management after alarm generation.

[0009] Preferred step S5 includes: S5.1 Diagnostic triggering and data extraction; S5.2 Construction of multi-dimensional feature vectors: Based on the extracted data, construct a 9-dimensional feature vector F=[f1, f2, ..., f9] for device operation; S5.3 Knowledge base matching and comprehensive diagnostic reasoning: Match the feature vectors with the fault knowledge base and calculate the sub-scores D. m Then, based on the itemized score D m The system calculates the comprehensive diagnostic score, sorts the candidate fault causes from high to low according to the comprehensive diagnostic score, outputs the top 3 possible fault causes, and also outputs the anomaly type, risk level, impact scope analysis and handling suggestions.

[0010] This invention proposes a ship-to-everything (SLO) multi-protocol edge access intelligent diagnostic data analysis system, comprising: The ship equipment layer, deployed in various compartments and decks of the ship, is the input starting point for the entire data collection and analysis process.

[0011] The edge access module is used for physical channel management, device identity binding, raw data acquisition, and online device status detection.

[0012] The protocol parsing module is the core of protocol identification and structured parsing of raw messages, converting unstructured raw messages of different protocols into structured fields.

[0013] The data governance and caching module is used for original message retention, data quality control, unified model conversion, and local cache storage.

[0014] The alarm diagnosis module is used to carry out anomaly detection, alarm management, multi-source correlation analysis and AI intelligent diagnosis functions.

[0015] The ship-to-shore synchronization module is designed to adapt to communication scenarios involving weak ship-to-shore networks, high latency, and easy interruptions, ensuring that data is reliably, orderly, and efficiently synchronized to the shore platform.

[0016] The data service module provides standardized data access and push services to the shore-based monitoring platform, operation and maintenance system, and third-party business systems, while also undertaking the functions of access control and operation auditing.

[0017] The technical effects and advantages of this invention are as follows: 1. Unified access across multiple protocols reduces access costs. By using an edge access module compatible with multiple communication interfaces and protocols, and in conjunction with a hierarchical device instance binding mechanism based on similarity, the problem of heterogeneous protocols and scattered access for ship equipment is solved. There is no need to repeatedly develop access logic for a single device, which greatly improves device access efficiency and system scalability.

[0018] 2. Unify the data model and improve data usability. Through weighted scoring protocol identification and standardization conversion, heterogeneous data with different formats and units are transformed into a unified structure. At the same time, four levels of data quality verification and labeling are completed, solving the problems of data fragmentation and poor reusability, and providing a consistent data foundation for subsequent analysis and business calls.

[0019] 3. Adapt to weak network scenarios and ensure transmission reliability. Through local persistent caching, a three-level priority message queue, exponential backoff retries, and breakpoint resumption mechanisms, it adapts to scenarios with unstable ship-shore communication links, avoiding data loss due to communication interruptions; at the same time, priority scheduling ensures that critical data is transmitted first, and deduplication verification avoids data redundancy.

[0020] 4. Two-tiered diagnostic mechanism to enhance diagnostic intelligence. A two-tiered diagnostic architecture of "rule engine initial screening + AI intelligent diagnosis" is adopted. The rule engine quickly identifies known anomalies, while AI algorithms combine multi-source correlated data, historical trends, and a fault knowledge base for deep weighted reasoning, outputting fault causes, risk levels, and handling suggestions. This solves the problems of low accuracy and insufficient information dimensions in traditional threshold alarm diagnosis.

[0021] 5. End-to-end traceability supports operation and maintenance auditing. By linking and storing original messages with parsing results, managing the entire lifecycle of alarm state machines, and synchronously outputting diagnostic evidence chains, the entire process from raw data collection and abnormal alarms to diagnostic conclusions is traceable, facilitating fault review, compliance auditing, and operation and maintenance management.

[0022] 6. Unified data export to support business reuse. Data services are provided externally through multiple standardized interfaces, breaking down system data silos and enabling various business systems such as monitoring, remote control, and operations and maintenance to uniformly access data, avoiding redundant development and significantly improving system scalability. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating an intelligent diagnostic data analysis method for multi-protocol edge access in ship networking proposed in this invention.

[0024] Figure 2 This is a flowchart illustrating step S1 of the intelligent diagnostic data analysis method for multi-protocol edge access in the Internet of Ships proposed in this invention.

[0025] Figure 3 This is a flowchart illustrating step S2 in the intelligent diagnostic data analysis method for multi-protocol edge access in the Internet of Ships proposed in this invention.

[0026] Figure 4 This is a flowchart illustrating step S3 in the intelligent diagnostic data analysis method for multi-protocol edge access in the Internet of Ships proposed in this invention.

[0027] Figure 5 This is a flowchart illustrating step S4 of the intelligent diagnostic data analysis method for multi-protocol edge access in the Internet of Ships proposed in this invention.

[0028] Figure 6 This is a flowchart illustrating step S6 of the intelligent diagnostic data analysis method for multi-protocol edge access in the Internet of Ships proposed in this invention.

[0029] Figure 7 This is a structural block diagram of a ship network multi-protocol edge access intelligent diagnostic data analysis system proposed in this invention. Detailed Implementation

[0030] Embodiments of the present invention are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the invention, and should not be construed as limiting the invention. Rather, embodiments of the invention include all variations, modifications, and equivalents falling within the spirit and scope of the appended claims.

[0031] Example 1 refer to Figure 1 This embodiment proposes a method for intelligent diagnostic data analysis of multi-protocol edge access in ship networking. The execution entities are the edge computing gateway deployed on the ship and the shore-based data platform. The specific implementation process is as follows: S1. Receive ship equipment data and identify and bind device instances. Through multiple types of physical communication channels, receive raw message data output by various ship equipment, identify the characteristic information of the current acquisition channel, match it with a preset ship equipment instance library to complete device instance binding, and generate a globally unique device identifier for each device; thereby realizing multi-device data access and identity binding. (Reference) Figure 2 Specifically, this can include the following sub-processes: S1.1 Raw Message Reception. The ship's edge access gateway receives raw message data output by various ship equipment through multiple physical channels, including RS232 / RS485 serial ports, Ethernet ports, CAN gateways, PLC interfaces, and wireless networks. Ship equipment covers five major categories: navigation equipment, power equipment, electrical equipment, safety equipment, and environmental sensing equipment. Ship equipment data includes various types of content such as navigation parameters, equipment operating conditions, switch status, alarm codes, and operation logs. S1.2 Channel Feature Extraction and Similarity Matching. The system first reads the basic configuration information of each physical channel. This part consists of the static attributes of the physical channel, which is used for preliminary rule screening to quickly eliminate obviously mismatched devices and narrow down the candidate range. This is a "hard rule filtering" step. This includes channel number, interface type, serial port baud rate / parity bit, IP address, port number, CAN channel number, PLC station number, and MQTT subscription topic. Of course, other basic configuration information is not excluded, but details are not elaborated here. This information is initially matched with the pre-stored ship equipment ledger to filter the candidate device range. Secondly, by extracting the channel operation features, an I-dimensional acquisition channel feature vector V can be constructed. i=[v1, v2, ..., vI], where i is the channel feature vector dimension number, and I is the total dimension of the channel feature vector, which can be 8. This part consists of dynamic statistical features and encoded attribute features during channel operation. Its function is to perform refined similarity calculations within the candidate range after initial screening, distinguishing different devices under the same interface and protocol. This belongs to the "soft matching fine calculation" stage. The meanings of the 8 channel feature vector dimensions can be as follows: v1: average message arrival time interval; v2: average message length; v3: message sending cycle stability; v4: field separation type encoding; v5: normalized value of numerical range; v6: device installation area encoding; v7: historical communication success rate; v8: protocol type matching encoding. The channel feature vectors are then compared with the preset standard feature vectors V of each device in the device instance library. i Similarity calculation is performed, and cosine similarity can be used. The similarity value ranges from [0, 1], with higher values ​​indicating a higher match. The system sorts devices by similarity from highest to lowest, and devices with a similarity ≥ 0.7 are added to the candidate list. Because the channel's operational characteristics involve dynamic, real-time data, fluctuations in data can easily cause match inconsistencies. Similarity calculation methods may also include: calculating the initial similarity. V i It is the feature vector of the acquisition channel; V i 'Preset standard feature vector; h is the sampling time point number within a preset acquisition time period, which can be 1 minute or 30 seconds, etc., and will not be elaborated here. H is the total number of sampling time points within the preset acquisition time period. If the preset acquisition time period is 1 minute and the sampling time interval is 1 second, then H is 60. v ih It is the optimized value of the feature vector of acquisition channel i at time point h, v ih 'ω' is the optimized value of the feature vector of the acquisition channel with dimension number i at time point h. The optimized value is obtained by optimizing data values ​​into a specific numerical space according to their quality. Specific methods may include: obtaining the maximum and minimum values ​​based on historical records, then assigning values ​​in a stepwise manner according to quality and normalizing them, with superior data being greater than inferior data, and then proportionally scaling them to this numerical space. The numerical space can be 0-10. For example, historical communication success rate has a maximum value of 1 and a minimum value of 0. Data with higher success rate values ​​is considered superior, then normalized, and then scaled up 10 times, resulting in a value between 0 and 10. Specific techniques are existing and will not be elaborated upon here. i These are the weights of the feature vectors of the i-th dimension channel. If all weights are the same, their values ​​can all be 1. hThe length of time point h relative to the current time point can be in seconds or 10 seconds, depending on the actual situation. All numerical calculations in the formula are dimensionless. Then, the initial similarity obtained from the calculation is normalized to obtain the final similarity. This method ensures stable similarity calculation, avoids data fluctuations, and can quickly amplify differences without calculation distortion. S1.3 Hierarchical Device Binding. Different binding strategies are adopted depending on whether the message carries a unique identifier: If the message carries unique identifier fields such as MMSI, Modbus slave address, CANID, and device serial number, the system directly extracts the field and accurately matches it with the device instance library, completing the binding with one click, and the binding confidence is recorded as 1.0; If the message does not have a unique identifier field, a four-layer identification logic is adopted: Physical channel priority: the candidate device range is locked based on the physical channel number; Protocol feature assistance: the range is further narrowed based on the message protocol features and field structure; Installation location verification: cross-verification is performed based on the device installation compartment and the system to which it belongs; Manual confirmation as a fallback: the binding is finally completed by manual confirmation by the maintenance personnel. After binding is completed, a globally unique device number is generated, and the binding confidence score is calculated. This binding confidence score is obtained by weighting the initial matching similarity and dynamic similarity, with corresponding weights of 0.4 and 0.6 respectively, resulting in more accurate judgment. The specific process is not detailed here. During the S1.4 dynamic verification and update system operation, the channel data characteristics are continuously monitored, and the binding confidence score is recalculated every 10 collection cycles. When there is a port change, device replacement, sudden change in packet structure, or the binding confidence score is below the 0.8 threshold for three consecutive cycles, the device re-identification process is automatically triggered, and a manual review reminder is pushed to avoid problems such as data crosstalk and incorrect device connection.

[0032] S2. Automatic Protocol Type Identification, Field Parsing, and Device Data Standardization. Based on the message characteristics and channel configuration information of the original message, the corresponding communication protocol type is identified. The original message is stored, and the parsing rules of the corresponding protocol are called to extract message fields. The parsed field data undergoes validity verification and standardization transformation to generate standardized device data conforming to a unified data model. (Reference) Figure 3Specifically, it includes the following sub-processes: S2.1 The protocol type automatic identification system combines channel configuration and message characteristics, employing a weighted scoring mechanism to automatically identify communication protocol types. It supports six major categories of mainstream ship equipment protocols: NMEA0183, ModbusRTU / TCP, CAN2.0B, TCP private protocol, UDP private protocol, and MQTT. Multiple scoring dimensions and corresponding weights can be set, typically six: channel configuration matching degree, message header matching degree, field structure matching degree, verification result matching degree, data length range matching degree, and device type matching degree. Other dimension settings are not excluded, but will not be elaborated here. Their corresponding weights can be 0.40, 0.30, 0.15, 0.10, 0.03, and 0.02, respectively. For each candidate protocol, a single-item score s is calculated for each of the six dimensions. j The comprehensive matching score is obtained by weighted summation: Where j is the matching dimension number, J is the total number of matching dimensions (which can be 6), and s j The matching value for number j can be obtained through the degree of matching. For example, a perfect match with the channel's preset protocol earns 100 points, a partial match earns 50 points, and no match earns 0 points. Details will not be elaborated here. Then, the overall matching score S is calculated. total The protocol type is determined through a process called "determination". The determination rules are as follows: when a certain protocol S... total If the score is ≥80 and higher than all other candidate protocols, it is determined to be this protocol type; if there are two or more protocols with scores less than a preset score (10 points), a secondary determination is made based on the bound device instance type, the historical protocol identification results of this channel, and the manually preset protocol priority; if all candidate protocols S total If the value is less than 60, the message is marked as "unknown protocol," and the original message and channel information are fully preserved for subsequent manual analysis and rule expansion. The core identification features of typical protocols are as follows: NMEA protocol: begins with "$" or "!", ends with a carriage return and line feed, fields are separated by commas, and the end includes an asterisk (*) followed by a two-digit hexadecimal checksum; Modbus protocol: includes slave address, function code, register address, data length field, and CRC / LRC checksum matching; CAN protocol: includes standard frame / extended frame ID, data length code (DLC), and 0-8 byte data payload; TCP / UDP private protocols: matches fixed frame header and trailer, length field, and custom separators; MQTT protocol: matches topic level, client ID, QoS level, and JSON payload structure. The above judgment process is complex and often requires manual analysis, increasing the difficulty of a fully automated process. The comprehensive matching score can also include... Where j is the matching dimension number, J is the total number of matching dimensions, and w jHere, we define the weight corresponding to the matching dimension numbered j, and its value can be the weight described above. k is the core feature number, K is the total number of core features for the matching dimension numbered j, and s... jk This represents the matching value of the core feature k in the matching dimension j, ranging from 1 to a, where a is the maximum matching value, which can be 10. The value can be set according to the degree of matching: 10 for a perfect match and 1 for a complete mismatch. Gradient settings are then applied based on the degree of matching. Other methods are also possible, but will not be elaborated upon here. T represents the core feature s. jk The matching order can be calculated based on the unique features of the core features in each matching dimension, and its value can be... Where T' represents the uniqueness of the core feature in each matching dimension. For example, if the uniqueness is 1, then T=6. Other values ​​are not elaborated here. Then, the comprehensive matching score T is calculated. totalThe most important protocol determination is the protocol type. This method allows for evaluation of core characteristic uniqueness, enabling the identification of unique core characteristics, increasing the proportion of unique characteristics, improving accuracy, and simplifying the determination process. S2.2 Raw Message Storage: The system associates and stores the received raw message, receiving timestamp, corresponding device number, identified protocol type, acquisition channel number, and global tracking ID. The raw message is persistently stored using lossless compression, serving as the original basis for subsequent parsing verification, alarm tracing, and diagnostic auditing. S2.3 Protocol Field Parsing: The system calls the parsing rule base corresponding to the protocol type to extract business fields from the raw message, including latitude and longitude, heading, speed, and heading for navigation; speed, temperature, pressure, and flow rate for power; voltage, current, power, and frequency for electrical; and operating status code, alarm code, and switch status for status. During parsing, abnormal messages are simultaneously identified, including empty messages, garbled messages, verification failure messages, missing field messages, and abnormal length messages. Abnormal messages are marked with their abnormal type and retained, and do not enter subsequent standardization processes. S2.4 Data Validation and Standardization Conversion: The system performs data governance on the parsed raw fields, including validity verification and standardization conversion. Data validation includes five logic steps: Null value detection: filtering invalid null fields and marking missing data; Out-of-bounds judgment: verifying whether the indicator value is within the physical reasonable range and the equipment's rated range, and identifying abnormal jumps; Duplicate value filtering: removing duplicate messages based on "device number + collection timestamp"; Timestamp calibration: uniformly converting to UTC standard timestamps and correcting device clock drift; Unit identification: identifying the original unit of the field to provide a basis for subsequent conversions. After validation, each data entry is marked with four data quality levels: Excellent (all validations passed), Acceptable (minor deviations do not affect use), Abnormal (values ​​out of bounds / partially missing), and Invalid (unusable). Standardization conversion maps all fields to a unified standardized data model. The core fields are as follows: Basic device information: device id (globally unique device ID), device type (device type code), install location (installation location). Indicator information: metric code (unified indicator code), metric value (indicator value), unit (standard unit of measurement). Collection information: collect time (UTC standard collection timestamp), protocol type, raw message ID. Quality information: data quality level. By unifying the data model, the differences in data formats between different protocols and devices are eliminated, providing a consistent data foundation for subsequent analysis and retrieval.

[0033] S3. Perform local caching and ship-to-shore synchronization. Standardized equipment data is written to the ship's local time-series storage unit for caching, and the ship-to-shore communication link status is monitored in real time. When the communication link is normal, data is uploaded to the shore platform; when the communication link is abnormal, data is written to a pending message queue, and interrupted transmission is resumed according to time priority after communication is restored. This achieves reliable transmission of ship-side data caching in weak network environments. (Reference) Figure 4 Specifically, this can include the following sub-processes: S3.1 Local Time-Series Storage: Standardized device data is first written to a local time-series database on the ship for persistent storage, supporting local querying, historical analysis, and edge computing. S3.2 Communication Status Detection and Queue Scheduling: Real-time detection of communication link availability. Data to be sent enters a message queue with three priority levels: Level 1 (highest): alarm events, diagnostic results, etc.; Level 2 (second highest): operating indicators of key equipment such as mainframes and power distribution systems; Level 3 (lowest): general environmental data, operating logs, etc. The system schedules data transmission from high to low priority, ensuring priority transmission of critical information in abnormal situations. S3.3 Exponential Backoff Retry: When data transmission fails, an exponential backoff strategy is used for retries. The waiting time for the nth retry is: Where n is the number of retries, T0 is the initial retry interval (T0 can be set to 1 second by default), and b is the retry amplification base, which should be greater than 1, generally 2. The maximum retry interval should not exceed 60 seconds. If 5 consecutive retries fail, the link is considered abnormal, the data is persisted to the local cache queue, and active transmission is stopped. This method avoids the overhead of failed data transmissions, thus allocating resources reasonably and ensuring timely data upload. S3.4 Resumable Transmission and Deduplication Verification: After the communication link is restored, the resumed transmission unit uploads cached data in batches according to the "first-in, first-out" principle, based on the collection time from earliest to latest. During the upload process, each piece of data generates a unique primary key using "deviceid + collecttime". The receiving platform verifies the primary key upon receipt, discarding existing data to prevent duplicate data from being entered into the database and ensuring data consistency on the receiving end.

[0034] S4, Rule Engine Alarm and State Machine Management: The rule engine performs multi-dimensional anomaly matching and judgment on standardized device data. When an anomaly rule is matched, an alarm event is generated. The alarm state machine manages the entire lifecycle of the alarm event, enabling multi-dimensional anomaly detection and full lifecycle management of alarms. (Reference) Figure 5Specifically, it includes the following sub-processes: S4.1 Multi-dimensional rule engine judgment: The rule engine unit performs anomaly matching on real-time standardized data based on a preset alarm rule library, supporting 6 types of anomaly judgment logic: Threshold judgment: Determines whether the indicator value exceeds the upper threshold or falls below the lower threshold; Duration judgment: An alarm is generated only after the abnormal state has lasted for a preset duration to avoid false alarms due to instantaneous fluctuations; Status change judgment: Identifies the transitions of switch quantities, status codes, and fault codes; Data missing judgment: Detects the data update cycle, and triggers a data interruption alarm if the update is not updated within the time limit; Device offline judgment: Determines device offline based on heartbeat response and the number of consecutive failed data collections; Multi-indicator combination judgment: Identifies composite faults by combining the abnormal characteristics of multiple related indicators. S4.2 Alarm level calculation: Combining 5 dimensions, as follows: Rule priority weight 0.30, with the highest weight for core safety rules; Indicator importance weight 0.25, including key equipment such as hosts and power distribution; Abnormal duration weight 0.20, including levels with longer durations; Trigger count weight 0.15, including levels with short-term repeated triggers; Device security level weight 0.10, including levels of security-related equipment. Then, the alarm level score is calculated using a weighted scoring method based on the individual quantitative scores of each dimension [scores range from 0 to 100, for example, based on the security attributes of the alarm rule itself, it is divided into 4 levels: - Core security rules (fire alarm, host failure, power failure, etc.): 100 points; - Important equipment rules (auxiliary machine abnormality, power distribution over-limit, etc.): 70 points; - General monitoring rules (ambient temperature and humidity, normal state changes, etc.): 40 points; Alert rules (data update delay, etc.): 10 points]. The alarm comprehensive score (0-100) is then divided into three levels based on the comprehensive alarm score: 0-40 is a general alarm, 41-70 is an important alarm, and 71-100 is a severe alarm. S4.3 alarm state machine implements closed-loop management, performing full lifecycle management after alarm generation. It sets five states: Unconfirmed, Confirmed, Processing, Recovered, and Closed. Initial generation: Unconfirmed; Manual confirmation by maintenance personnel: Changed to Confirmed; Maintenance personnel initiate handling: Marked as Processing; Abnormal indicators return to normal range and remain so for 300 seconds (anti-jitter duration): Automatically changed to Recovered; Maintenance personnel verify and confirm fault resolution: Manually changed to Closed. The state machine records the trigger time, operator, and operation notes for each state throughout the entire process, ensuring full traceability of alarm handling.

[0035] S5, AI-powered intelligent diagnosis and evidence chain generation: When an alarm event occurs or an active diagnosis request is received, the AI ​​diagnosis module is invoked. Centered on the moment of the anomaly, multi-source correlated data is extracted to construct a device operation feature vector. This vector is then combined with a fault knowledge base and historical fault samples for comprehensive reasoning to generate a diagnostic conclusion and a traceable diagnostic evidence chain; achieving intelligent fault reasoning and traceable output based on multi-source data. (Reference) Figure 6Specifically, it includes the following sub-processes: S5.1 Diagnostic Trigger and Data Extraction: When a critical / important alarm is generated, or when a user initiates an active diagnostic request, the AI ​​diagnostic process is triggered. Centered on the alarm trigger time, real-time data of the target device within 10 minutes before and after the alarm, historical data from the same period over the past 7 days, data from related devices in the same system, and environmental data from the same period are extracted. S5.2 Multi-dimensional Feature Vector Construction: Based on the extracted data, a 9-dimensional feature vector F=[f1, f2, ..., f9] is constructed for device operation. Other dimensions are not excluded. The meanings of each dimension are as follows: f1: Current real-time value of the indicator; f2: Average value of the indicator within the time period; f3: Maximum value of the indicator within the time period; f4: Minimum value of the indicator within the time period; f5: Rate of change of the indicator (amount of change in value per unit time); f6: Variance of the indicator fluctuation; f7: Duration of the anomaly (unit: seconds); f8: Pearson correlation coefficient of the related indicator; f9: Data quality score. S5.3 Knowledge Base Matching and Comprehensive Diagnostic Reasoning: The feature vector is matched with the fault knowledge base to calculate the sub-item scores D. m Then, based on the itemized score D m Calculate the overall diagnostic score and the individual item scores (D). m It can include five sub-scores based on the fault knowledge base storing device fault modes, expert diagnostic rules, historical fault case library, and device standard operating baseline: rule hit score D1, historical similarity score D2, trend anomaly score D3, associated device consistency score D4, and data quality score D5. These scores are then summed by corresponding weights to obtain the comprehensive diagnostic score. The system employs several metrics: Rule Hit Score D1 (weight β10.30): Matches fault judgment conditions in the expert rule base; the more rules matched, the higher the score. Historical Similarity Score D2 (weight β20.25): Calculates the cosine similarity between the current feature vector and the features of historical fault samples; higher similarity indicates a greater likelihood of fault. Trend Anomaly Score D3 (weight β30.20): Calculates the degree and rate of change of the current indicator deviating from the normal baseline; more severe deviations result in a higher score. Related Equipment Consistency Score D4 (weight β40.15): Verifies whether upstream / downstream / system-related equipment exhibits synchronization anomalies; more related anomalies increase confidence. Data Quality Score D5 (weight β50.10): Adjusts the score based on data quality level; lower data quality leads to greater confidence reduction. The system sorts candidate fault causes from highest to lowest based on the comprehensive diagnostic score, outputs the top 3 possible fault causes, and provides anomaly type, risk level, impact scope analysis, and handling suggestions. Taking a host exhaust temperature rise alarm as an example: if the exhaust temperature rise is accompanied by a synchronous rise in cooling water outlet temperature and no significant increase in host load, the cooling system anomaly score is the highest, and the recommended handling is to check the cooling water pump, clean the pipes, and check the coolant level; if the exhaust temperature rise is synchronized with the increase in host load and speed, the high load normal temperature rise score is the highest, and the risk level is moderate; if only a single sensor value changes abruptly, and all other related indicators remain stable, the sensor anomaly score is the highest. S5.4 Diagnostic Evidence Chain Generation: Simultaneously with the AI ​​diagnostic output conclusion, a diagnostic evidence chain is generated. The evidence chain includes: the specific indicator and value that triggered the alarm; the corresponding original message ID; the matched alarm rule entries; historical trend comparison data of the indicators; related device status data; and matching knowledge base entries and historical case IDs. Through the evidence chain, maintenance personnel can trace back all the basis for the diagnosis, verify the rationality of the diagnostic conclusion, and facilitate subsequent fault review and knowledge base iteration optimization.

[0036] S6. Unified Data Distribution and Service Openness: Standardized equipment data, alarm events, diagnostic conclusions, and operational records are distributed externally through multiple standardized interfaces, providing a unified data access point for upper-layer business systems. This standardization data output includes the following: The data service module provides standardized equipment data, alarm events, diagnostic conclusions, and operational statistics reports externally through multiple interfaces, supporting calls from various upper-layer business systems: 1. REST API Interface: Provides query services such as historical data query, alarm query, diagnostic result query, and equipment ledger query, supporting parameterized filtering and paginated queries; 2. MQTT Message Push: Pushes equipment status data, alarm events, and diagnostic results in real time, categorized by device, system, and alarm level, supporting on-demand subscription by business systems; 3. WebSocket Push: Provides millisecond-level real-time data push to the web monitoring frontend, supporting dynamic refresh of the visual monitoring page; 4. Report Export: Automatically generates daily / weekly / monthly equipment operation reports, alarm statistics reports, and diagnostic analysis reports, supporting PDF / Excel format export. Simultaneously, permissions and audit units are configured to control data access permissions based on roles, and logs are recorded for all data queries, configuration modifications, and diagnostic operations, including the operator, operation time, and operation content, to meet the requirements for ship data security and compliance auditing.

[0037] Example 2 refer to Figure 7 The present invention proposes a ship network multi-protocol edge access intelligent diagnostic data analysis system, as detailed below: The ship equipment layer, deployed in various compartments and decks of the ship, is the input starting point for the entire data acquisition and analysis process. It can include five major categories of ship equipment: navigation equipment, power equipment, electrical equipment, safety equipment, and environmental sensing equipment, providing the system with raw data sources.

[0038] The edge access module, used for physical channel management, device identity binding, raw data acquisition, and device online status detection, is the first processing stage for data entering the system. It can include a channel management unit, a device binding unit, a data acquisition unit, and a heartbeat detection unit. The channel management unit manages all physical communication channels, including serial ports, Ethernet, CAN bus, and PLC interfaces, and is responsible for channel parameter configuration, connection establishment / disconnection, channel operation status monitoring, and communication statistics. The device binding unit performs matching and binding between acquisition channels and device instances, with a built-in similarity calculation engine and hierarchical recognition logic, completing channel feature extraction, similarity calculation, hierarchical identity determination, binding confidence calculation, and dynamic verification updates. The data acquisition unit collects complete raw messages from the physical channels according to the communication protocol specifications of each device, through active polling or passive listening. The heartbeat detection unit periodically sends heartbeat commands to devices or indirectly detects the online / offline status of devices through data update cycles, providing a basis for subsequent rule engine-based device offline alarms.

[0039] The protocol parsing module is the core of protocol identification and structured parsing of raw messages. It converts unstructured raw messages of different protocols into structured fields, which is a pre-processing step for data standardization. It can include a protocol identification unit, a field parsing unit, a unit conversion unit, and an abnormal message identification unit. The protocol identification unit has a built-in six-dimensional weighted scoring model that combines multi-dimensional features such as channel configuration, message structure, and verification results to automatically identify protocol types such as NMEA, Modbus, CAN, TCP / UDP, and MQTT. It supports secondary judgment in fuzzy scenarios and unknown protocol marking. The field parsing unit is used to call the parsing rule base of the corresponding protocol to extract business fields such as navigation parameters, equipment operating conditions, status codes, and alarm codes from the original message, completing the conversion of the message from unstructured to structured. The unit conversion unit is used to uniformly convert heterogeneous measurement units output by different devices and different protocols into international standard units, eliminating unit differences and laying the foundation for subsequent standardized modeling. The abnormal message identification unit is used to identify invalid data such as empty messages, garbled messages, verification failure messages, missing field messages, and abnormal length messages, classify and mark abnormal messages and retain them to prevent invalid data from entering the subsequent process and polluting the analysis results.

[0040] The data governance and caching module is used for raw message retention, data quality control, unified model transformation, and local cache storage, connecting the parsing layer and the analysis / transmission layer. It can include a raw message storage unit, a standardization transformation unit, a data quality verification unit, a time-series data storage unit, and a local cache unit. The raw message storage unit is used for lossless persistent storage of all raw messages, synchronously associating them with device number, protocol type, acquisition channel, acquisition time, and global tracking ID, providing original evidence for subsequent fault tracing, audit verification, and problem analysis. The standardization conversion unit is used to map heterogeneous parsed fields to a unified standardized data model, unifying field naming, data format, and time format, eliminating data structure differences between different devices and protocols. The data quality verification unit is used to perform five data verifications: null value detection, out-of-bounds judgment, duplicate value filtering, and timestamp calibration. It also combines the bound confidence level to correct the data quality level, classifying the data into four levels: high-quality, qualified, abnormal, and invalid. The time-series data storage unit is used to persistently store standardized data locally on the ship using a time-series database, supporting efficient time range queries, historical trend statistics, and device baseline calculation, providing local historical data support for edge alarm analysis and AI diagnosis. The local cache unit is used to persistently store standardized data to be uploaded, alarm events, and diagnostic results when ship-to-shore communication is abnormal, serving as a data carrier for breakpoint resume transmission and avoiding data loss caused by communication interruption.

[0041] The alarm diagnosis module, responsible for anomaly detection, alarm management, multi-source correlation analysis, and AI-powered intelligent diagnosis, is the core embodiment of the solution's intelligent value. It can include: a rule engine unit, an alarm state machine unit, a historical trend analysis unit, a multi-source correlation analysis unit, an AI diagnosis unit, and an evidence chain generation unit. The rule engine unit performs threshold judgment, duration judgment, state change judgment, data missing judgment, device offline judgment, and multi-indicator combination judgment for anomaly matching; it calculates alarm levels through weighted scoring and adjusts the final alarm score based on bound confidence levels, filtering low-confidence false alarms. The alarm state machine unit performs closed-loop management of alarm events throughout their entire lifecycle, maintaining flow rules for five states: unconfirmed, confirmed, processing, recovered, and closed, recording the trigger time, operator, and operation notes for each state; it has a built-in recovery debouncing mechanism to avoid false alarm recovery caused by instantaneous fluctuations. The historical trend analysis unit statistically analyzes the historical operating patterns of equipment indicators, calculating trend characteristics such as the equipment's normal operating baseline, rate of change, and fluctuation amplitude, providing data for AI diagnosis. The diagnostic system provides historical comparison data; the multi-source correlation analysis unit is used to correlate data from multiple devices and multiple indicators within the same time window, analyze the correlation and synchronization anomaly characteristics between indicators, and identify complex anomalies that cannot be detected by a single indicator; the AI ​​diagnostic unit has a built-in fault knowledge base and weighted inference engine, which constructs a multi-dimensional feature vector of device operation when an alarm is triggered or active diagnosis is performed, and outputs the sorted fault causes, risk levels and handling suggestions through weighted inference based on five scores: rule hit, historical similarity, trend anomaly, correlation consistency and data quality; the evidence chain generation unit is used to synchronously assemble the entire chain of diagnostic evidence, including trigger indicators, original message IDs, hit rules, historical trends, associated device status and knowledge base entries, to form a traceable diagnostic evidence chain.

[0042] The ship-to-shore synchronization module serves as the data transmission hub between the ship and shore ends. It is adapted to communication scenarios characterized by weak network conditions, high latency, and frequent interruptions, ensuring reliable, orderly, and efficient data synchronization to the shore platform. It includes a message queue unit, retry control unit, deduplication verification unit, breakpoint resumption unit, and communication status detection unit, implementing three-level priority scheduling, exponential backoff retries, and breakpoint resumption. The message queue unit manages the queue of data to be sent, setting a three-level transmission priority (highest for alarms / diagnoses, followed by critical equipment data, and lowest for general data), and schedules data transmission according to priority to ensure that critical information is transmitted first. The retry control unit uses an exponential backoff strategy to retry data when transmission fails, controlling the retry interval and maximum number of retries to avoid frequent retries exacerbating network congestion. The deduplication verification unit generates a unique primary key for data based on "device number + collection timestamp" and performs deduplication verification during data upload to avoid duplicate data entering the database and ensure data consistency at the shore end. The breakpoint resume transmission unit retransmits historical data in batches from the data collection time to the latest order after communication is restored, ensuring data integrity. The communication status detection unit uses a dual mechanism of heartbeat packets and transmission success rate to detect the availability of the ship-shore communication link in real time, and automatically switches between "real-time transmission mode" and "buffered storage mode" according to the link status.

[0043] The data service module serves as the system's external data service outlet, providing standardized data access and push services to the onshore monitoring platform, operation and maintenance system, and third-party business systems. It also undertakes access control and operation auditing functions. This may include API service units, MQTT push units, WebSocket push units, report generation units, and access auditing units. The API service unit provides a standardized REST-style query interface, supporting historical data queries, alarm queries, diagnostic result queries, and equipment ledger queries, as well as parameterized filtering, paginated queries, and permission verification. The MQTT push unit categorizes message topics by device, system, and alarm level, pushing real-time device status data, alarm events, and diagnostic results, supporting on-demand subscription by multiple business systems. The WebSocket push unit provides millisecond-level real-time data push to the web monitoring frontend, supporting dynamic refresh of the visual monitoring page and ensuring the real-time display. The report generation unit automatically generates daily / weekly / monthly equipment operation reports, alarm statistics reports, and diagnostic analysis reports, supporting PDF / Excel export for maintenance review and management reporting. The permission audit unit implements fine-grained data access control based on roles, while fully recording the operator, operation time, and operation content of data queries, configuration modifications, diagnostic operations, and alarm handling, meeting the requirements of ship data security and compliance auditing.

[0044] It should be understood that the various forms of processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this invention disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this invention can be achieved, and this is not limited herein.

[0045] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for intelligent diagnostic data analysis of multi-protocol edge access in ship networking, characterized in that, The intelligent diagnostic data analysis method for multi-protocol edge access in the ship network includes: S1. Receive raw message data output by various types of ship equipment through multiple physical communication channels, identify the characteristic information of the current acquisition channel, match it with the preset ship equipment instance library to complete the equipment instance binding, and generate a globally unique equipment identifier for each device. S2. Based on the message characteristics and channel configuration information of the original message, identify the corresponding communication protocol type, store the original message and call the parsing rules of the corresponding protocol to extract the message fields, perform legality verification and standardization conversion on the parsed field data, and generate standardized device data that conforms to the unified data model. S3. Write standardized equipment data into the ship's local time-series storage unit for caching and monitor the ship-shore communication link status in real time. When the communication link is normal, upload the data to the shore platform. When the communication link is abnormal, write the data into the message queue to be sent. After the communication is restored, resume the transmission according to the time priority. S4. The rule engine performs multi-dimensional anomaly matching and judgment on standardized device data. When an anomaly rule is hit, an alarm event is generated. The alarm state machine manages the state transition of the alarm event throughout its entire lifecycle. S5. When an alarm event occurs or an active diagnosis request is received, the AI ​​diagnosis module is invoked to extract multi-source related data centered on the abnormal moment to construct the device operation feature vector. Combined with the fault knowledge base and historical fault samples, comprehensive reasoning is performed to generate a diagnosis conclusion and a traceable chain of diagnostic evidence. S6. Distribute standardized equipment data, alarm events, diagnostic conclusions, and operation records to external systems through multiple types of standardized interfaces, providing a unified data access point for upper-layer business systems.

2. The intelligent diagnostic data analysis method for multi-protocol edge access in ship networking according to claim 1, characterized in that, Step S1 includes: S1.1 receiving the original message; S1.2 channel feature extraction and similarity matching; S1.3 hierarchical device binding; S1.4 dynamic verification and update.

3. The intelligent diagnostic data analysis method for multi-protocol edge access in ship networking according to claim 2, characterized in that, Channel feature extraction and similarity calculation include: the system first reads the basic configuration information of each physical channel and performs a preliminary match with the pre-stored ship equipment ledger to filter the range of candidate equipment; secondly, it extracts the channel operation features and constructs an I-dimensional acquisition channel feature vector; and thirdly, it calculates the similarity between the channel feature vector and the preset standard feature vector of each device in the equipment instance library.

4. The intelligent diagnostic data analysis method for multi-protocol edge access in ship networking according to claim 3, characterized in that the channel Feature vector V i =[v1, v2, ..., v I ], where I is 8; v1: average message arrival time interval; v2: average message length; v3: message transmission cycle stability; v4: field separator type encoding; v5: normalized value of numerical range; v6: device installation area encoding; v7: historical communication success rate; v8: protocol type matching encoding.

5. The intelligent diagnostic data analysis method for multi-protocol edge access in ship networking according to claim 2, characterized in that, The hierarchical device binding includes the following: different binding strategies are adopted based on whether the message carries a unique identifier: if the message carries a unique identifier, the system directly extracts the field and accurately matches it with the device instance library, completing the binding with one click, and the binding confidence level is recorded as 1.0; if the message does not have a unique identifier, a four-layer identification logic is adopted: physical channel priority: the candidate device range is locked based on the physical channel number; protocol feature assistance: the range is further narrowed based on the message protocol features and field structure; installation location verification: cross-verification is performed in combination with the device installation compartment and the system to which it belongs; manual confirmation as a fallback: the binding is finally completed by manual confirmation by the operation and maintenance personnel. After the binding is completed, a globally unique device number is generated, and the binding confidence level is calculated.

6. The intelligent diagnostic data analysis method for multi-protocol edge access in ship networking according to claim 1, characterized in that, Automatic protocol type identification includes: the system combines channel configuration and message characteristics, employs a weighted scoring mechanism to automatically identify communication protocol types, sets multiple scoring dimensions and corresponding weights, and calculates individual scores s for each candidate protocol across six dimensions. j The comprehensive matching score S is obtained by weighted summation. total Then, through comprehensive matching, S total The protocol type is determined through a judgment process.

7. The intelligent diagnostic data analysis method for multi-protocol edge access in ship networking according to claim 6, characterized in that, The rules for determining the protocol type are as follows: When a certain protocol S total If the score is ≥80 and higher than all other candidate protocols, it is determined to be this protocol type; if there are two or more protocols with scores less than a preset score, a secondary determination is made based on the bound device instance type, the historical protocol identification results of this channel, and the manually preset protocol priority; if all candidate protocols S total If the value is less than 60, the message is marked as an unknown protocol, and the original message and channel information are fully preserved for subsequent manual analysis and rule expansion.

8. The intelligent diagnostic data analysis method for multi-protocol edge access in ship networking according to claim 1, characterized in that, S5 includes: S5.1 Diagnostic triggering and data extraction; S5.2 Multi-dimensional feature vector construction, which constructs a 9-dimensional feature vector F=[f1, f2, ..., f9] based on the extracted data; S5.3 Knowledge base matching and comprehensive diagnostic reasoning, which matches the feature vector with the fault knowledge base to calculate the sub-item scores, and then calculates the comprehensive diagnostic score based on the sub-item scores. The system sorts the candidate fault causes from high to low according to the comprehensive diagnostic scores, outputs the top 3 possible fault causes, and outputs the anomaly type, risk level, impact range analysis and handling suggestions.

9. The intelligent diagnostic data analysis method for multi-protocol edge access in ship networking according to claim 8, characterized in that, The 9-dimensional feature vector F = [f1, f2, ..., f9] has the following meanings for each dimension: f1: real-time value of the current indicator; f2: average value of the indicator within the time period; f3: maximum value of the indicator within the time period; f4: minimum value of the indicator within the time period; f5: rate of change of the indicator; f6: variance of the indicator fluctuation; f7: duration of the anomaly. f8: Pearson correlation coefficient; f9: Data quality score.

10. A ship-to-everything (SLO) multi-protocol edge access intelligent diagnostic data analysis system, characterized in that: include: Edge access module is used for physical channel management, device identity binding, raw data acquisition, and online device status detection; The protocol parsing module is the core of protocol identification and structured parsing of raw messages, converting unstructured raw messages of different protocols into structured fields; The data governance and caching module is used for original message retention, data quality control, unified model conversion, and local cache storage. The alarm diagnosis module is used to carry out anomaly detection, alarm management, multi-source correlation analysis and AI intelligent diagnosis functions; The ship-to-shore synchronization module is designed to adapt to communication scenarios involving weak ship-to-shore networks, high latency, and easy interruptions, ensuring that data is reliably, orderly, and efficiently synchronized to the shore platform. The data service module provides standardized data access and push services to the shore-based monitoring platform, operation and maintenance system, and third-party business systems, while also undertaking the functions of access control and operation auditing.

Images