A data transmission method and system for ship fuel supply information

Abstract

A method and system for transmitting ship fuel supply information is disclosed. In this method, the sending end divides real-time data into critical monitoring data and routine business data. The critical data is placed at the beginning of the data packet payload, and its length and independent checksum are written into the packet header before transmission. The shore-based server monitors bandwidth in real time while receiving the byte stream. If the network bandwidth is lower than a preset threshold, based on the cumulative length of received bytes, when the packet header and critical data have just been received, while continuing to receive the remaining routine data, the critical data segment is preferentially extracted from the buffer, deserialized, and output immediately after passing independent checksum verification. This application aims to reduce the transmission delay of critical data and improve the timeliness of ship fuel supply information data transmission.

Description

Technical Field

[0001] This application belongs to the field of data processing, and in particular relates to a method for transmitting ship fuel supply information. Background Technology

[0002] With the digital transformation of the shipping industry, data interaction in the ship fuel supply process is becoming increasingly frequent. In traditional ship fuel supply information transmission, basic point-to-point direct communication or manual offline data entry is usually used for data interaction. This method has the drawbacks of low data transmission efficiency and poor data synchronization among multiple terminals when faced with massive and multi-dimensional fuel supply data.

[0003] To address the aforementioned shortcomings, the relevant technology employs a centralized data transmission architecture based on ship-shore collaboration. This technology deploys energy efficiency acquisition and data transmission units on the ship, utilizing wireless communication networks to uniformly encapsulate multi-dimensional data collected by sensors such as ship fuel flow and shaft power, and transmits it in real-time to a shore-based server for centralized parsing, distribution, and storage. This approach, through standardized data aggregation and centralized scheduling of ship-shore collaboration, improves the transmission efficiency of fuel supply and energy consumption data and enhances data synchronization between business nodes on both ship and shore ends.

[0004] However, the bandwidth of maritime wireless network environments is often dynamically fluctuating. The aforementioned technologies typically encapsulate multi-dimensional data into complete data packets for real-time transmission. When network bandwidth decreases, these data packets containing massive amounts of information take a long time to transmit over the network channel. Since all types of data in the fuel supply process rely on this complete data packet for overall interaction, the extended transmission period increases the time it takes for the entire data packet to reach the shore-based server. This delays the reception and parsing of time-sensitive critical monitoring data (such as the real-time pressure of the fueling pipeline), further increasing the transmission latency of critical data and reducing the timeliness of ship fuel supply information data transmission. Summary of the Invention

[0005] This application provides a method and system for transmitting ship fuel supply information, which reduces the transmission delay of critical data and improves the timeliness of ship fuel supply information transmission.

[0006] Firstly, this application provides a method for transmitting ship fuel supply information, which divides multi-dimensional real-time data in the ship fuel supply process into key monitoring data and routine business data;

[0007] Serialize the critical monitoring data to the beginning of the data payload area of ​​the data packet to be sent, and serialize the regular business data after the critical monitoring data;

[0008] Write the byte length identifier and independent checksum for critical monitoring data into the header area of ​​the data packet to be sent;

[0009] The data packets to be sent are transmitted to the shore-based server in the form of a byte stream via the maritime wireless network;

[0010] During the process of receiving byte streams, the shore-based server obtains the transmission bandwidth of the current network environment in real time;

[0011] If the transmission bandwidth is determined to be lower than the preset bandwidth threshold, the cumulative length of the received bytes is determined in the receiving buffer of the shore server.

[0012] When the cumulative length reaches the sum of the fixed length of the header region and the byte length identifier, while continuously receiving the remaining byte stream, extract the byte segment located after the header region from the receive buffer whose length corresponds to the byte length identifier.

[0013] Byte segments are validated based on independent checksums;

[0014] After the verification is confirmed to be successful, the byte fragments are deserialized into key monitoring data output.

[0015] By adopting the above technical solution, multi-dimensional real-time data during the ship's fuel supply process is divided into critical monitoring data and routine business data. The critical monitoring data is serialized to the beginning of the payload area of ​​the data packet to be sent. Simultaneously, a byte length identifier and an independent checksum for the critical monitoring data are written into the header area. This provides a structural basis for priority parsing when the data is transmitted via the maritime wireless network. When the shore-based server detects that the current network bandwidth is below a preset threshold, it can accurately extract the corresponding byte segments of the critical monitoring data from the receive buffer in advance based on the header identifier while continuously receiving the remaining byte stream. It then performs independent verification and deserialization, allowing the critical data to be parsed preferentially without waiting for the entire data packet containing routine business data to be received. This reduces the transmission and processing latency of critical monitoring data in the weak network environment at sea and improves the timeliness of ship fuel supply information data transmission.

[0016] In conjunction with some implementation methods of the first aspect, in some implementation methods, the multi-dimensional real-time data of the ship fuel supply process is divided into key monitoring data and routine business data, specifically including:

[0017] Extract device status identifier sequences from multi-dimensional real-time data;

[0018] Based on the equipment status identifier sequence, the current operational stage of the ship's fuel supply process is determined. The operational stage characterizes the physical process of the ship's fuel supply process and includes the pipeline precooling stage, the initial refueling stage, and the pressure stabilization supply stage.

[0019] Obtain the set of core monitoring dimensions that uniquely correspond to the work phase from the pre-defined phase mapping knowledge base;

[0020] Data items belonging to the core monitoring dimension set in the multi-dimensional real-time data are identified as key monitoring data.

[0021] The remaining data items in the multi-dimensional real-time data, excluding key monitoring data, are identified as regular business data.

[0022] By employing the aforementioned technical solution, the specific operational stage of the current ship fuel supply is determined by extracting equipment status identifier sequences from multi-dimensional real-time data. A set of core monitoring dimensions uniquely corresponding to this physical process is then obtained from a pre-defined stage mapping knowledge base, and the corresponding data items are identified as key monitoring data. Since the physical states and core monitoring requirements faced by ship fuel supply differ significantly at different stages such as pipeline precooling, initial refueling, and pressure stabilization, this method of dynamically adjusting the scope of key data based on the current operational stage enables the system to accurately identify the most critical monitoring indicators at specific moments. This avoids the omission or redundant transmission of key data that might occur when using static classification standards, thereby improving the accuracy and relevance of key monitoring data classification and further enhancing the utilization efficiency of limited network bandwidth resources at different operational stages.

[0023] In conjunction with some implementation methods of the first aspect, in some implementation methods, the multi-dimensional real-time data of the ship fuel supply process is divided into key monitoring data and routine business data, specifically including:

[0024] Obtain a preset basic key data whitelist, and classify the data in the multi-dimensional real-time data that are in the preset basic key data whitelist as initial key data, and classify the data that are not in the preset basic key data whitelist as initial regular data;

[0025] Construct a sliding time window corresponding to the initial normal data, and calculate the real-time rate of change of the initial normal data within the sliding time window;

[0026] Extract fluid pressure and fluid temperature values ​​from the initial key data, and calculate the physical fluctuation baseline of the current pipeline based on the current values ​​of fluid pressure and fluid temperature;

[0027] If the real-time rate of change in the initial routine data exceeds the physical fluctuation benchmark, the corresponding initial routine data is transformed to obtain the key data.

[0028] The initial critical data and the critical data that has been upgraded to a higher level are merged into critical monitoring data, and the remaining initial regular data after the upgrade is used as regular business data.

[0029] By adopting the above technical solution, based on the initial data division using a preset whitelist, a sliding time window is constructed for the initial routine data, and its real-time rate of change within the window is calculated. Simultaneously, fluid pressure and temperature values ​​from the initial key data are extracted to dynamically calculate the physical fluctuation benchmark of the current pipeline. When the real-time rate of change of the initial routine data exceeds this physical fluctuation benchmark, it is upgraded to key data and merged for transmission. By closely integrating the dynamic trend of routine data with the actual physical state of the current pipeline, routine data that was originally of low priority can be promptly identified and automatically upgraded in transmission priority when abnormal and drastic fluctuations occur. This enhances the dynamic adaptability of the data transmission strategy to sudden abnormal operating conditions and improves the system's response speed to potential equipment anomalies or safety hazards.

[0030] In conjunction with some implementations of the first aspect, in some implementations, after confirming that the verification has passed and deserializing the byte fragments into key monitoring data for output, the method further includes:

[0031] Monitor the receive buffer of the shore-based server until the remaining byte stream corresponding to the data packet to be sent is received, and obtain the complete byte stream of the data packet to be sent;

[0032] The regular data offset cursor in the complete byte stream is determined based on the sum of the fixed length of the header region and the byte length identifier;

[0033] Starting from a regular data offset cursor, extract the tail byte fragment from the complete byte stream and deserialize the tail byte fragment into regular business data;

[0034] Extract the first generation timestamp of regular business data and obtain the second generation timestamp of the latest key monitoring data output from the current shore-based server;

[0035] If the first generation timestamp matches the second generation timestamp, the routine business data and the key monitoring data corresponding to the first generation timestamp are concatenated at the object level to generate a complete ship fuel supply record for storage.

[0036] By adopting the above technical solution, after completing the pre-verification and output of key monitoring data, the complete byte stream is obtained by continuously monitoring the receiving buffer. The offset cursor for regular data is determined based on the length identifier of the header region, thereby accurately extracting and deserializing regular business data. The first generation timestamp of the regular business data is extracted and compared with the second generation timestamp of the latest output key monitoring data in the shore-based server. If the timestamps match, the two are concatenated at the object level. This solves the data fragmentation caused by asynchronous extraction and hierarchical processing of key and regular data, ensuring that while achieving low-latency priority transmission of key data, the original full picture of global data at the same moment can be restored in the backend. This improves the integrity and temporal consistency of the final stored ship fuel supply records.

