A ship heterogeneous information output method and system based on data exchange middleware

Abstract

The application relates to the technical field of ship information processing, and provides a ship heterogeneous information output method based on data exchange middleware, which comprises the following steps: S1: a plurality of independent threads are used to respectively listen to data packets from a ship communication navigation system, an integrated monitoring and alarming system, a network communication system and a video monitoring system, corresponding analyzers are dynamically identified and loaded according to protocols adopted by the data packets to perform analysis, and service data is extracted from original data; S2: the extracted service data is subjected to field mapping and data conversion according to a predefined ship unified data model, structured data conforming to the unified data model is formed, and the structured data is serialized into a standard JSON format; and S3: standard JSON format data is pushed in real time to a subscription client which has established a WebSocket connection through the WebSocket protocol. The technical scheme can realize unified access and standardized output of data of various heterogeneous systems of a ship.

Description

Technical Field

[0001] This invention relates to the technical field of ship information processing, and in particular to a method and system for outputting heterogeneous ship information based on data exchange middleware. Background Technology

[0002] To meet the demands of navigation safety, automated control, and efficient operation, modern ships are typically equipped with various information systems, including: communication and navigation systems (such as autopilot, anemometers, depth sounders, GPS, and logs); integrated monitoring and alarm systems (such as engine room monitoring and alarm systems (AMS), cargo control systems, valve control systems, and liquid cargo monitoring systems); network communication systems (such as 4G / 5G routers, firewalls, and switches); and video surveillance systems (such as CCTV and unsafe behavior alarms). Among these ship digital systems, communication and navigation systems, integrated monitoring and alarm systems, network communication systems, and CCTV video surveillance systems are all well-developed, each possessing independent communication interfaces and data output capabilities, typically providing data externally via serial ports and Ethernet ports.

[0003] In practical applications of existing technologies, the various systems deployed on ships operate independently, with each system processing, storing, and applying its own data. There is no unified medium within the entire ship's information system to simultaneously view comprehensive ship information. Specifically, the data outputs of each system use different communication methods or protocols, making it impossible to connect multiple systems simultaneously via a single communication link. Furthermore, if the data provider experiences an anomaly, it directly impacts the data application, requiring the application to handle the anomaly and execute additional exception processing logic. Therefore, effective decoupling between the data application and the data provider is lacking.

[0004] In summary, the existing technology has the following problems: (1) Protocol heterogeneity: Different types of systems use their own different communication protocol standards. For example, communication and navigation systems generally use the NMEA / IEC61162-450 standard; cabin monitoring systems mostly use Modbus RTU / TCP or MQTT protocols; and network communication systems use SNMP / Syslog protocols. In addition, many manufacturers also have proprietary protocols, which further exacerbates the complexity of protocol heterogeneity.

[0005] (2) Data silos: As each system operates independently, the data generated is also stored in its own independent system. When the crew conducts daily monitoring or troubleshooting, they have to switch frequently between multiple different operating terminals, which makes it impossible to form a unified view of the ship's operating status and seriously affects the crew's situational awareness and decision-making efficiency.

[0006] (3) High integration complexity: When it is necessary to develop upper-layer applications to obtain data from multiple systems, application developers must write special adaptation code for each communication protocol and repeatedly handle underlying basic functions such as connection management, exception recovery, and data parsing, resulting in a huge workload and long development cycle.

[0007] Further analysis of the shortcomings of existing technologies reveals the following: due to protocol fragmentation, each system needs to independently develop a corresponding adaptation layer, which directly leads to a significant increase in development costs and a marked extension of the development cycle; at the same time, due to heterogeneous data formats, the application layer has to understand and process multiple different protocol formats, resulting in a high degree of coupling between business logic and data parsing logic, which is not conducive to system maintenance and expansion.

[0008] In summary, there is an urgent need to propose a data exchange middleware that can unify access to various heterogeneous systems on a ship, shield the differences in underlying protocols, realize standardized data conversion, and provide decoupling capabilities, in order to solve the problems of protocol heterogeneity, data silos, and complex integration in existing technologies. Summary of the Invention

[0009] To address the aforementioned problems, the present invention aims to provide a method and system for outputting heterogeneous information from ships based on data exchange middleware. This system enables unified access and standardized output of data from various heterogeneous systems within a ship, eliminating the need for the application layer to concern itself with underlying protocol differences. When adding a new data source, only the middleware needs to be extended without modifying the application layer code, thereby significantly reducing integration complexity and achieving complete decoupling between the application layer and the data layer.

[0010] The above-mentioned objective of this invention is achieved through the following technical solutions: A method for outputting heterogeneous ship information based on a data exchange middleware includes the following steps: S1: Multiple independent threads monitor data packets from the ship's communication and navigation system, integrated monitoring and alarm system, network communication system, and video surveillance system. Based on the protocol used by the data packets, the corresponding parser is dynamically identified and loaded for parsing. Business data is extracted from the raw data. The types of data packets monitored include: communication and navigation system data, integrated monitoring and alarm system data, network communication system data, and video surveillance data. S2: The extracted business data is mapped and transformed according to the predefined unified data model for ships to form structured data that conforms to the unified data model. The structured data is then serialized into standard JSON format. S3: Based on a publish-subscribe architecture, standard JSON format data is pushed in real time to subscribing clients with established WebSocket connections via the WebSocket protocol. When establishing a WebSocket connection, the client carries the variables to be subscribed and the type of data to be received. The data exchange middleware continuously pushes data according to a set period.

[0011] Further, in step S1, the parsing of the communication navigation system data includes: The information of the ship's communication and navigation equipment is collected in real time via the NMEA / IEC61162-450 protocol. The communication and navigation equipment includes devices such as autopilot, wind direction and speed meter, depth sounder, GPS, log, electronic compass and AIS. The access methods include access via RS485 serial port with NMEA protocol and access via Ethernet with IEC61162-450 protocol. During the data acquisition process, the middleware dynamically identifies the protocol type of the data frame, performs start flag verification, checksum verification and integrity check on each data frame, filters abnormal or incomplete data packets, and extracts valid communication data fields. The extracted valid data is given a unified collection timestamp and source device identifier to form a structured communication data record. The data is then classified and stored according to device type and data category. At the same time, the parsed data is persisted to the historical database to support subsequent queries and traceability. It provides a standardized historical data query interface, supports combined searches based on conditions such as device name, time range, and data type, and allows batch export of query results.

[0012] Further, in step S1, the parsing of the integrated monitoring and alarm system data includes: Data from ship engine room equipment is collected via protocols including Modbus TCP / RTU or MQTT. Access methods include RS485 serial port access via Modbus RTU protocol and Ethernet access via Modbus TCP or MQTT protocol. The middleware interfaces with the ship's AMS system to obtain or synchronize the operating data of various ship equipment and systems from the AMS system. During the data acquisition process, the middleware dynamically identifies the protocol type used and establishes the corresponding communication link according to the protocol characteristics: for Modbus RTU / TCP, it reads data frames from the holding register or input register by sending function codes; for MQTT, it subscribes to the corresponding topic to receive messages published by the device; it performs integrity verification, address matching and function code verification on the received raw data frames, filters invalid or erroneous data packets, and extracts valid device parameter fields. The data sources analyzed include the main unit, auxiliary unit, generator, cargo control system, and valve control system. Specific data sources include the AMS system, the main unit remote control system, the cargo control system, and the valve control system. The extracted valid data undergoes range conversion, unit unification, and physical quantity conversion, and data acquisition timestamps, equipment identifiers, and system source identifiers are added to form structured monitoring data records. The parsed and processed monitoring data is persistently stored in the database to support subsequent data queries and statistical analysis.

[0013] Further, in step S1, the parsing of the network communication system data includes: The data source is connected to the ship's network communication equipment via Ethernet access. The data source includes network devices such as routers, switches, and firewalls. The middleware establishes communication links with the above devices using TCP, SNMP, and Syslog protocols, respectively. Data analysis for signal strength and traffic consumption: Actively connect to the router's management port via TCP protocol and send query commands to obtain the router's 4G / 5G signal strength values; At the same time, periodically collect the router's traffic statistics via TCP protocol, and calculate 4G / 5G traffic consumption and satellite communication VAST traffic consumption based on signal strength. During the calculation process, the traffic estimate is dynamically corrected based on fluctuations in signal strength. Parsing network device status information: Send GetRequest or GetNextRequest requests to devices including switches, routers, and firewalls via the SNMP protocol to read device status nodes in the Management Information Base (MIB), including key status parameters such as device runtime, port status, CPU utilization, memory usage, and temperature. It also supports the SNMP Trap mechanism to receive abnormal alarms actively reported by devices. Parsing of log data: Receive syslog log data sent by devices including routers, switches, and firewalls via the Syslog protocol, parse the log format according to RFC 3164 or RFC 5424 standards, or use regular expressions set in the system to match the log format and extract key fields including log priority, timestamp, hostname, process ID, and message body. The signal strength data, traffic consumption data, device status data, and syslog log data collected and parsed via TCP, SNMP, and Syslog protocols are structured, and collection timestamps and device identifiers are added. The data is then persistently stored for subsequent querying and analysis.

[0014] Further, in step S1, the parsing of the video surveillance data includes: The middleware connects to the data source of the ship's video surveillance system via Ethernet access. The data source includes devices such as network video recorders (NVRs) and AI algorithm servers. The middleware establishes a connection with the above devices using SDK or API. Specifically, this includes calling the initialization interface in the software development kit (SDK) provided by the device manufacturer for login authentication, or constructing an HTTP request according to the RESTful API specification. The middleware provides an alarm data receiving interface via the HTTP protocol to receive ship video alarm data actively pushed by the AI ​​algorithm server. At the same time, for NVRs, the middleware actively sends alarm data query requests via the HTTP protocol, carrying necessary parameters including time range, alarm type or video channel, to obtain ship video alarm data. For SDKs / APIs that support active push, the middleware registers callback functions to receive alarm events in real time. The received video alarm data is parsed to extract unsafe behavior alarm information, including key fields such as alarm type, time of occurrence, location of occurrence, associated video channel number, alarm screenshot URL or video clip identifier; for alarm data output by the AI ​​algorithm server, the behavioral classification tags and confidence scores, including not wearing a life jacket, falling, and violation of regulations, are parsed. The parsed alarm data of unsafe behaviors is structured and organized, and a collection timestamp and data source identifier are added. The data is then persistently stored to support subsequent alarm record queries, statistical analysis, and alarm linkage.