[0037] In conjunction with some implementation methods of the first aspect, in some implementation methods, when it is determined that the first generation timestamp matches the second generation timestamp, the routine business data and the key monitoring data corresponding to the first generation timestamp are concatenated at the object level to generate a complete ship fuel supply record for storage, specifically including:

[0038] Calculate the absolute value of the time difference between the first generation timestamp and the second generation timestamp;

[0039] Determine the historical variance of the key monitoring data corresponding to the first generated timestamp within a preset time period;

[0040] The dynamic time tolerance threshold is determined based on the historical volatility variance, and the value of the historical volatility variance is inversely proportional to the value of the dynamic time tolerance threshold.

[0041] If the absolute value of the time difference is less than the dynamic time tolerance threshold, the first generated timestamp and the second generated timestamp are matched.

[0042] By concatenating routine business data with key monitoring data corresponding to the first generated timestamp at the object level, a complete ship fuel supply record is generated.

[0043] Complete ship fuel supply records are saved to a database for storage.

[0044] By adopting the above technical solution, when determining whether the timestamps of key monitoring data and routine business data match, the historical fluctuation variance of the key monitoring data within a preset time period is calculated, and a dynamic time tolerance threshold that is inversely proportional to it is determined. This dynamic threshold is then used as the criterion for judging the time difference. This mechanism closely integrates the fault tolerance range of data matching with the actual physical stability state of the ship's fuel supply system. When the system state fluctuates drastically, the tolerance threshold is tightened to reduce the probability of mismatch, while the tolerance threshold is relaxed when the system state is stable to improve the matching success rate. This reduces the risk of data splicing misalignment caused by fixed time windows during asynchronous transmission and hierarchical processing, thereby improving the accuracy and reliability of the final generated ship fuel supply record in the time dimension.

[0045] In some embodiments, in conjunction with some implementations of the first aspect, after generating and storing a complete ship fuel supply record, the method further includes:

[0046] The first processing timestamp when key monitoring data is output to the shore-based server and the second processing timestamp when the complete ship fuel supply record is spliced ​​together;

[0047] Calculate the time difference between the second processing timestamp and the first processing timestamp to obtain the asynchronous delay duration of the current data packet;

[0048] Write the asynchronous delay duration into the preset sliding monitoring window;

[0049] Calculate the rate of change of multiple consecutive asynchronous delay durations within a preset sliding monitoring window to obtain the delay growth gradient;

[0050] If the delay growth gradient is determined to be greater than the preset warning threshold, a target acquisition frequency that is inversely proportional to the delay growth gradient is determined.

[0051] Encapsulate the target acquisition frequency into a regular data down-frequency command;

[0052] The command to downsample regular data is sent to the ship via the maritime wireless network so that the ship can collect subsequent regular business data at the target sampling frequency.

[0053] By employing the above technical solution, the asynchronous delay duration of the current data packet is calculated by extracting the processing timestamps of the key monitoring data output and the complete record splicing. Furthermore, the rate of change of continuous asynchronous delay durations is calculated to obtain the delay growth gradient. When the delay growth gradient exceeds a warning threshold, the system determines a target acquisition frequency inversely proportional to this gradient and issues a routine data frequency reduction command to the ship. By monitoring the real-time trend of asynchronous processing time difference on the shore-based server, the system detects deterioration of the maritime wireless network environment or system processing bottlenecks, and proactively reduces the acquisition and transmission frequency of routine business data on the ship when congestion intensifies. By dynamically reducing the transmission volume of low-priority data, the network load and server cache pressure in weak network environments are reduced, thereby improving the transmission stability of key monitoring data during network congestion and the overall system's resilience.

[0054] In conjunction with some implementation methods of the first aspect, in some implementation methods, when it is determined that the delay growth gradient is greater than a preset warning threshold, a target acquisition frequency that is inversely proportional to the delay growth gradient is determined, specifically including:

[0055] If the delay growth gradient is determined to be greater than the preset warning threshold, obtain multiple historical transmission bandwidths recorded within the preset sliding monitoring window;

[0056] Calculate the bandwidth attenuation slope for multiple historical transmission bandwidths;

[0057] The composite congestion index is obtained by weighting and summing the delay growth gradient and the bandwidth decay slope.

[0058] From the preset frequency mapping table, obtain the frequency reduction coefficient corresponding to the numerical range of the composite congestion index;

[0059] The initial collection frequency of routine business data during the current ship fuel supply process;

[0060] The product of the initial acquisition frequency and the down-conversion coefficient is determined as the target acquisition frequency, so that the value of the target acquisition frequency decreases as the delay growth gradient increases.

[0061] By adopting the above technical solution, when determining the target acquisition frequency for routine business data, the bandwidth attenuation slope of historical transmission bandwidth is further introduced. A composite congestion index is obtained by weighted summation of the delay growth gradient and the bandwidth attenuation slope. The acquisition frequency is then adjusted based on the corresponding frequency reduction coefficient matched to this index, making the system's assessment of the current communication link congestion status more comprehensive and objective. Quantifying the frequency reduction magnitude through multi-dimensional composite indicators reduces the probability of excessive or insufficient frequency reduction caused by fluctuations in a single indicator. This makes the dynamic adjustment of the routine business data acquisition frequency more closely reflect the actual network degradation level, thereby improving the system's refined control level in balancing data transmission reliability and data acquisition integrity in complex maritime communication environments.

[0062] In a second aspect, embodiments of this application provide a data transmission system for ship fuel supply information. The data transmission system for ship fuel supply information includes: one or more processors and a memory; the memory is coupled to one or more processors, and the memory is used to store computer program code, the computer program code including computer instructions, and one or more processors call the computer instructions to cause the system to perform the method described in the first aspect and any possible implementation thereof.

[0063] Thirdly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a system, cause the system to perform the method described in the first aspect and any possible implementation thereof.

[0064] Fourthly, embodiments of this application provide a computer program product that, when run on a system, causes the system to execute the method described in any possible implementation of the first aspect.

[0065] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0066] 1. This application provides a method for transmitting ship fuel supply information. By dividing multi-dimensional real-time data during the ship fuel supply process into key monitoring data and routine business data, and serializing the key monitoring data to the beginning of the payload area of ​​the data packet to be sent, a byte length identifier and an independent checksum for the key monitoring data are written into the header area. This provides a structure for priority parsing when the data is transmitted via a maritime wireless network. When the shore-based server detects that the current network bandwidth is below a preset threshold, it can accurately extract the byte segments corresponding to the key monitoring data from the receive buffer in advance based on the header identifier while continuously receiving the remaining byte stream. It then performs independent verification and deserialization, allowing the key data to be parsed preferentially without waiting for the entire data packet containing routine business data to be received. This reduces the transmission and processing latency of key monitoring data in weak maritime network environments and improves the timeliness of ship fuel supply information data transmission.

[0067] 2. This application provides a method for transmitting ship fuel supply information. After pre-verification and output of key monitoring data, the method continuously monitors the receiving buffer to obtain a complete byte stream and determines the offset cursor of regular data based on the length identifier of the header area, thereby accurately extracting and deserializing regular business data. The method extracts the first generation timestamp of the regular business data and compares it with the second generation timestamp of the latest output key monitoring data from the shore-based server. If the timestamps match, the two are concatenated at the object level. This solves the data fragmentation caused by asynchronous extraction and hierarchical processing of key data and regular data, ensuring that while achieving low-latency priority transmission of key data, the original full picture of global data at the same moment can be restored in the backend, thereby improving the integrity and temporal consistency of the finally stored ship fuel supply records.

[0068] 3. This application provides a method for transmitting ship fuel supply information. By extracting the processing timestamps of key monitoring data output and the completion of the complete record splicing, the asynchronous delay duration of the current data packet is calculated. Furthermore, the rate of change of continuous asynchronous delay durations is calculated to obtain the delay growth gradient. When the delay growth gradient exceeds a warning threshold, the system determines a target acquisition frequency inversely proportional to this gradient and issues a command to reduce the frequency of regular data transmission to the ship. By monitoring the time difference changes in asynchronous processing on the shore-based server in real time, the system detects the deterioration of the maritime wireless network environment or system processing bottlenecks, and proactively reduces the acquisition and transmission frequency of regular business data on the ship when congestion intensifies. By dynamically reducing the transmission volume of low-priority data, the network load and server cache pressure in weak network environments are reduced, thereby improving the transmission stability of key monitoring data during network congestion and the overall system's resilience. Attached Figure Description

[0069] Figure 1 This is a flowchart illustrating a method for transmitting ship fuel supply information in an embodiment of this application.

[0070] Figure 2 This is another flowchart illustrating a method for transmitting ship fuel supply information in an embodiment of this application.

[0071] Figure 3 This is another flowchart illustrating a method for transmitting ship fuel supply information in an embodiment of this application.

[0072] Figure 4 This is a schematic diagram of the physical device structure of a data transmission system for ship fuel supply information provided in an embodiment of this application. Detailed Implementation

[0073] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to any or all possible combinations including one or more of the listed items.

[0074] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0075] The following example is used in conjunction with Figure 1 The present application describes a method for transmitting ship fuel supply information in an embodiment of the present application:

[0076] Please see Figure 1 This is a flowchart illustrating a method for transmitting ship fuel supply information in an embodiment of this application.

[0077] S101. Divide the multi-dimensional real-time data in the ship fuel supply process into key monitoring data and routine business data.

[0078] The system divides multi-dimensional real-time data from the ship's fuel supply process into key monitoring data and routine operational data. This step can be achieved in at least two ways:

[0079] The system can extract equipment status identifier sequences from multi-dimensional real-time data; based on the equipment status identifier sequences, determine the current operational stage of the ship's fuel supply process. The operational stage represents the physical process of the ship's fuel supply process and includes the pipeline pre-cooling stage, the initial refueling stage, and the pressure stabilization supply stage; obtain the set of core monitoring dimensions that uniquely correspond to the operational stage from the preset stage mapping knowledge base; identify the data items in the multi-dimensional real-time data that belong to the set of core monitoring dimensions as key monitoring data; and identify the remaining data items in the multi-dimensional real-time data other than the key monitoring data as regular business data.

[0080] The system can also obtain a preset whitelist of basic key data, and classify data in the multi-dimensional real-time data that are in the preset whitelist as initial key data, and data that are not in the preset whitelist as initial regular data; construct a sliding time window corresponding to the initial regular data, and calculate the real-time change rate of the initial regular data within the sliding time window; extract fluid pressure and fluid temperature values ​​from the initial key data, and calculate the physical fluctuation benchmark of the current pipeline based on the current values ​​of fluid pressure and fluid temperature; if it is determined that the real-time change rate in the initial regular data exceeds the physical fluctuation benchmark, the corresponding initial regular data is transformed to obtain advanced key data; the initial key data and advanced key data are merged as key monitoring data, and the remaining initial regular data after the advanced transformation is used as regular business data.

[0081] First, let's explain all the terms involved in this step: Multi-dimensional real-time data refers to the comprehensive data set reflecting the system's operating status collected by various sensors and monitoring equipment during ship fuel supply operations. This can include fluid temperature, pipeline pressure, valve opening, pump speed, etc. Key monitoring data refers to data items in the multi-dimensional real-time data that have a decisive impact on the safety and core processes of ship fuel supply. Routine business data refers to data items in the multi-dimensional real-time data, excluding key monitoring data, used for daily recording, statistics, or non-emergency state analysis. Equipment status identifier sequence refers to a set of codes arranged chronologically to uniquely represent the current operating mode or start / stop status of each piece of equipment. Operation phase refers to a specific operational period in the ship fuel supply process at the physical level, which can include the pipeline pre-cooling phase, initial refueling phase, and pressure stabilization phase. Pre-set phase mapping knowledge base refers to a structured information set pre-built and stored in a database, recording the correspondence between different operation phases and the required monitoring focus. Core monitoring dimension set refers to a list of data types that must be monitored frequently and with high precision for a specific operation phase. The preset basic critical data whitelist refers to a directory pre-configured by the system administrator, explicitly defining which data types are considered critical data by default under all circumstances. Initial critical data refers to data that meets the criteria after initial screening from the preset basic critical data whitelist. Initial regular data refers to data that does not belong to the whitelist after initial screening. A sliding time window refers to a dynamic data processing interval in a continuous data stream, segmented by a fixed time length and continuously sliding forward over time. Real-time change rate refers to the ratio of the magnitude of the change in initial regular data within the sliding time window to the time span. Fluid pressure value refers to the pressure exerted by the fuel on the pipe wall inside the pipeline. Fluid temperature value refers to the real-time thermodynamic temperature of the fuel inside the pipeline. The physical fluctuation benchmark refers to a reference value reflecting the upper limit of data fluctuation allowed under normal physical conditions of the current pipeline. It is derived from a dynamic threshold calculated in real-time based on fluid pressure and fluid temperature values ​​using a preset algorithm. This benchmark is compared with the real-time change rate to determine whether data changes are abnormal. Data that was originally initial regular data but has had its importance level temporarily increased due to its change characteristics exceeding the physical fluctuation benchmark.

[0082] For the first implementation, the system can utilize a rule-matching engine to achieve the first refined technical solution. The system extracts the device status identifier sequence from multi-dimensional real-time data, inputs this sequence into a finite state machine model built in memory for state transition parsing, and determines the current operational stage of the ship's fuel supply process based on the final dwell node of the state machine. Subsequently, the system establishes a connection with a relational database and, by executing a structured query language, performs precise matching from a preset stage mapping knowledge base using the name of the operational stage as the primary key to obtain the core monitoring dimension set uniquely corresponding to that operational stage. The system traverses the currently received multi-dimensional real-time data, reading the dimension attribute label of each data item one by one. Data items whose dimension attribute labels exist in the core monitoring dimension set are extracted, stored in a high-priority memory area, and identified as key monitoring data. For any remaining unextracted data items after the traversal, the system moves them uniformly to a low-priority memory area and identifies them as regular business data.

[0083] The system can also utilize a large-scale stage recognition model based on Long Short-Term Memory (LSTM) networks to achieve the first refined technical solution. The underlying structure of this model includes an input layer, an LSM network layer, a fully connected layer, and a Softmax output layer. The training set consists of a massive number of equipment status identifier sequence samples from historical ship fuel supply processes, while the test set consists of historical equipment status identifier sequence samples independent of the training set. Both the training and test sets are labeled with corresponding manually annotated operation stages. The system inputs the extracted equipment status identifier sequences as input data into the model, which then outputs the current operation stage through forward propagation. The system uses a key-value pair caching system, using the output operation stage as the key, to quickly retrieve the corresponding core monitoring dimension set from a pre-defined stage mapping knowledge base. The system employs a data filtering algorithm to perform intersection operations on the multi-dimensional real-time data and the core monitoring dimension set, identifying the data items in the intersection as key monitoring data. It then performs difference operations on the multi-dimensional real-time data and the intersection, identifying the data items in the difference as regular business data.

[0084] For the second implementation, the system can employ a streaming data processing framework to implement the second refined technical solution. The system reads a pre-defined whitelist of basic key data from the configuration file and loads it into a hash table in memory. It then iterates through multi-dimensional real-time data, using hash lookups to classify data matching the whitelist as initial key data and those not matching as initial regular data. The system constructs a sliding time window of corresponding length for the initial regular data in memory, using a difference algorithm to calculate the difference between the first and last values ​​of the initial regular data within the sliding time window and divide it by the time span to obtain the real-time rate of change. The system extracts fluid pressure and temperature values ​​from the initial key data and substitutes them into a pre-defined multiple linear regression equation to calculate the physical fluctuation benchmark for the current pipeline. The system uses a numerical comparator to determine if the real-time rate of change exceeds the physical fluctuation benchmark. If it does, the system modifies the memory label of the corresponding initial regular data to a higher-priority label, thus performing a step-by-step transformation to obtain step-by-step key data. The system uses an array concatenation function to merge the initial key data and the step-by-step key data into key monitoring data, and uses the remaining initial regular data with unmodified labels after the step-by-step transformation as regular business data.

[0085] The system can also implement a second refined technical solution based on a complex event processing engine. The system retrieves a pre-defined whitelist of basic key data stored on the configuration server, uses a Bloom filter to quickly screen multi-dimensional real-time data, classifies the screened data as initial key data, and classifies the intercepted data as initial regular data. The system allocates a fixed-length circular queue as a sliding time window for the initial regular data, and uses a moving average algorithm to calculate the slope of change between adjacent data points in the queue as the real-time rate of change. The system extracts fluid pressure and temperature values ​​and inputs them into a pre-established nonlinear dynamic threshold evaluation function to calculate the physical fluctuation benchmark. When the system detects that the real-time rate of change is greater than the physical fluctuation benchmark, it triggers an event processing rule, modifies the metadata attributes of the corresponding initial regular data to perform a cross-level transformation, and generates cross-level key data. The system uses a data aggregation component to package and encapsulate the initial key data and cross-level key data into key monitoring data, and retains the initial regular data that has not triggered event processing rules as regular business data.

[0086] S102. Serialize the key monitoring data to the beginning of the data payload area of ​​the data packet to be sent, and serialize the regular business data after the key monitoring data;

[0087] Serialization refers to the process of converting complex data structures or objects in memory into a continuous stream of bytes that can be transmitted over a network or persistently stored. A data packet to be sent refers to a data unit containing a complete protocol structure that the system prepares to send to external nodes at the network layer. The payload area refers to the storage space within the data packet specifically used to carry the actual business data, distinct from the header space used for routing and control. The starting position refers to the physical or logical address of the first byte of the payload area in the memory address space.

[0088] The system can implement this step using a custom serialization tool based on a binary protocol. The system allocates a contiguous block of memory for the data packets to be sent and divides it into a header area and a data payload area according to the protocol specification. The system calls the underlying binary conversion interface to convert the critical monitoring data into a binary byte stream according to preset byte alignment and endianness rules. The system obtains the starting physical memory address of the data payload area and directly writes the binary byte stream of the critical monitoring data to this starting position using a memory copy function. Subsequently, the system calls the binary conversion interface again to convert the regular business data into a binary byte stream, obtains the memory address of the end position of the critical monitoring data byte stream as the new write starting point, and appends the binary byte stream of the regular business data after the critical monitoring data, completing the serialization and splicing of the entire data payload area.

[0089] The system can also implement this step using a serialization library based on a lightweight data exchange format. The system constructs a composite structure containing critical monitoring data objects and regular business data objects at the application layer, and uses protocol buffer technology to serialize this composite structure. When defining the serialization structure file, the system sets the field numbers of the critical monitoring data fields to the highest priority, ensuring that the critical monitoring data is encoded first and placed at the beginning of the generated byte array during the execution of the compiled serialization code. The system sets the field numbers of the regular business data fields to the second highest priority, ensuring that they automatically follow the byte stream corresponding to the critical monitoring data during encoding. The system then fills the data payload area of ​​the data packet to be sent into the final complete byte array all at once.

[0090] S103. Write the byte length identifier and independent checksum for key monitoring data into the header area of ​​the data packet to be sent;