[0015] Further, in step S2, the extracted business data is mapped and transformed according to a predefined unified ship data model to form structured data that conforms to the unified data model. This structured data is then serialized into standard JSON format, specifically: The data exchange middleware creates independent listening threads for the communication and navigation system, integrated monitoring and alarm system, network communication system, and video surveillance system. Each thread continuously listens for data pushes from the corresponding data source. Once any thread listens for a complete data packet, it performs protocol-level parsing on the data packet, identifies the source system type and specific data format based on the protocol identifier or feature field in the data packet header, and extracts the original business data fields. The extracted raw business data fields are mapped to a predefined unified ship data model. This model contains a set of standardized data field definitions, including common fields such as equipment identifier, data type, collection timestamp, value, unit, status code, alarm level, and location information. Based on the meaning of the fields from different source systems, a unified conversion of field names is performed to ensure that all field names conform to the naming conventions in the unified model. Standardize and convert data formats and units, including: unifying the time formats of different systems into a standard time format, unifying the units of different systems into a target unit system, and converting enumerated status values ​​into unified semantic labels; for alarm data, uniformly extract the alarm level field and map it into a standardized alarm level system. After completing field mapping and standardization transformation, a structured data object conforming to the unified data model for ships is formed. This object is a collection of key-value pairs. The structured data object is then converted into a standard JSON format string using a JSON serializer. During the serialization process, the accuracy of the data type is maintained, and nested objects and array structures are supported to express complex related data.

[0016] Furthermore, in step S3, based on the publish-subscribe architecture, the standard JSON format data is pushed in real time to the subscribing clients with established WebSocket connections via the WebSocket protocol, specifically as follows: The client actively establishes a WebSocket connection with the data exchange middleware. During the connection process, the client carries the variable identifier to be subscribed, the data type parameter to be received, and the user identifier. The subscribed variable is used to indicate the specific data item that the client is interested in. The data type is used to indicate the system category to which the data that the client wants to receive belongs. The user identifier is used to distinguish between different clients or different users so that the middleware can perform session management and access control. After receiving a WebSocket connection request from a client, the middleware parses the subscription information and user identifier in the connection parameters, creates an independent subscription session for each client, and registers the session to the publish-subscribe architecture. Based on the variables, data types, and user identifiers subscribed to by the client, it establishes a dynamic routing mapping from the data source to the client, while also supporting data isolation and personalized push strategies based on user identifiers. Meanwhile, the middleware maintains an internal push scheduling mechanism, which is divided into two modes: real-time data push and historical data push. For real-time data, the middleware pushes the latest data to the client immediately after receiving it. For historical data, the middleware extracts data that matches the subscription conditions from the data stream after protocol parsing and data standardization transformation according to the push cycle set by the client or the system's default push interval. The middleware continuously monitors the WebSocket connection status of registered clients. For clients with normal connections, it actively pushes matching data to the client in standard JSON format according to the set period. During the push process, if a certain variable subscribed to by the client has no new data within a specific period, it decides whether to push a heartbeat packet containing an empty value or the last valid value according to the configuration in order to maintain connection activity. The client continuously listens to the WebSocket communication channel, receives data pushed by the middleware, and processes or displays the received data locally. During the subscription period, the client can dynamically adjust the subscribed variables or data types, or change the user identifier as needed, and realize the subscription change by resending the subscription parameters or creating a new WebSocket connection. When a client actively disconnects or the connection is abnormally interrupted, the middleware automatically cleans up the corresponding subscription session based on the user identifier and session information, releases related resources, and stops pushing data to that client.

[0017] A ship heterogeneous information output system based on data exchange middleware for executing the ship heterogeneous information output method based on data exchange middleware as described above includes: The protocol adaptation layer uses multiple independent threads to listen to data packets from the ship's communication and navigation system, integrated monitoring and alarm system, network communication system, and video surveillance system. It dynamically identifies and loads the corresponding parser based on the protocol used by the data packet to extract business data from the raw data. The types of data packets listened to include: communication and navigation system data, integrated monitoring and alarm system data, network communication system data, and video surveillance data. The data conversion layer maps and transforms the extracted business data according to a predefined unified ship data model, forming structured data that conforms to this unified data model. This structured data is then serialized into standard JSON format. The service middleware layer, based on a publish-subscribe architecture, pushes the standard JSON format data in real-time to subscribed clients with established WebSocket connections via the WebSocket protocol. When establishing a WebSocket connection, the client carries the variables to be subscribed and the type of data to be received. The data exchange middleware continuously pushes data according to a set period.

[0018] A computer device includes a memory and one or more processors, the memory storing computer code that, when executed by the one or more processors, causes the one or more processors to perform the method described above.

[0019] A computer-readable storage medium storing computer code that, when executed, performs the method described above.

[0020] Compared with the prior art, the beneficial effects of the present invention are: The data exchange middleware based on heterogeneous ship systems provided by this invention can provide all the data required by the application layer using a unified protocol and data structure. When a new data layer needs to be added, no application layer code needs to be modified; only the middleware needs to be extended to achieve integration. Through this approach, this invention achieves complete decoupling between the application layer and the data layer, significantly reducing the complexity of system integration and maintenance costs. Attached Figure Description