[0091] The header area refers to the specific sequence of bytes at the very beginning of the data packet to be sent, used to store control information, routing information, and metadata descriptions of the data. The byte length identifier is a numerical field used to accurately record the total number of bytes occupied by the critical monitoring data after serialization. The independent checksum is a uniquely calculated signature for critical monitoring data, used to verify data integrity and correctness; it is only related to the content of the critical monitoring data and is unaffected by regular business data.

[0092] The system can implement this step using a Cyclic Redundancy Check (CRC) algorithm. The system acquires the byte stream of the serialized critical monitoring data, counts the total number of bytes occupied, and converts this total number of bytes into a fixed-bit unsigned integer value as the byte length identifier. The system inputs the byte stream of critical monitoring data into the CRC calculation function, performs modulo-2 division on the byte stream using a preset generator polynomial, and extracts the final remainder as the independent check value. The system locates a pre-reserved specific offset position in the header region of the data packet to be sent, and sequentially writes the byte length identifier and the independent check value into these designated memory spaces according to network byte order requirements, completing the encapsulation of the header region control information.

[0093] The system can also implement this step using a hash algorithm. The system uses a built-in length calculation module to read the difference between the end and start memory pointers of the critical monitoring data in the data payload area, and uses this difference directly as the byte length identifier. The system uses a message digest algorithm to perform a hash operation on the byte stream of the critical monitoring data, generating a fixed-length hash value, and extracting the first few bytes of this hash value as an independent checksum. The system constructs a metadata structure in the header area of ​​the data packet to be sent, assigns the byte length identifier and the independent checksum as member variables of this structure, and then converts the entire metadata structure into a byte stream and overwrites the beginning position of the header area.

[0094] S104. Send the data packets to be sent to the shore-based server in the form of a byte stream via the maritime wireless network;

[0095] A maritime wireless network refers to a radio network system deployed in a marine environment to enable communication between ships and shore-based facilities. This can include very small aperture terminal satellite communication networks, maritime fifth-generation mobile communication networks, or very high frequency (VHF) communication networks. A byte stream refers to a continuous sequence of data, broken down and organized into bytes, during network transmission. A shore-based server refers to the core computing equipment deployed in a land-based data center, responsible for receiving, processing, and storing data from ships.

[0096] The system can achieve this step by establishing a Transmission Control Protocol (TCP) connection. The system calls the operating system's network socket interface, specifies the Internet Protocol address and communication port of the shore-based server, and initiates a three-way handshake via the maritime wireless network to establish a reliable TCP connection. After successful connection establishment, the system converts the encapsulated data packets to be sent into a continuous byte stream, and uses the socket's send function to push the byte stream in batches to the operating system's network send buffer. The underlying network protocol stack automatically handles the fragmentation, packetization, and routing operations of the byte stream, and stably sends the byte stream to the shore-based server via the satellite communication link or microwave link of the maritime wireless network.

[0097] The system can also implement this step using the User Datagram Protocol (UDP) combined with application-layer reliability mechanisms. The system implements packet numbering and retransmission logic at the application layer, splitting the data packets to be sent into multiple small byte stream fragments suitable for the maximum transmission unit (MTU) of the maritime wireless network. Leveraging the connectionless nature of UDP, the system directly sends these byte stream fragments to the shore-based server via the maritime wireless network. During transmission, the system dynamically adjusts the transmission rate based on network congestion and appends a sequence number and timestamp to a custom header of each byte stream fragment, enabling the shore-based server to reassemble the fragments upon receiving out-of-order byte streams.

[0098] S105. During the process of receiving the byte stream, the shore-based server obtains the transmission bandwidth of the current network environment in real time.

[0099] The receive buffer refers to a dedicated memory area allocated by the shore-based server to temporarily store data received from the network interface card that has not yet been processed by the application layer program. Transmission bandwidth refers to the amount of data that can actually be successfully transmitted per unit of time under the current network connection status.

[0100] The system can implement this step using the network monitoring interface of the operating system kernel. During the process of receiving byte streams from the shore server, the system starts an independent background monitoring thread. This background monitoring thread periodically calls the network status query system call provided by the operating system to obtain the total number of bytes received by the current network interface card per unit time. The system divides the obtained total number of bytes by the monitoring period time interval to calculate the real-time receiving rate, which is used as the transmission bandwidth of the current network environment. The system updates the calculated transmission bandwidth value to the shared memory area in real time for subsequent data processing modules to read at any time.

[0101] The system can also implement this step based on the application-layer data reception statistics mechanism. The system maintains a sliding time window and a byte counter in the application-layer receiving program on the shore server. Whenever the system successfully reads a batch of bytes from the network socket and stores it in the receive buffer, it increments the number of bytes read into the byte counter and records the current timestamp. As the sliding time window moves forward, the system calculates the average receiving rate based on the total number of bytes accumulated within the window and the window's time span, using this as the transmission bandwidth of the current network environment. The system writes this transmission bandwidth value into a global state variable.

[0102] S106. If it is determined that the transmission bandwidth is lower than the preset bandwidth threshold, determine the cumulative length of the received bytes in the receiving buffer of the shore server.

[0103] The preset bandwidth threshold is a fixed value pre-set in the system configuration file. It is derived from a critical value for weak network environments based on historical maritime network performance data analysis. This threshold is compared with the transmission bandwidth to determine whether the current network is in a weak state. The cumulative length refers to the total number of bytes that the shore-based server has successfully received and stored in the receive buffer, starting from the first byte of the current data packet.

[0104] The system can implement this step by polling the receive buffer status. The system reads the real-time updated transmission bandwidth from shared memory and compares it with a preset bandwidth threshold using a numerical comparator. If the transmission bandwidth is determined to be lower than the preset bandwidth threshold, the system triggers a weak network processing mode. In this mode, the system calls the receive buffer status query function to obtain the tail and head pointers of the currently valid data in the buffer. The system determines the cumulative length of bytes that have been received and stored in the receive buffer by calculating the memory address difference between the tail and head pointers.

[0105] The system can also implement this step using an event-driven mechanism combined with pointer offset calculation. A listener is set up in the network status assessment module. When the calculated transmission bandwidth is lower than a preset bandwidth threshold, the listener throws a weak network environment event. After the system's receiving program captures this event, it immediately locks the read / write operations of the receive buffer. The system reads the write cursor position maintained internally in the receive buffer. Since the starting cursor position of the receive buffer is reset to zero when processing each new data packet, the current write cursor position represents the cumulative length of received bytes. After the calculation is complete, the system releases the read / write lock.

[0106] S107. When the cumulative length reaches the sum of the fixed length of the header region and the byte length identifier, while continuously receiving the remaining byte stream, extract the byte segment located after the header region from the receiving buffer whose length corresponds to the byte length identifier.

[0107] Fixed length refers to the constant number of bytes occupied by basic control information in the header area of ​​the data packet to be sent, excluding variable fields, as mandated by the protocol specification. A byte segment refers to an independent data sequence extracted from a complete continuous byte stream according to a specific starting position and length; in this context, it specifically refers to a binary sequence containing critical monitoring data.

[0108] The system can implement this step using memory slicing technology. The system continuously monitors the cumulative length of received bytes. When the system determines that the cumulative length is equal to or greater than the sum of the fixed length of the header region and the value indicated by the byte length identifier, the system operates on the receive buffer using memory slicing functions without blocking the underlying network receiving thread. The system uses the end position of the header region as the starting offset and the value of the byte length identifier as the slice length to copy the corresponding memory block from the receive buffer, forming an independent byte fragment. Simultaneously, the system keeps the underlying network receiving thread running, continuously receiving the remaining byte stream and writing it to the subsequent space of the receive buffer.

[0109] The system can also employ a double-buffered queue mechanism to implement this step. The system configures two cooperating circular buffers on the shore-based server. When the cumulative length reaches the sum of the fixed length of the header region and the byte length identifier, a dedicated data extraction task is initiated. This task accurately calculates the start and end indices of the critical monitoring data in the first circular buffer based on the byte length identifier parsed from the header region. The system then extracts bytes within this index range one by one and combines them into byte fragments through a loop reading method. During this process, the system automatically routes and continuously writes newly arriving remaining byte streams into the second circular buffer.

[0110] S108. Verify the byte segment based on the independent check value;

[0111] Verification refers to the process by which the receiving end uses a specific algorithm to recalculate the received data and compare it with a reference value provided by the sending end in order to confirm whether the received data has been bit-flipped, lost, or tampered with during network transmission.

[0112] The system can achieve this step by recalculating and comparing the Cyclic Redundancy Check (CRC) code. After extracting the byte segment, the system inputs it into the CRC algorithm module, which uses the same generator polynomial parameters as the sender. This module performs a polynomial modulo 2 division on all binary bits in the byte segment to generate a locally calculated checksum. The system extracts the independent checksum from the previously parsed header region and uses a memory comparison function to compare the locally calculated checksum with the independent checksum bit by bit. If they match perfectly, the system sets the internal checksum status flag to "pass".

[0113] The system can also implement this step through hash value matching. The system calls the built-in cryptographic hash function library, using the same message digest algorithm as the sender to hash the extracted byte fragment, generating a fixed-length local hash digest. The system reads the independent checksum carried in the header area and performs a memory-level equivalence check on it against the local hash digest. If every byte of the two hash values ​​in memory is identical, the system determines that the byte fragment's content is complete and has not been tampered with, thus confirming the check passes and triggering the subsequent deserialization process.

[0114] S109. After confirming that the verification has passed, deserialize the byte fragments into key monitoring data output.

[0115] Deserialization refers to the process of re-parseing and restoring a byte stream received from the network or read from the disk according to specific format rules into the original complex data structure or object in memory. Output refers to the operation of passing the deserialized structured data to other business modules, storage systems, or front-end display interfaces on the shore server.

[0116] The system can implement this step using dynamic parsing based on reflection. After verification, the system dynamically creates an empty data object according to the predefined key monitoring data class structure, using the reflection mechanism of the programming language. The system calls the deserialization engine to read the corresponding bytes from the byte fragments sequentially according to the byte alignment rules and data type length agreed upon by the sender, and converts them into basic data types such as integers, floating-point numbers, or strings. The system uses the reflection interface to inject the values ​​of these basic data types one by one into the corresponding attributes of the empty data object, and finally outputs the filled key monitoring data object to the rendering queue of the real-time monitoring screen.

[0117] The system can also implement this step using static parsing based on pre-compiled templates. During the compilation phase, the system generates dedicated deserialization template code based on the structure of the key monitoring data. After verification, the system directly passes the memory pointer of the byte fragment to the pre-compiled template. The template code quickly maps the binary data in the byte fragment to a structure instance in memory using hard-coded memory offsets and type conversion instructions. After mapping, the system uses an inter-process communication mechanism to publish the recovered key monitoring data structure as a message payload to a specific topic in the message middleware for the shore-based business systems to subscribe to and display.

[0118] In the above embodiments, by dividing the multi-dimensional real-time data of the ship's fuel supply process into key monitoring data and regular business data, and serializing the key monitoring data to the beginning of the payload area of ​​the data packet to be sent, while writing the byte length identifier and independent checksum for the key monitoring data in the header area, the data has a structural basis for priority parsing when transmitted through the maritime wireless network. When the shore-based server obtains in real time that the current network transmission bandwidth is lower than a preset threshold, it can accurately extract the byte fragments corresponding to the key monitoring data from the receive buffer in advance based on the header identifier while continuously receiving the remaining byte stream, and perform independent verification and deserialization output. This allows the key data to be parsed first without waiting for the entire data packet containing regular business data to be received, thereby reducing the transmission and processing delay of key monitoring data in the weak network environment at sea and improving the timeliness of ship fuel supply information data transmission.

[0119] In the above embodiments, by prioritizing the extraction and output of key monitoring data, low-latency transmission and processing of core ship monitoring indicators are ensured in weak network environments. However, this layered processing and asynchronous extraction mechanism inevitably leads to the separation of key data and routine business data within the same data packet. To ensure the timeliness of key data while maintaining the integrity of global data, the system also needs to accurately extract the continuously received remaining routine business data and match and restore it with the already output key data in terms of time dimension. Based on this, this application provides another method for transmitting ship fuel supply information. The following is combined with... Figure 2 Another method for transmitting ship fuel supply information in the embodiments of this application is described below:

[0120] Please see Figure 2 This is another flowchart illustrating a method for transmitting ship fuel supply information in an embodiment of this application.

[0121] S201. Monitor the receiving buffer of the shore-based server until the remaining byte stream corresponding to the data packet to be sent is received, and obtain the complete byte stream of the data packet to be sent.

[0122] The remaining byte stream refers to the data sequence that continues to be transmitted at the lower network layer after key monitoring data has been extracted in advance and has not yet been fully read by the application layer. It usually contains the encoded content of regular business data. The complete byte stream refers to the set of all binary data in the data packet to be sent, from the header area to the tail area, representing the complete picture of the data packet at the network transmission layer.

[0123] The system can implement this step using a polling mechanism based on content length. The system maintains an expected total length variable in memory, obtaining its value by parsing the total packet length field in the header area of ​​the data packet to be sent. The system starts a loop timer to periodically check the total number of bytes of data received in the receive buffer. During each check, the system compares the total number of bytes received with the expected total length variable. If the total number of bytes received is less than the expected total length variable, the system continues to wait for the underlying network interface card to write the remaining byte stream into the receive buffer. When the total number of bytes received equals the expected total length variable, the system determines that the remaining byte stream has been received and immediately calls a memory read function to copy the corresponding contiguous memory block of length from the receive buffer to the application layer's independent working area, thereby obtaining the complete byte stream of the data packet to be sent.

[0124] The system can also implement this step using an event-driven mechanism based on a specific end-of-byte character. The system registers an asynchronous read callback function on the underlying network socket and loads a predefined end-of-byte character sequence into the memory matching engine. This callback function is automatically triggered when the underlying network protocol stack receives data and pushes it into the receive buffer. Inside the callback function, the system uses a streaming pattern matching algorithm to scan the newly arriving remaining byte stream in real time, searching for the end-of-byte character sequence. Before the end-of-byte character sequence is found, the system appends the received data fragments sequentially to a dynamically expanded byte array. Once the matching engine successfully locates the end-of-byte character sequence, the system immediately stops the appending operation and confirms that the remaining byte stream has been received. At this point, the dynamically expanded byte array stores the complete byte stream of the data packet to be sent.

[0125] S202. Determine the regular data offset cursor in the complete byte stream based on the sum of the fixed length of the header region and the byte length identifier;

[0126] A regular data offset cursor is a logical pointer or index value used to precisely indicate the starting position of regular business data in the memory address space of a complete byte stream. Its function is to serve as a physical boundary point separating critical monitoring data from regular business data.

[0127] The system can implement this step using memory address offset calculation technology. The system obtains the physical memory address of the first byte of the complete byte stream in the application layer workspace and stores it as the base address in a pointer variable. The system reads the fixed-length value of the previously parsed header region and the byte length identifier value, inputs these two values ​​into the arithmetic logic unit for addition, and obtains the total offset in bytes. Subsequently, the system uses pointer arithmetic rules to add the base address to the total offset in bytes to calculate the new physical memory address. The system assigns this new physical memory address to a specific pointer variable, which serves as the regular data offset cursor in the complete byte stream for subsequent data truncation operations.

[0128] The system can also employ a logical positioning algorithm based on array indexing to achieve this step. The system maps the acquired complete byte stream to a one-dimensional byte array, where the array's starting index is set to zero by default. The system extracts the fixed length of the header region and a byte length identifier representing the size of the critical monitoring data from the global state manager, and sums them using a built-in adder to obtain an unsigned integer index span value. Based on the starting index of the one-dimensional byte array, the system directly adds this index span value to obtain a target index position. The system records the value of this target index position in the configuration register in memory, using it as a regular data offset cursor, thereby accurately marking the starting position of regular business data within the complete byte stream array at the logical level.

[0129] S203. Starting from the regular data offset cursor, extract the tail byte fragment from the complete byte stream and deserialize the tail byte fragment into regular business data;

[0130] The tail byte segment refers to the binary data block that remains after the header area and key monitoring data have been stripped from the complete byte stream, and is specifically used to carry regular business data.

[0131] The system can implement this step using memory slicing and a lightweight data exchange format parsing engine. Starting from the memory address indicated by the regular data offset cursor, the system uses the difference between the total length of the complete byte stream and the corresponding offset of the regular data offset cursor as the truncation length. It then calls a memory copy function to copy the corresponding binary data block from the complete byte stream, forming an independent tail byte fragment. Subsequently, the system inputs this tail byte fragment into a pre-initialized lightweight data exchange format parsing engine. The parsing engine performs lexical and syntactic analysis on the tail byte fragment according to preset key-value pair mapping rules, restoring the binary encoding layer by layer into a hierarchical memory object. This deserializes the tail byte fragment into regular business data and stores it in the regular data cache pool.

[0132] The system can also implement this step using streaming read and a custom binary protocol deserialization component. The system encapsulates the complete byte stream into an input stream object and calls the flow control interface, using the value of a regular data offset cursor to directly jump the input stream's read pointer to the corresponding position. Starting from this pointer position, the system continuously reads data from the input stream until the end of the stream, using the read content as the tail byte fragment. Next, the system starts the custom binary protocol deserialization component, extracting bytes sequentially from the tail byte fragment according to the field order, data type, and byte endianness defined in the protocol specification, and performing type conversion. The system then fills the converted values ​​and strings into a pre-instantiated regular business data structure, completing the deserialization process.

[0133] S204. Extract the first generation timestamp of regular business data and obtain the second generation timestamp of the latest key monitoring data output in the current shore-based server;

[0134] The first generation timestamp refers to the time stamp accurate to the millisecond or microsecond level assigned by the system clock when routine business data is collected and generated at the ship's end. The second generation timestamp refers to the time stamp generated synchronously when critical monitoring data is collected at the ship's end, and is used to accompany the priority transmission of critical monitoring data to the shore-based server.

[0135] The system can implement this step through object attribute access and in-memory database query mechanisms. The system obtains the deserialized regular business data object, calls the object's built-in attribute retrieval method, directly reads the reserved timestamp field in its metadata header, extracts the first generation timestamp, and stores it in a local variable. Simultaneously, the system establishes a connection with a key-value database deployed in the shore-based server's memory. Since the latest output critical monitoring data stores its timestamp as a specific key value in this database during output, the system quickly retrieves the value corresponding to that specific key from the in-memory database by executing a key-value query command, thereby obtaining the second generation timestamp of the latest output critical monitoring data in the current shore-based server.

[0136] The system can also achieve this step by parsing the abstract syntax tree and reading the global state registry. The system converts regular business data into an abstract syntax tree structure, uses a depth-first traversal algorithm to search for specific time node tags in the tree structure, locates and extracts the value corresponding to that tag as the first generated timestamp. For critical monitoring data, after each successful deserialization and output of critical monitoring data, the shore-based server calls the system's underlying state update interface to write its timestamp to the operating system's global state registry. The system then directly reads the second generated timestamp of the latest output critical monitoring data by calling the registry reading application programming interface provided by the operating system, specifying the corresponding registry path and key name.

[0137] S205. If the first generation timestamp and the second generation timestamp are determined to match, the regular business data and the key monitoring data corresponding to the first generation timestamp are concatenated at the object level to generate a complete ship fuel supply record for storage.