[0021] Figure 1 This is an overall flowchart of the ship heterogeneous information output method based on data exchange middleware of the present invention; Figure 2 This is a diagram showing the overall structure of the ship heterogeneous information output system based on data exchange middleware according to the present invention. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this specification means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0024] The key points of this invention are as follows: (1) Multi-protocol dynamic adaptation and resolution mechanism for ship heterogeneous systems This invention's middleware incorporates multiple protocol parsers for different ship systems, specifically including the ability to parse various communication protocols used by communication and navigation systems, integrated monitoring and alarm systems, network communication systems, and video surveillance systems. The middleware can dynamically identify the protocol type used by data from different systems and automatically load the corresponding parser for targeted data parsing, thereby achieving unified access to data from various heterogeneous ship systems.

[0025] (2) Standardized transformation method based on unified data model After parsing the original data according to the protocol, the middleware maps, converts, and unifies the data according to a predefined unified ship data model, regardless of the protocol or physical format, ultimately converting it into a standard JSON data structure. This standardized conversion method eliminates the need for the application layer to worry about differences in the underlying data format when consuming data, achieving a unified abstraction of data formats.

[0026] (3) Decoupling design and scalability of application layer and data layer By leveraging the isolation provided by middleware between data providers and data consumers, this invention achieves complete decoupling between the two. Specifically, the application layer code is independent of the underlying data source, eliminating the need for application developers to write adaptation logic for different data sources. When adding or changing existing data sources, only extended configurations on the middleware side are required (e.g., adding a new protocol parser or updating data model mapping rules), without modifying any application layer code. This design significantly reduces system maintenance costs and scalability, enhancing the flexibility and scalability of the ship information system.

[0027] The following is an illustration through specific examples: First Embodiment like Figure 1 As shown, this embodiment provides a method for outputting heterogeneous ship information based on a data exchange middleware, including the following steps: S1: Multiple independent threads monitor data packets from the ship's communication and navigation system, integrated monitoring and alarm system, network communication system, and video surveillance system. Based on the protocol used by the data packets, the corresponding parser is dynamically identified and loaded for parsing. Business data is extracted from the raw data. The types of data packets monitored include: communication and navigation system data, integrated monitoring and alarm system data, network communication system data, and video surveillance data.

[0028] (1) The parsing of the communication and navigation system data includes: The information of the ship's communication and navigation equipment is collected in real time via the NMEA / IEC61162-450 protocol. The communication and navigation equipment includes devices such as autopilot, wind direction and speed meter, depth sounder, GPS, log, electronic compass and AIS. The access methods include access via RS485 serial port with NMEA protocol and access via Ethernet with IEC61162-450 protocol. During the data acquisition process, the middleware dynamically identifies the protocol type of the data frame, performs start flag verification, checksum verification and integrity check on each data frame, filters abnormal or incomplete data packets, and extracts valid communication data fields. The extracted valid data is given a unified collection timestamp and source device identifier to form a structured communication data record. The data is then classified and stored according to device type and data category. At the same time, the parsed data is persisted to the historical database to support subsequent queries and traceability. It provides a standardized historical data query interface, supports combined searches based on conditions such as device name, time range, and data type, and allows batch export of query results.

[0029] (2) The parsing of the data from the integrated monitoring and alarm system includes: Data from ship engine room equipment is collected via protocols including Modbus TCP / RTU or MQTT. Access methods include RS485 serial port access via Modbus RTU protocol and Ethernet access via Modbus TCP or MQTT protocol. The middleware interfaces with the ship's AMS system to obtain or synchronize the operating data of various ship equipment and systems from the AMS system. During the data acquisition process, the middleware dynamically identifies the protocol type used and establishes the corresponding communication link according to the protocol characteristics: for Modbus RTU / TCP, it reads data frames from the holding register or input register by sending function codes; for MQTT, it subscribes to the corresponding topic to receive messages published by the device; it performs integrity verification, address matching and function code verification on the received raw data frames, filters invalid or erroneous data packets, and extracts valid device parameter fields. The data sources analyzed include the main unit, auxiliary unit, generator, cargo control system, and valve control system. Specific data sources include the AMS system, the main unit remote control system, the cargo control system, and the valve control system. The extracted valid data undergoes range conversion, unit unification, and physical quantity conversion, and data acquisition timestamps, equipment identifiers, and system source identifiers are added to form structured monitoring data records. The parsed and processed monitoring data is persistently stored in the database to support subsequent data queries and statistical analysis.

[0030] (3) The parsing of the network communication system data includes: The data source is connected to the ship's network communication equipment via Ethernet access. The data source includes network devices such as routers, switches, and firewalls. The middleware establishes communication links with the above devices using TCP, SNMP, and Syslog protocols, respectively. Data analysis for signal strength and traffic consumption: Actively connect to the router's management port via TCP protocol and send query commands to obtain the router's 4G / 5G signal strength values; At the same time, periodically collect the router's traffic statistics via TCP protocol, and calculate 4G / 5G traffic consumption and satellite communication VAST traffic consumption based on signal strength. During the calculation process, the traffic estimate is dynamically corrected based on fluctuations in signal strength. Parsing network device status information: Send GetRequest or GetNextRequest requests to devices including switches, routers, and firewalls via the SNMP protocol to read device status nodes in the Management Information Base (MIB), including key status parameters such as device runtime, port status, CPU utilization, memory usage, and temperature. It also supports the SNMP Trap mechanism to receive abnormal alarms actively reported by devices. Parsing of log data: Receive syslog log data sent by devices including routers, switches, and firewalls via the Syslog protocol, parse the log format according to RFC 3164 or RFC 5424 standards, or use regular expressions set in the system to match the log format and extract key fields including log priority, timestamp, hostname, process ID, and message body. The signal strength data, traffic consumption data, device status data, and syslog log data collected and parsed via TCP, SNMP, and Syslog protocols are structured, and collection timestamps and device identifiers are added. The data is then persistently stored for subsequent querying and analysis.