[0138] Once the first generation timestamp matches the second generation timestamp, the system performs object-level concatenation of regular business data and the key monitoring data corresponding to the first generation timestamp to generate a complete ship fuel supply record for storage, specifically including:

[0139] Calculate the absolute value of the time difference between the first and second generated timestamps; determine the historical fluctuation variance of the key monitoring data corresponding to the first generated timestamp within a preset time period; determine the dynamic time tolerance threshold based on the historical fluctuation variance, the value of the historical fluctuation variance is inversely proportional to the value of the dynamic time tolerance threshold; if the absolute value of the time difference is less than the dynamic time tolerance threshold, determine that the first and second generated timestamps match; perform object-level concatenation of regular business data and the key monitoring data corresponding to the first generated timestamp to generate a complete ship fuel supply record; save the complete ship fuel supply record to the database for storage.

[0140] The absolute value of the time difference refers to the time span after subtracting the first and second generation timestamps, taking the non-negative result. A preset time period refers to the fixed time window length pre-defined by the system for statistically analyzing historical data characteristics. Historical variance refers to the measure of the dispersion of the time intervals between the generation of key monitoring data within the preset time period. The dynamic time tolerance threshold refers to the maximum allowed time deviation between the first and second generation timestamps. This threshold is calculated based on the historical variance through an inverse proportional mapping; the two are inversely proportional, meaning the larger the historical variance, the smaller the dynamic time tolerance threshold. Object-level stitching refers to the operation of merging two independent data objects into a single comprehensive data object containing all attributes of both in memory. A complete ship fuel supply record refers to the stitched record, encompassing a full set of information covering both key monitoring data and routine business data at the same moment. A database refers to a system used for persistently storing data, which can include relational databases or time-series databases.

[0141] The system can extract the values ​​of the first and second generation timestamps, calculate the non-negative result of their difference using an absolute value calculation function, and obtain the absolute value of the time difference. The system retrieves the timestamp sequence of historical key monitoring data within a preset time period from the local cache, calls the variance calculation function in the statistical algorithm library to calculate the historical fluctuation variance of the sequence. The system uses a reciprocal function to convert the historical fluctuation variance into a dynamic time tolerance threshold, ensuring that the larger the variance value, the smaller the threshold. The system uses a numerical comparator to determine whether the absolute value of the time difference is less than the dynamic time tolerance threshold, and determines a match if the condition is met. The system uses an object merging function to copy the attributes of regular business data objects and key monitoring data objects into a newly created comprehensive class instance, generating a complete ship fuel supply record. The system obtains a connection through the database connection pool, executes a structured query language insert statement, and saves the record to a relational database for storage.

[0142] The system can also input the first and second generation timestamps into the time processing node of the stream processing engine, and calculate the absolute value of the time difference using the built-in absolute difference operator. The aggregation node of the stream processing engine continuously collects key monitoring data streams within a preset time period, and updates the historical fluctuation variance in real time using a sliding window variance statistical algorithm. The system inputs the historical fluctuation variance into a preset nonlinear inverse proportional decay function to calculate the dynamic time tolerance threshold. When the condition judgment node of the stream processing engine confirms that the absolute value of the time difference is less than the dynamic time tolerance threshold, it outputs a matching success signal. After receiving the signal, the system uses a data serialization tool to convert regular business data and key monitoring data into document format, and performs object-level splicing using a document merging operator to generate a complete ship fuel supply record. The system calls the application programming interface of the document-oriented database to save the complete ship fuel supply record to the document-oriented database for storage in an asynchronous write manner.

[0143] In the above embodiments, after completing the pre-verification and output of key monitoring data, the complete byte stream is obtained by continuously monitoring the receiving buffer, and the offset cursor of regular data is determined based on the length identifier of the header area, thereby accurately extracting and deserializing regular business data. The first generation timestamp of the regular business data is extracted and compared with the second generation timestamp of the latest output key monitoring data in the shore-based server. If the timestamps match, the two are concatenated at the object level. This solves the data fragmentation caused by asynchronous extraction and hierarchical processing of key data and regular data, ensuring that while achieving low-latency priority transmission of key data, the original full picture of global data at the same moment can be restored in the backend, thereby improving the integrity and temporal consistency of the finally stored ship fuel supply records.

[0144] Through the above embodiments, the system achieves object-level splicing of critical data and regular data, compensating for data fragmentation caused by asynchronous extraction and ensuring the integrity of the final stored record. However, in the actual maritime communication environment, network congestion is dynamic. If data reception and splicing are only passively performed on the shore-based server, the reception time of regular data will continuously increase as the network environment deteriorates, leading to aggravated asynchronous latency in data splicing, which may ultimately cause server buffer overflow and affect the stability of the overall system. Therefore, the system also needs to actively adjust the data acquisition strategy on the ship side based on the latency change trend during data processing. Based on this, this application provides another method for transmitting ship fuel supply information. The following is combined with... Figure 3 The present application describes another method for transmitting ship fuel supply information in its embodiments:

[0145] Please see Figure 3 This is another flowchart illustrating a method for transmitting ship fuel supply information in an embodiment of this application.

[0146] S301. Extract the first processing timestamp when key monitoring data is output to the shore-based server and the second processing timestamp when the complete ship fuel supply record is spliced.

[0147] The first processing timestamp refers to the precise timestamp recorded by the system kernel when critical monitoring data is successfully deserialized and pushed to the output interface during the processing flow on the shore-based server. The second processing timestamp refers to the precise timestamp recorded by the system kernel when routine business data and critical monitoring data are successfully joined at the object level on the shore-based server to form a complete ship fuel supply record. These two timestamps are used together to define the time span of data during asynchronous processing within the server.

[0148] The system can implement this step using aspect-oriented programming (AOP) combined with system clock calls. Time-aspect interceptors are embedded in the data output and data stitching modules of the shore-based server. When critical monitoring data triggers a call event at the output interface, the first interceptor immediately captures the event and calls the underlying operating system's high-precision time acquisition function to obtain the current system time in milliseconds, storing it as the first processing timestamp in the context environment variable corresponding to the current data packet. When the complete ship fuel supply record is stitched and triggers a storage event, the second interceptor captures the event, again calls the high-precision time acquisition function to obtain the current system time in milliseconds, and stores it as the second processing timestamp in the same context environment variable.

[0149] The system can also utilize the event sourcing mechanism in a message-driven architecture to achieve this step. A distributed event bus is deployed within the shore-based server, with all data processing nodes connected to this bus. When critical monitoring data is output, the output node publishes an output completion event message to the event bus, containing a unique packet identifier and the current node's machine time. When a complete ship fuel supply record is stitched together, the stitching node publishes a stitching completion event message to the event bus, containing the same unique packet identifier and the current node's machine time. A dedicated monitoring microservice in the system subscribes to these two types of event messages, and by matching the same unique packet identifier, parses and extracts the first and second processing timestamps from the received message payloads, respectively.

[0150] S302. Calculate the time difference between the second processing timestamp and the first processing timestamp to obtain the asynchronous delay duration of the current data packet;

[0151] The time difference refers to the absolute distance between the second processing timestamp and the first processing timestamp on the timeline, usually measured in milliseconds or microseconds. The current data packet refers to the specific network transmission data unit that the system is currently performing latency calculations and processing analysis on. Asynchronous latency duration refers to the time span during which regular business data within the same data packet lags behind critical monitoring data processing due to the system's layered extraction and asynchronous splicing mechanism. This duration reflects the combined lag between the current system's processing capacity and network reception status.

[0152] The system can implement this step using a basic arithmetic logic unit combined with a time format conversion module. The system reads the first and second processing timestamps extracted from the context environment variables. Since these two timestamps may be stored in the standard Uniform Resource Time (URL) string format, the system first calls the time format conversion module to parse and convert these two string timestamps into long integer millisecond values ​​since the epoch time. Then, the system uses the converted second processing timestamp as the minuend and the first processing timestamp as the subtrahend, inputting them into the arithmetic logic unit of the central processing unit to perform a large integer subtraction operation. The system obtains the difference result and directly uses it as the asynchronous delay duration of the current data packet for subsequent processing.

[0153] The system can also utilize the built-in time duration calculation library in a high-level programming language to implement this step. The system obtains the original object instances of the first and second processing timestamps. The system directly calls the time interval calculation function in the time duration calculation library, passing the first and second processing timestamp objects as input parameters. This function automatically handles complex factors such as potential time zone differences, leap second adjustments, and underlying clock drift to accurately calculate the physical time interval between the two time points. The system extracts a numerical attribute in milliseconds from the function's return result, determines this numerical attribute as the asynchronous delay duration of the current data packet, and temporarily stores it in a temporary calculation result area in memory.

[0154] S303. Write the asynchronous delay duration into the preset sliding monitoring window;

[0155] The preset sliding monitoring window refers to a data structure with a fixed capacity that is pre-allocated in memory by the system. It is used to continuously store the delay data calculated in the most recent period in chronological order. When the number of stored data reaches the capacity limit, the newly stored data will automatically push out the oldest data, thereby realizing the forward sliding of the window.

[0156] The system can implement this step using an array-based circular queue data structure. During initialization, the system allocates a fixed-length floating-point array in memory as a preset sliding monitoring window and sets a write cursor to initially point to the zero index of the array. Once the system calculates the asynchronous delay duration of the current data packet, it directly assigns this delay duration value to the array element currently pointed to by the write cursor. After assignment, the system uses modulo operations to incrementally update the write cursor; that is, it increments the write cursor by one and then takes the modulo of the total array length. This ensures that the cursor automatically wraps back to the beginning when it reaches the end of the array, thus achieving a sliding update of the window by overwriting old data and completing the writing of the asynchronous delay duration.

[0157] The system can also implement this step using a linked list-based deque combined with a time-based eviction strategy. The system instantiates a deque object in memory as a preset sliding monitoring window. When a new asynchronous delay duration is obtained, the system encapsulates it and the current timestamp into a delay record node and calls the tail insertion method of the deque to append this node to the end of the queue. After each new node is written, the system starts a background cleanup routine, traversing the nodes starting from the head of the deque. The system checks the timestamp of the head node; if it finds that the difference between the head node and the current time exceeds the preset window time span, it calls the head pop method to remove it until the head node is within the valid time range, thus ensuring that the window always maintains the latest batch of asynchronous delay durations.

[0158] S304. Calculate the rate of change of multiple consecutive asynchronous delay durations within the preset sliding monitoring window to obtain the delay growth gradient;

[0159] Multiple consecutive asynchronous delay durations refer to a series of delay time values ​​stored in a preset sliding monitoring window, arranged closely according to the order in which data packets arrive. The rate of change of these delay time values ​​refers to how quickly they change as the sequence increases or as time progresses. The delay growth gradient is a mathematical indicator that quantifies the trend of asynchronous delay deterioration or mitigation; a positive value indicates that the delay is worsening, and a negative value indicates that the delay is decreasing.

[0160] The system can implement this step using a first-order difference averaging algorithm. The system iterates through a preset sliding monitoring window, extracting all asynchronous delay duration values ​​sequentially and constructing a time series array. Using a loop structure, the system calculates the difference between adjacent elements in the array, subtracting the asynchronous delay duration of the previous data packet from the asynchronous delay duration of the next data packet, resulting in a series of first-order difference values. The system sums these first-order difference values ​​and divides them by the total number of differences to calculate the average difference value. This average difference value is used as the rate of change and directly defined as the current delay growth gradient, reflecting the overall average increase or decrease slope of the delay duration within the window period.

[0161] The system can also employ a least-squares linear regression algorithm to achieve this step. The system reads multiple consecutive asynchronous delay durations from a preset sliding monitoring window, using these as the dependent variable set, and simultaneously uses the sequence number of these delay durations within the window or their corresponding timestamps as the independent variable set. The system inputs these two sets of variables into the linear regression calculation module. This module utilizes the least-squares principle, calculating the slope of the line that minimizes the sum of the squared vertical distances from all data points to the fitted line by solving for and setting the partial derivatives to zero. The system uses the slope of this optimal fitted line as the rate of change of the numerical value and determines it as the delay growth gradient. This gradient can more smoothly and accurately reflect the macroscopic trend of delay changes.

[0162] S305. When it is determined that the delay growth gradient is greater than the preset warning threshold, a target acquisition frequency that is inversely proportional to the delay growth gradient is determined.

[0163] When the delay growth gradient is determined to be greater than a preset warning threshold, the system determines a target acquisition frequency that is inversely proportional to the delay growth gradient, specifically including:

[0164] When the delay growth gradient is determined to be greater than the preset warning threshold, multiple historical transmission bandwidths recorded within the preset sliding monitoring window are obtained; the bandwidth attenuation slope of the multiple historical transmission bandwidths is calculated; the delay growth gradient and the bandwidth attenuation slope are weighted and summed to obtain the composite congestion index; the frequency reduction coefficient corresponding to the numerical range of the composite congestion index is obtained from the preset frequency mapping table; the initial acquisition frequency of routine business data in the current ship fuel supply process is obtained; the product of the initial acquisition frequency and the frequency reduction coefficient is determined as the target acquisition frequency, so that the value of the target acquisition frequency decreases as the delay growth gradient increases.

[0165] The preset warning threshold is a judgment boundary pre-set by the system administrator based on the maximum cache capacity and processing limit of the shore-based server. It is used to compare with the latency growth gradient; when the gradient exceeds this threshold, it indicates that the system faces congestion risk. Historical transmission bandwidth refers to the network transmission rate recorded by the system at various time points within the time period corresponding to the preset sliding monitoring window. Bandwidth attenuation slope is an indicator of the rate at which historical transmission bandwidth decreases over time. The composite congestion index is a quantitative evaluation standard that comprehensively considers the degree of server processing latency aggravation and network bandwidth deterioration. The preset frequency mapping table is a key-value correspondence stored in the configuration database, recording the frequency reduction ratio that should be adopted for different congestion index intervals. The frequency reduction coefficient is a floating-point number between zero and one, used to proportionally reduce the collection frequency. The initial collection frequency refers to the ratio of the number of regular business data collections to the time under normal network conditions on the ship side. The target collection frequency refers to the new, lower data collection frequency that should be implemented on the ship side after congestion control adjustments.

[0166] When the delay growth gradient exceeds a preset warning threshold, the system extracts multiple historical transmission bandwidth value sequences from the extended fields of the preset sliding monitoring window. The system calls a linear fitting function from the data analysis and calculation library to calculate the slope of the descending trend line of the bandwidth sequence, taking its absolute value as the bandwidth attenuation slope. The system obtains pre-configured delay and bandwidth weights, multiplies the delay growth gradient by the delay weight, and multiplies the bandwidth attenuation slope by the bandwidth weight, then adds the products to obtain a composite congestion index. The system uses this composite congestion index as a query key to perform interval matching in a preset frequency mapping table pre-loaded into a memory hash table, extracting the corresponding frequency reduction coefficient. The system reads the initial acquisition frequency of regular business data from the global configuration file, multiplies the initial acquisition frequency by the frequency reduction coefficient using a floating-point multiplier to obtain the target acquisition frequency, thus achieving an inverse adjustment where the frequency decreases as the gradient increases.

[0167] When the numerical comparator determines that the delay growth gradient exceeds a preset warning threshold, the system triggers the congestion assessment topology of the streaming computing engine. This topology retrieves multiple historical transmission bandwidths within a preset sliding monitoring window from the state storage, calculates the bandwidth difference between the beginning and end using a differential operator, and divides it by the time span to obtain the bandwidth attenuation slope. The computing nodes use a built-in weighted summation formula to fuse the delay growth gradient and the bandwidth attenuation slope into a composite congestion index. The system constructs a structured query language statement, uses the composite congestion index as a condition parameter, and sends a query request to the relational database to retrieve the frequency reduction coefficient matching the index interval from a preset frequency mapping table. The system obtains the initial acquisition frequency set for the current voyage by calling the ship archive service interface, performs a multiplication operation at the application layer, multiplies the initial acquisition frequency by the frequency reduction coefficient, and calculates the final target acquisition frequency.

[0168] S306. Encapsulate the target acquisition frequency into a regular data down-frequency command;

[0169] A standard data down-frequency command refers to a network control message generated by a shore-based server and sent to the ship, containing specific control semantics and target acquisition frequency parameters. Encapsulation refers to the process of converting the target acquisition frequency value, which is currently in memory variable form, into a byte sequence that can be directly transmitted over the network, according to a specific network communication protocol format, by adding necessary message headers, checksums, and terminators.

[0170] The system can employ Extensible Markup Language (XML) serialization technology to implement this step. The system instantiates an instruction object model in memory, sets the instruction type attribute to "regular data downsampling," and assigns the calculated target sampling frequency value to the object's frequency parameter attribute. The system then calls the XML serialization engine to convert the instruction object model into a text string with a hierarchical tag structure. Subsequently, the system adds a standard application layer protocol header to the beginning of this text string, including the total message length, protocol version number, and timestamp information, and appends a cyclic redundancy check (CRC) code to the end. The system converts the concatenated string into a byte sequence of a uniform format, thus completing the encapsulation of the regular data downsampling instruction.

[0171] The system can also implement this step using a custom compact binary protocol encoding. The system allocates a fixed-size byte buffer in memory. First, the system writes a pre-agreed single-byte opcode to the beginning of the buffer; this opcode uniquely identifies the regular data down-frequency operation. Next, the system converts the target sampling frequency value into an unsigned short integer and writes it into the two bytes following the opcode, according to network byte order. To ensure instruction security and tamper resistance, the system uses a hash message authentication code algorithm to encrypt the three bytes written, generating a fixed-length secure signature, which is then appended to the end of the buffer. The system then extracts all bytes from the buffer, using this as the encapsulated regular data down-frequency instruction.

[0172] S307. Send the command to downgrade the frequency of regular data to the ship via the maritime wireless network so that the ship can collect subsequent regular business data at the target acquisition frequency.

[0173] Maritime wireless networks refer to wireless communication infrastructure covering marine areas, such as satellite communication links or coastal base station networks, used to enable data exchange between shore and ships. The shipside refers to the hardware and software suite consisting of edge computing gateways, data acquisition programmable logic controllers, and various sensors installed on the vessel.

[0174] The system can achieve this step by establishing a dedicated transmission control protocol (TCP) control channel. The system uses a socket interface in the network communication module of the shore-based server to establish and maintain a long-term TCP channel with the ship-side edge computing gateway. This channel is independent of the massive data upload channel to ensure the real-time performance of control commands. The system writes the encapsulated byte sequence of regular data downsampling commands into the socket's transmit buffer. The underlying operating system reliably routes and transmits the byte sequence to the ship-side via the maritime wireless network. Upon receiving the command, the ship-side edge computing gateway parses it, extracts the target acquisition frequency, and uses the industrial fieldbus protocol to modify the period register value of the regular business data acquisition timer in the underlying programmable logic controller, thereby enabling the ship-side to acquire subsequent regular business data according to the new target acquisition frequency.