[0031] (4) The parsing of the video surveillance data includes: The middleware connects to the data source of the ship's video surveillance system via Ethernet access. The data source includes devices such as network video recorders (NVRs) and AI algorithm servers. The middleware establishes a connection with the above devices using SDK or API. Specifically, this includes calling the initialization interface in the software development kit (SDK) provided by the device manufacturer for login authentication, or constructing an HTTP request according to the RESTful API specification. The middleware provides an alarm data receiving interface via the HTTP protocol to receive ship video alarm data actively pushed by the AI ​​algorithm server. At the same time, for NVRs, the middleware actively sends alarm data query requests via the HTTP protocol, carrying necessary parameters including time range, alarm type or video channel, to obtain ship video alarm data. For SDKs / APIs that support active push, the middleware registers callback functions to receive alarm events in real time. The received video alarm data is parsed to extract unsafe behavior alarm information, including key fields such as alarm type, time of occurrence, location of occurrence, associated video channel number, alarm screenshot URL or video clip identifier; for alarm data output by the AI ​​algorithm server, the behavioral classification tags and confidence scores, including not wearing a life jacket, falling, and violation of regulations, are parsed. The parsed alarm data of unsafe behaviors is structured and organized, and a collection timestamp and data source identifier are added. The data is then persistently stored to support subsequent alarm record queries, statistical analysis, and alarm linkage.

[0032] In step S1, this invention establishes independent listening threads for each type of ship information system (communication and navigation, integrated monitoring and alarm, network communication, and video surveillance), achieving parallel acquisition of multi-source heterogeneous data without interference. Each thread follows a unified processing pipeline: "protocol identification → link establishment / command interaction → data frame verification → valid field extraction → structure enhancement (timestamp, identifier, unit conversion) → persistent storage and query support." The differences lie only in the adaptation details for specific protocols: for example, using function code to read registers for Modbus, topic subscription for MQTT, MIB node reading and Trap listening for SNMP, and HTTP polling or callback registration for video SDKs / APIs. This layered, modular parsing architecture allows the middleware to flexibly expand support for new protocols or device types without modifying the overall process framework. Ultimately, all raw data is transformed into historical records with unified semantic tags and storage structures, and access is provided externally through standardized query interfaces, laying a high-quality data foundation for subsequent unified data transformation and publish / subscribe. S2: The extracted business data is mapped and transformed according to the predefined unified ship data model to form structured data that conforms to the unified data model, and then the structured data is serialized into standard JSON format.

[0033] In this embodiment, step S2 specifically includes: The data exchange middleware creates independent listening threads for the communication and navigation system, integrated monitoring and alarm system, network communication system, and video surveillance system. Each thread continuously listens for data pushes from the corresponding data source. Once any thread listens for a complete data packet, it performs protocol-level parsing on the data packet, identifies the source system type and specific data format based on the protocol identifier or feature field in the data packet header, and extracts the original business data fields. The extracted raw business data fields are mapped to a predefined unified ship data model. This model contains a set of standardized data field definitions, including common fields such as equipment identifier, data type, collection timestamp, value, unit, status code, alarm level, and location information. Based on the meaning of the fields from different source systems, a unified conversion of field names is performed to ensure that all field names conform to the naming conventions in the unified model. Standardize and convert data formats and units, including: unifying the time formats of different systems into a standard time format, unifying the units of different systems into a target unit system, and converting enumerated status values ​​into unified semantic labels; for alarm data, uniformly extract the alarm level field and map it into a standardized alarm level system. After completing field mapping and standardization transformation, a structured data object conforming to the unified data model for ships is formed. This object is a collection of key-value pairs. The structured data object is then converted into a standard JSON format string using a JSON serializer. During the serialization process, the accuracy of the data type is maintained, and nested objects and array structures are supported to express complex related data.

[0034] Based on the technical solution described in step S2 above, the core design idea of ​​this invention in the data standardization and transformation stage can be further understood: through a predefined unified ship data model, raw business data from different protocols, formats, and units are abstracted into a common key-value pair structure, thereby completely shielding the underlying heterogeneity. Specifically, after completing protocol-level parsing, the middleware does not directly expose the raw fields to the application layer, but undergoes a three-step transformation process: "field name mapping → time / unit / enumeration standardization → alarm level unification," ensuring that all data has consistent semantic and type characteristics before entering the publish / subscribe stage. This model-driven transformation method not only ensures data integrity (by supporting nested objects and arrays) but also provides deterministic output for subsequent JSON serialization, allowing the application layer to parse JSON according to the unified model without needing to care whether the data comes from GPS, Modbus, or an HTTP interface. This design is the key intermediate link in this invention to achieve "decoupling between the application layer and the data layer." S3: Based on a publish-subscribe architecture, standard JSON format data is pushed in real time to subscribing clients with established WebSocket connections via the WebSocket protocol. When establishing a WebSocket connection, the client carries the variables to be subscribed and the type of data to be received. The data exchange middleware continuously pushes data according to a set period.