[0175] The system can also implement this step using the publish-subscribe mechanism of the message queue telemetry transport protocol. On the shore-based server, the system acts as a message publisher, publishing encapsulated routine data downsampling instructions as message payloads to a dedicated downlink control topic for the ship in the cloud message broker server. The ship's data acquisition system, acting as a message subscriber, continuously listens to this control topic via the maritime wireless network. When the message broker server pushes the instructions to the ship, the ship's protocol client triggers a callback function to deserialize the instruction payload into the target acquisition frequency. Based on this target acquisition frequency, the ship's main control program dynamically adjusts the sleep interval of the routine business data sensor polling task, thereby reducing the frequency of routine business data acquisition and transmission.

[0176] In the above embodiments, the asynchronous delay duration of the current data packet is calculated by extracting the processing timestamps of the key monitoring data output and the complete record splicing, and further calculating the numerical change rate of the continuous asynchronous delay duration to obtain the delay growth gradient. When the delay growth gradient exceeds the warning threshold, the system determines the target acquisition frequency that is inversely proportional to the gradient and issues a routine data frequency reduction command to the ship. By monitoring the time difference change trend of asynchronous processing on the shore-based server in real time, the system can detect the deterioration of the maritime wireless network environment or system processing bottlenecks, and proactively reduce the acquisition and transmission frequency of routine business data on the ship when congestion intensifies. By dynamically reducing the transmission volume of low-priority data, the network load and server cache pressure in weak network environments are reduced, thereby improving the transmission stability of key monitoring data and the overall system's resilience during network congestion.

[0177] The system in the embodiments of this invention is described below from the perspective of hardware processing. Please refer to [link / reference needed]. Figure 4 This is a schematic diagram of the physical device structure of a data transmission system for ship fuel supply information provided in an embodiment of this application.

[0178] It should be noted that, Figure 4 The structure of the system shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0179] like Figure 4As shown, the system includes a Central Processing Unit (CPU) 401, which can perform various appropriate actions and processes based on a program stored in Read-Only Memory (ROM) 402 or a program loaded from storage portion 408 into Random Access Memory (RAM) 403, such as executing the methods described in the above embodiments. The RAM 403 also stores various programs and data required for system operation. The CPU 401, ROM 402, and RAM 403 are interconnected via a bus 404. An Input / Output (I / O) interface 405 is also connected to the bus 404.

[0180] The following components are connected to I / O interface 405: input section 406 including a camera, infrared sensor, etc.; output section 407 including a liquid crystal display (LCD) and speakers, etc.; storage section 408 including a hard disk, etc.; and communication section 409 including a network interface card such as a LAN (Local Area Network) card and a modem, etc. Communication section 409 performs communication processing via a network such as the Internet. Drive 410 is also connected to I / O interface 405 as needed. Removable media 411, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 410 as needed so that computer programs read from it can be installed into storage section 408 as needed.

[0181] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 409, and / or installed from removable medium 411. When the computer program is executed by central processing unit (CPU) 401, it performs the various functions defined in the present invention.

[0182] It should be noted that the computer-readable medium shown in the embodiments of the present invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In the present invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In the present invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, wherein a computer-readable computer program is carried. The transmitted data signal can take many forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof.

[0183] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0184] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the system described in the above embodiments; or it may exist independently and not assembled into the system. The storage medium carries one or more computer programs that, when executed by a processor of a system, cause the system to implement the methods provided in the above embodiments.

[0185] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0186] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

[0187] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0188] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for transmitting ship fuel supply information, characterized in that, include: The multi-dimensional real-time data in the ship fuel supply process is divided into key monitoring data and routine business data. The key monitoring data is serialized to the beginning of the data payload area of ​​the data packet to be sent, and the regular business data is serialized after the key monitoring data; Write the byte length identifier and independent checksum for the key monitoring data into the header area of ​​the data packet to be sent; The data packets to be sent are transmitted to the shore-based server in the form of a byte stream via a maritime wireless network. During the process of receiving the byte stream, the shore-based server obtains the transmission bandwidth of the current network environment in real time. If the transmission bandwidth is determined to be lower than a preset bandwidth threshold, the cumulative length of the received bytes is determined in the receiving buffer of the shore-based server. When the cumulative length reaches the sum of the fixed length of the header region and the byte length identifier, while continuously receiving the remaining byte stream, a byte segment located after the header region and whose length corresponds to the byte length identifier is extracted from the receiving buffer. The byte fragment is verified based on the independent check value; After the verification is confirmed to be successful, the byte fragment is deserialized into the key monitoring data output.

2. The method according to claim 1, characterized in that, The process of dividing multi-dimensional real-time data in the ship fuel supply process into key monitoring data and routine business data specifically includes: Extract the device status identifier sequence from the multi-dimensional real-time data; Based on the equipment status identifier sequence, the current operational phase of the ship fuel supply process is determined. The operational phase characterizes the physical process of the ship fuel supply process and includes the pipeline precooling phase, the initial refueling phase, and the pressure stabilization supply phase. Obtain the set of core monitoring dimensions that uniquely correspond to the operation stage from the preset stage mapping knowledge base; The data items belonging to the core monitoring dimension set in the multi-dimensional real-time data are identified as key monitoring data. The remaining data items in the multi-dimensional real-time data, excluding the key monitoring data, are identified as regular business data.

3. The method according to claim 1, characterized in that, The process of dividing multi-dimensional real-time data in the ship fuel supply process into key monitoring data and routine business data specifically includes: Obtain a preset basic key data whitelist, and classify the data in the multi-dimensional real-time data that are in the preset basic key data whitelist as initial key data, and classify the data that are not in the preset basic key data whitelist as initial regular data; Construct a sliding time window corresponding to the initial normal data, and calculate the real-time rate of change of the initial normal data within the sliding time window; Extract the fluid pressure and fluid temperature values ​​from the initial key data, and calculate the physical fluctuation benchmark of the current pipeline based on the current values ​​of the fluid pressure and fluid temperature; If the real-time rate of change in the initial routine data exceeds the physical fluctuation benchmark, the corresponding initial routine data will be transformed to obtain key data. The initial key data and the upgraded key data are merged into key monitoring data, and the remaining initial regular data after the upgraded conversion is used as regular business data.

4. The method according to claim 1, characterized in that, After confirming that the verification has passed and deserializing the byte fragment into the key monitoring data output, the method further includes: Monitor the receive buffer of the shore-based server until the remaining byte stream corresponding to the data packet to be sent is received, and obtain the complete byte stream of the data packet to be sent; The regular data offset cursor in the complete byte stream is determined based on the sum of the fixed length of the header region and the byte length identifier; Starting from the regular data offset cursor, extract the tail byte fragment from the complete byte stream, and deserialize the tail byte fragment into regular business data; Extract the first generation timestamp of the regular business data, and obtain the second generation timestamp of the latest key monitoring data output from the current shore-based server; If the first generated timestamp matches the second generated timestamp, the regular business data and the key monitoring data corresponding to the first generated timestamp are concatenated at the object level to generate a complete ship fuel supply record for storage.

5. The method according to claim 4, characterized in that, When it is determined that the first generated timestamp matches the second generated timestamp, the routine business data and the key monitoring data corresponding to the first generated timestamp are concatenated at the object level to generate a complete ship fuel supply record for storage. Specifically, this includes: Calculate the absolute value of the time difference between the first generated timestamp and the second generated timestamp; Determine the historical fluctuation variance of the key monitoring data corresponding to the first generated timestamp within a preset time period; The dynamic time tolerance threshold is determined based on the historical fluctuation variance, and the value of the historical fluctuation variance is inversely proportional to the value of the dynamic time tolerance threshold. If the absolute value of the time difference is less than the dynamic time tolerance threshold, the first generated timestamp is determined to match the second generated timestamp. The regular business data is combined with the key monitoring data corresponding to the first generated timestamp at the object level to generate a complete ship fuel supply record. The complete ship fuel supply record is saved to a database for storage.

6. The method according to claim 4, characterized in that, After the complete ship fuel supply record is generated and stored, the method further includes: Extract the first processing timestamp when the key monitoring data is output to the shore-based server and the second processing timestamp when the complete ship fuel supply record is spliced ​​together. Calculate the time difference between the second processing timestamp and the first processing timestamp to obtain the asynchronous delay duration of the current data packet; Write the asynchronous delay duration into a preset sliding monitoring window; Calculate the rate of change of multiple consecutive asynchronous delay durations within the preset sliding monitoring window to obtain the delay growth gradient; If the delay growth gradient is determined to be greater than a preset warning threshold, a target acquisition frequency that is inversely proportional to the delay growth gradient is determined. The target acquisition frequency is encapsulated into a conventional data down-frequency command; The command to downsample the regular data is sent to the ship via the maritime wireless network, so that the ship can collect subsequent regular service data at the target sampling frequency.

7. The method according to claim 6, characterized in that, The step of determining a target acquisition frequency that is inversely proportional to the delay growth gradient when the delay growth gradient is determined to be greater than a preset warning threshold specifically includes: If the delay growth gradient is determined to be greater than a preset warning threshold, multiple historical transmission bandwidths recorded within the preset sliding monitoring window are obtained. Calculate the bandwidth attenuation slope of the multiple historical transmission bandwidths; The composite congestion index is obtained by weighting and summing the delay growth gradient and the bandwidth attenuation slope. Obtain the frequency reduction coefficient corresponding to the numerical range of the composite congestion index from the preset frequency mapping table; The initial collection frequency of the aforementioned routine business data during the current ship fuel supply process is determined. The product of the initial acquisition frequency and the down-conversion coefficient is determined as the target acquisition frequency, so that the value of the target acquisition frequency decreases as the delay growth gradient increases.

8. A data transmission system for ship fuel supply information, characterized in that, The system includes: One or more processors and a memory; the memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the system to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instructions are executed on the system, the system performs the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on the system, the system performs the method as described in any one of claims 1-7.

Images