[0035] In this embodiment, step S3 specifically includes: The client actively establishes a WebSocket connection with the data exchange middleware. During the connection process, the client carries the variable identifier to be subscribed, the data type parameter to be received, and the user identifier. The subscribed variable is used to indicate the specific data item that the client is interested in. The data type is used to indicate the system category to which the data that the client wants to receive belongs. The user identifier is used to distinguish between different clients or different users so that the middleware can perform session management and access control. After receiving a WebSocket connection request from a client, the middleware parses the subscription information and user identifier in the connection parameters, creates an independent subscription session for each client, and registers the session to the publish-subscribe architecture. Based on the variables, data types, and user identifiers subscribed to by the client, it establishes a dynamic routing mapping from the data source to the client, while also supporting data isolation and personalized push strategies based on user identifiers. Meanwhile, the middleware maintains an internal push scheduling mechanism, which is divided into two modes: real-time data push and historical data push. For real-time data, the middleware pushes the latest data to the client immediately after receiving it. For historical data, the middleware extracts data that matches the subscription conditions from the data stream after protocol parsing and data standardization transformation according to the push cycle set by the client or the system's default push interval. The middleware continuously monitors the WebSocket connection status of registered clients. For clients with normal connections, it actively pushes matching data to the client in standard JSON format according to the set period. During the push process, if a certain variable subscribed to by the client has no new data within a specific period, it decides whether to push a heartbeat packet containing an empty value or the last valid value according to the configuration in order to maintain connection activity. The client continuously listens to the WebSocket communication channel, receives data pushed by the middleware, and processes or displays the received data locally. During the subscription period, the client can dynamically adjust the subscribed variables or data types, or change the user identifier as needed, and realize the subscription change by resending the subscription parameters or creating a new WebSocket connection. When a client actively disconnects or the connection is abnormally interrupted, the middleware automatically cleans up the corresponding subscription session based on the user identifier and session information, releases related resources, and stops pushing data to that client.

[0036] Based on the technical solution described in step S3 above, the core design of this invention at the data distribution and subscription level can be further understood: by introducing a publish-subscribe architecture and relying on WebSocket full-duplex communication, the middleware delivers standardized JSON data to the upper-layer application in an "on-demand, real-time, and manageable" manner. Specifically, the client establishes a connection by carrying subscription variables, data types, and user identifiers, enabling the middleware to build precise dynamic routing mappings for each session. This achieves accurate data push by topic and supports multi-tenant isolation and personalized strategies through user identifiers. The periodic scheduling mechanism and heartbeat packet maintenance strategy effectively solve the problems of network jitter and data gaps in the ship environment, avoiding the overhead of repeated reconstruction after unexpected connection interruptions. At the same time, the client can dynamically change the subscription content, and the middleware automatically completes session updates and resource cleanup, all transparent to the application layer. This design allows the data consumer to focus only on the JSON stream in the WebSocket channel without worrying about underlying protocol parsing, data conversion, or push frequency control, truly achieving decoupling between the application layer and the data layer, and significantly reducing the development and maintenance complexity in multi-system integration scenarios.

[0037] Second Embodiment like Figure 2 As shown, this embodiment provides a ship heterogeneous information output system based on data exchange middleware for executing the ship heterogeneous information output method based on data exchange middleware as described in the first embodiment, comprising: The protocol adaptation layer uses multiple independent threads to listen to data packets from the ship's communication and navigation system, integrated monitoring and alarm system, network communication system, and video surveillance system. It dynamically identifies and loads the corresponding parser based on the protocol used by the data packet to extract business data from the raw data. The types of data packets listened to include: communication and navigation system data, integrated monitoring and alarm system data, network communication system data, and video surveillance data. The data conversion layer maps and transforms the extracted business data according to a predefined unified ship data model, forming structured data that conforms to this unified data model. This structured data is then serialized into standard JSON format. The service middleware layer, based on a publish-subscribe architecture, pushes the standard JSON format data in real-time to subscribed clients with established WebSocket connections via the WebSocket protocol. When establishing a WebSocket connection, the client carries the variables to be subscribed and the type of data to be received. The data exchange middleware continuously pushes data according to a set period.

[0038] A computer-readable storage medium stores computer code that, when executed, performs the methods described above. Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. This program can be stored in a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0039] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

[0040] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0041] It should be noted that the above embodiments can be freely combined as needed. The above description is only a preferred embodiment of the present invention. It should be pointed out that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for outputting heterogeneous ship information based on data exchange middleware, characterized in that, Includes the following steps: S1: Multiple independent threads monitor data packets from the ship's communication and navigation system, integrated monitoring and alarm system, network communication system, and video surveillance system. Based on the protocol used by the data packets, the corresponding parser is dynamically identified and loaded for parsing. Business data is extracted from the raw data. The types of data packets monitored include: communication and navigation system data, integrated monitoring and alarm system data, network communication system data, and video surveillance data. S2: The extracted business data is mapped and transformed according to the predefined unified data model for ships to form structured data that conforms to the unified data model. The structured data is then serialized into standard JSON format. S3: Based on a publish-subscribe architecture, standard JSON format data is pushed in real time to subscribing clients with established WebSocket connections via the WebSocket protocol. When establishing a WebSocket connection, the client carries the variables to be subscribed and the type of data to be received. The data exchange middleware continuously pushes data according to a set period.

2. The method for outputting heterogeneous ship information based on data exchange middleware according to claim 1, characterized in that, In step S1, the parsing of the communication navigation system data includes: The information of the ship's communication and navigation equipment is collected in real time via the NMEA / IEC61162-450 protocol. The communication and navigation equipment includes devices such as autopilot, wind direction and speed meter, depth sounder, GPS, log, electronic compass and AIS. The access methods include access via RS485 serial port with NMEA protocol and access via Ethernet with IEC61162-450 protocol. During the data acquisition process, the middleware dynamically identifies the protocol type of the data frame, performs start flag verification, checksum verification and integrity check on each data frame, filters abnormal or incomplete data packets, and extracts valid communication data fields. The extracted valid data is given a unified collection timestamp and source device identifier to form a structured communication data record. The data is then classified and stored according to device type and data category. At the same time, the parsed data is persisted to the historical database to support subsequent queries and traceability. It provides a standardized historical data query interface, supports combined searches based on conditions such as device name, time range, and data type, and allows batch export of query results.

3. The method for outputting heterogeneous ship information based on data exchange middleware according to claim 1, characterized in that, In step S1, the parsing of the integrated monitoring and alarm system data includes: Data from ship engine room equipment is collected via protocols including Modbus TCP / RTU or MQTT. Access methods include RS485 serial port access via Modbus RTU protocol and Ethernet access via Modbus TCP or MQTT protocol. The middleware interfaces with the ship's AMS system to obtain or synchronize the operating data of various ship equipment and systems from the AMS system. During the data acquisition process, the middleware dynamically identifies the protocol type used and establishes the corresponding communication link according to the protocol characteristics: for Modbus RTU / TCP, it reads data frames from the holding register or input register by sending function codes; for MQTT, it subscribes to the corresponding topic to receive messages published by the device; it performs integrity verification, address matching and function code verification on the received raw data frames, filters invalid or erroneous data packets, and extracts valid device parameter fields. The data sources analyzed include the main unit, auxiliary unit, generator, cargo control system, and valve control system. Specific data sources include the AMS system, the main unit remote control system, the cargo control system, and the valve control system. The extracted valid data undergoes range conversion, unit unification, and physical quantity conversion, and data acquisition timestamps, equipment identifiers, and system source identifiers are added to form structured monitoring data records. The parsed and processed monitoring data is persistently stored in the database to support subsequent data queries and statistical analysis.

4. The method for outputting heterogeneous ship information based on data exchange middleware according to claim 1, characterized in that, In step S1, the parsing of the network communication system data includes: The data source is connected to the ship's network communication equipment via Ethernet access. The data source includes network devices such as routers, switches, and firewalls. The middleware establishes communication links with the above devices using TCP, SNMP, and Syslog protocols, respectively. Data analysis for signal strength and traffic consumption: Actively connect to the router's management port via TCP protocol and send query commands to obtain the router's 4G / 5G signal strength values; At the same time, periodically collect the router's traffic statistics via TCP protocol, and calculate 4G / 5G traffic consumption and satellite communication VAST traffic consumption based on signal strength. During the calculation process, the traffic estimate is dynamically corrected based on fluctuations in signal strength. Parsing network device status information: Send GetRequest or GetNextRequest requests to devices including switches, routers, and firewalls via the SNMP protocol to read device status nodes in the Management Information Base (MIB), including key status parameters such as device runtime, port status, CPU utilization, memory usage, and temperature. It also supports the SNMPTrap mechanism to receive abnormal alarms actively reported by devices. Parsing of log data: Receive syslog log data sent by devices including routers, switches, and firewalls via the Syslog protocol, parse the log format according to RFC 3164 or RFC 5424 standards, or use regular expressions set in the system to match the log format and extract key fields including log priority, timestamp, hostname, process ID, and message body. The signal strength data, traffic consumption data, device status data, and syslog log data collected and parsed via TCP, SNMP, and Syslog protocols are structured, and collection timestamps and device identifiers are added. The data is then persistently stored for subsequent querying and analysis.

5. The method for outputting heterogeneous ship information based on data exchange middleware according to claim 1, characterized in that, In step S1, the parsing of the video surveillance data includes: The middleware connects to the data source of the ship's video surveillance system via Ethernet access. The data source includes devices such as network video recorders (NVRs) and AI algorithm servers. The middleware establishes a connection with the above devices using SDK or API. Specifically, this includes calling the initialization interface in the software development kit (SDK) provided by the device manufacturer for login authentication, or constructing an HTTP request according to the RESTful API specification. The middleware provides an alarm data receiving interface via the HTTP protocol to receive ship video alarm data actively pushed by the AI ​​algorithm server. At the same time, for NVRs, the middleware actively sends alarm data query requests via the HTTP protocol, carrying necessary parameters including time range, alarm type or video channel, to obtain ship video alarm data. For SDKs / APIs that support active push, the middleware registers callback functions to receive alarm events in real time. The received video alarm data is parsed to extract unsafe behavior alarm information, including key fields such as alarm type, time of occurrence, location of occurrence, associated video channel number, alarm screenshot URL or video clip identifier; for alarm data output by the AI ​​algorithm server, the behavioral classification tags and confidence scores, including not wearing a life jacket, falling, and violation of regulations, are parsed. The parsed alarm data of unsafe behaviors is structured and organized, and a collection timestamp and data source identifier are added. The data is then persistently stored to support subsequent alarm record queries, statistical analysis, and alarm linkage.

6. The method for outputting heterogeneous ship information based on data exchange middleware according to claim 1, characterized in that, In step S2, the extracted business data is mapped and transformed according to a predefined unified ship data model to form structured data that conforms to the unified data model. This structured data is then serialized into standard JSON format, specifically: The data exchange middleware creates independent listening threads for the communication and navigation system, integrated monitoring and alarm system, network communication system, and video surveillance system. Each thread continuously listens for data pushes from the corresponding data source. Once any thread listens for a complete data packet, it performs protocol-level parsing on the data packet, identifies the source system type and specific data format based on the protocol identifier or feature field in the data packet header, and extracts the original business data fields. The extracted raw business data fields are mapped to a predefined unified ship data model. This model contains a set of standardized data field definitions, including common fields such as equipment identifier, data type, collection timestamp, value, unit, status code, alarm level, and location information. Based on the meaning of the fields from different source systems, a unified conversion of field names is performed to ensure that all field names conform to the naming conventions in the unified model. Standardize and convert data formats and units, including: unifying the time formats of different systems into a standard time format, unifying the units of different systems into a target unit system, and converting enumerated status values ​​into unified semantic labels; for alarm data, uniformly extract the alarm level field and map it into a standardized alarm level system. After completing field mapping and standardization transformation, a structured data object conforming to the unified data model for ships is formed. This object is a collection of key-value pairs. The structured data object is then converted into a standard JSON format string using a JSON serializer. During the serialization process, the accuracy of the data type is maintained, and nested objects and array structures are supported to express complex related data.

7. The method for outputting heterogeneous ship information based on data exchange middleware according to claim 1, characterized in that, In step S3, based on the publish-subscribe architecture, the standard JSON format data is pushed in real time to the subscribing clients with established WebSocket connections via the WebSocket protocol, specifically as follows: The client actively establishes a WebSocket connection with the data exchange middleware. During the connection process, the client carries the variable identifier to be subscribed, the data type parameter to be received, and the user identifier. The subscribed variable is used to indicate the specific data item that the client is interested in. The data type is used to indicate the system category to which the data that the client wants to receive belongs. The user identifier is used to distinguish between different clients or different users so that the middleware can perform session management and access control. After receiving a WebSocket connection request from a client, the middleware parses the subscription information and user identifier in the connection parameters, creates an independent subscription session for each client, and registers the session to the publish-subscribe architecture. Based on the variables, data types, and user identifiers subscribed to by the client, it establishes a dynamic routing mapping from the data source to the client, while also supporting data isolation and personalized push strategies based on user identifiers. Meanwhile, the middleware maintains an internal push scheduling mechanism, which is divided into two modes: real-time data push and historical data push. For real-time data, the middleware pushes the latest data to the client immediately after receiving it. For historical data, the middleware extracts data that matches the subscription conditions from the data stream after protocol parsing and data standardization transformation according to the push cycle set by the client or the system's default push interval. The middleware continuously monitors the WebSocket connection status of registered clients. For clients with normal connections, it actively pushes the matching data to the client in standard JSON format according to the set period. During the push process, if a certain variable subscribed to by the client has no new data within a specific period, the system will decide whether to push a heartbeat packet containing an empty value or the last valid value, depending on the configuration, in order to maintain connection activity. The client continuously listens to the WebSocket communication channel, receives data pushed by the middleware, and processes or displays the received data locally. During the subscription period, the client can dynamically adjust the subscribed variables or data types, or change the user identifier as needed, and realize the subscription change by resending the subscription parameters or creating a new WebSocket connection. When a client actively disconnects or the connection is abnormally interrupted, the middleware automatically cleans up the corresponding subscription session based on the user identifier and session information, releases related resources, and stops pushing data to that client.

8. A ship heterogeneous information output system based on data exchange middleware for executing the ship heterogeneous information output method based on data exchange middleware as described in any one of claims 1-7, characterized in that, include: The protocol adaptation layer is used to listen to data packets from the ship's communication and navigation system, integrated monitoring and alarm system, network communication system, and video surveillance system through multiple independent threads. It dynamically identifies and loads the corresponding parser according to the protocol used by the data packet to parse it and extract business data from the raw data. The types of data packets listened to include: communication and navigation system data, integrated monitoring and alarm system data, network communication system data, and video surveillance data. The data transformation layer is used to map and transform the extracted business data according to a predefined unified ship data model, forming structured data that conforms to the unified data model, and then serializing the structured data into standard JSON format. The service middleware layer is used to push the standard JSON format data to the subscribed clients with established WebSocket connections in real time based on a publish-subscribe architecture and via the WebSocket protocol. When establishing a WebSocket connection, the client carries the variables to be subscribed and the type of data to be received. The data exchange middleware continuously pushes data according to a set period.

9. A computer device, characterized in that, The device includes a memory and one or more processors, wherein the memory stores computer code that, when executed by the one or more processors, causes the one or more processors to perform the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer code, and when the computer code is executed, the method as described in any one of claims 1 to 7 is performed.

Images