Balancing Efficiency and Data Quality in Change-Aware Shipboard Sensor Data Transmission

Abstract

Shipboard data servers sample many sensor channels at a fixed interval, although many channels repeat their value or vary only within a small tolerance. This study examines how far transmission to shore can be reduced while the received stream remains fit for its intended use. Traces from five liquefied natural gas (LNG) carriers with 1300–1870 channels per vessel were cleaned of no-signal sentinels and profiled by value type and temporal behaviour. Seven policies, from full and compressed transmission to change-only, heartbeat, deadband, spike-aware, and adaptive transmission, were applied and reconstructed at the receiver. Indicators derived from the International Organization for Standardization and International Electrotechnical Commission (ISO/IEC) standards 25012 and 25024 were evaluated against acceptance profiles for alarm monitoring, condition-monitoring dashboards, and aggregate evidence. Applied to all channels, the adaptive policy removed 82.8% of the records, with a normalised error of 0.08% on numeric channels and no missed state transition. Savings ranged from 73.9% on all float channels to 98.7% on quasi-static ones. Gzip reduced bytes by 85.9% but removed no records, and compressing the reduced stream removed a further 51–78% of the compressed bytes. Staleness, rather than reconstruction error, limited the reduction, so heartbeats must be set in elapsed time.

1. Introduction

Maritime digitalisation turns shipboard sensor data into a shore-facing data product used for condition monitoring, energy management, remote diagnosis, operational decision support, and environmental compliance [1,2,3]. The Maritime Single Window (MSW), the International Maritime Organization (IMO) Data Collection System (DCS), the Carbon Intensity Indicator (CII), the European Union (EU) Emissions Trading System (EU ETS), and FuelEU Maritime all raise the value of reliable operational data interfaces between ship and shore [4,5,6,7,8,9,10,11]. The engineering objective is no longer simply to transmit more data. It is to transmit data in a form that remains fit for its intended shore-side use while controlling communication, storage, and processing cost.

An often overlooked property of shipboard sensor data is that repeated acquisition does not necessarily imply repeated information change. A vessel may record hundreds or thousands of channels at a fixed sampling interval, but many channels remain unchanged, change only rarely, or vary only within a small engineering tolerance [12,13]. Alarm flags, equipment statuses, operating modes, counters, setpoints, and some floating-point measurements can be static, quasi-static, event-driven, slowly varying, or monotonic over long periods. Transmitting every sampled value at the acquisition frequency can therefore create a large number of records whose information value is small relative to their communication cost. General-purpose compression can reduce wire bytes after records have been generated, but it does not reduce message generation, queue growth, ingestion burden, or the recovery load created by unnecessary updates [14,15]. Reducing the records themselves is the older industrial tradition of exception reporting and deadband-based historian methods and of more recent event- and self-triggered transmission designs [16,17,18,19,20,21].

This paper frames the problem as a data-quality trade-off rather than as a pure compression problem. The International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) Systems and software Quality Requirements and Evaluation (SQuaRE) series provides a useful basis for this framing because it treats data quality as a set of measurable characteristics rather than as a single notion of correctness [22,23,24]. In this paper, selected SQuaRE-inspired characteristics are mapped to shipboard transmission metrics. Efficiency is represented by byte and message reduction. Accuracy is represented by reconstruction error. Completeness is represented by event miss and spike recall. Currentness is represented by receiver-side staleness. Consistency is represented by the preservation of aggregate and temporal behaviour. This mapping allows change-aware transmission policies to be evaluated not only by how much traffic they save, but also by what kind of data quality they preserve or sacrifice. In this paper, a balance between efficiency and data quality is therefore not a single optimum. It is defined operationally as the policy that transmits the fewest records while satisfying an explicit, service-specific acceptance profile, namely, bounds on reconstruction error, event and excursion preservation, receiver-side staleness, and aggregate error that are stated before the policies are compared (Section 3.7).

This study evaluated change-aware transmission using operational traces from five liquefied natural gas (LNG) carriers sampled on a sub-minute grid. The dataset contains 9.8 million timestamped rows and 1300–1870 sensor channels per vessel after sentinel cleanup. Each channel was first profiled by value type and temporal behaviour, including boolean, enumeration, counter, string, and floating-point channels and static, quasi-static, event-driven, slowly varying, continuously varying, monotonic, and noisy behaviours. We then compared full transmission, compressed full transmission, exact change-only transmission, change transmission with heartbeat, deadband transmission, spike-aware deadband transmission, and a type-and-behaviour adaptive policy. The receiver reconstructed the shore-side time series, and each policy was evaluated using both communication metrics and SQuaRE-inspired data-quality metrics.

The study is organised around three research questions (RQs), each answered by a defined set of indicators and analyses (Table 1).

Table 1. RQs, indicators, and where they are answered.

Question	Indicators and Analyses	Sections
RQ1	zero-change ratio (ZCR), deadband-stable ratio (DSR), value-type inventory, missing-data strata, operating-phase split, typing validation	Section 4.1
RQ2	records sent, logical bytes, same-format gzip and zstd bytes, consolidated whole-stream comparison	Section 4.2 and Section 4.5
RQ3	reconstruction error, event miss, step and windowed excursion recall, staleness in steps and seconds, aggregate error, acceptance-profile check, perturbation tests	Section 4.3, Section 4.4, Section 4.5, Section 4.6, Section 4.7, Section 4.8, Section 4.9 and Section 4.10

• RQ1. How much of a repeatedly sampled shipboard stream is exactly or quasi-constant once no-signal sentinels are removed, and how does this differ by value type, vessel, missing-data level, and operating phase?
• RQ2. Which parts of the transmission cost do compression and change-aware record suppression each remove, when both are measured on the same channel population, record format, and codec?
• RQ3. Which policy transmits the fewest records while staying within an explicit, service-specific data-quality acceptance profile, and how robust is that choice to the deadband, heartbeat, sampling interval, and transport disturbances?

The study builds on established mechanisms, namely, exception reporting, deadbands, heartbeats, and compression, and its contribution is empirical and methodological. It is threefold. First, it provides a cross-vessel profile of value type and temporal behaviour for five shipboard data servers, including the effect of no-signal sentinels, missing data, and operating phase on the apparent stability of the channels. Second, it turns selected ISO/IEC SQuaRE data-quality characteristics into transmission-level indicators and acceptance criteria so that a reduced stream can be accepted or rejected for a stated shore-side service rather than judged by bytes alone. Third, it compares compression, change-only, heartbeat, deadband, spike-aware, and adaptive policies on identical channel populations and identical record formats and reports where each policy meets or fails those criteria.

The remainder of this paper is organised as follows. Section 2 reviews shipboard data standards, SQuaRE data-quality concepts, and related work on time-series compression and change-based telemetry. Section 3 describes the dataset, cleanup, profiling, transmission policies, reconstruction methods, and evaluation metrics. Section 4 presents the cross-vessel results. Section 5 discusses implications and limitations. Section 6 concludes the paper.

2. Background and Related Work

2.1. Maritime Data Standards and Regulatory Reporting

Shipboard sensor data are no longer a local on-board signal. They are an addressable asset in a standardised ship–shore information exchange that is increasingly tied to regulatory reporting and verification. Two complementary layers govern that exchange. The semantic layer is set by ISO 19847, which specifies the requirements for a shipboard data server that collects and shares field data safely and efficiently, and by ISO 19848, which standardises the naming, units, quality codes, and update cycles of sensor channels through a hierarchical data-channel identifier and an accompanying data-channel list [12,13]. These standards make a vessel’s sensor inventory machine-readable, but they do not prescribe a transmission rate or a data-reduction policy for the channels that they catalogue.

The service and regulatory layer is set by IMO and regional frameworks that consume those channels. The MSW institutionalises digital ship–shore information exchange for harbour-clearance and compliance workflows, while the IMO Compendium harmonises message and declaration data across maritime services and has been recently extended to safety-information channels such as Navigational Telex (NAVTEX) [4,5,25]. In the EU, the European Maritime Single Window environment links national single windows and the SafeSeaNet system for electronic port-call data exchange [26]. Environmental and carbon-intensity regimes add operational reporting and aggregate-evidence requirements that depend on shipboard data, including the IMO DCS, the CII, the EU Monitoring, Reporting and Verification regulation, the EU ETS extension to maritime transport, and FuelEU Maritime [6,7,8,9,10,11]. The transport link itself is rarely a uniform pipe as surveys of maritime communication networks emphasise that satellite, aerial, terrestrial, and short-range maritime channels coexist with widely different latency and capacity constraints [27,28]. The downstream services that consume these data range from real-time monitoring and dashboarding to periodic compliance evidence and long-term audit archives, each with different freshness, fidelity, and traceability requirements.

A shipboard sensor stream is typically retained on board in raw archival form, often a columnar file written at the acquisition cadence, while a separate operational stream is transmitted to shore for active monitoring and reporting. The two purposes are different. The raw archive is the system of record and must preserve every recorded value for audit. The operational stream is a derived data product whose granularity should be matched to the downstream service. Conflating the two leads either to over-transmission, in which the operational stream carries every recorded value at the acquisition cadence, or to under-archival, in which the raw record is discarded once a reduced operational view has been sent. This paper assumes that the raw archive is retained on board and focuses on the operational stream.

The standards define what each channel means, and the service and regulatory frameworks define what evidence the shore side must obtain from those channels. Neither layer prescribes whether every sampled value must travel to shore at the acquisition cadence. That decision sits in the shipboard gateway and is an architectural and data-quality problem rather than a standardisation problem.

2.2. ISO/IEC SQuaRE Data Quality Model

The ISO/IEC SQuaRE series provides a structured way to reason about data quality [22]. ISO/IEC 25012 defines a data quality model in which data quality is decomposed into measurable characteristics such as accuracy, completeness, consistency, credibility, currentness, accessibility, compliance, confidentiality, efficiency, precision, traceability, and understandability [23]. The model further distinguishes between inherent quality, which is a property of the data themselves, and system-dependent quality, which depends on the system in which the data are used. ISO/IEC 25024 provides a corresponding set of measurement functions for these characteristics [24]. Although these standards are intended for software and information systems in general rather than for maritime telemetry, the underlying view that data quality is multi-dimensional and measurable applies directly to shipboard sensor transmission.

For change-aware shipboard transmission, the relevant characteristics can be operationalised as communication and reconstruction metrics. Table 2 summarises the mapping used in this paper. Efficiency corresponds to how much of the original byte and message volume is avoided. Accuracy is the closeness between the receiver-side reconstructed series and the original sampled series. Completeness is the preservation of meaningful changes and excursions that the receiving service needs to observe. Currentness is the freshness of the most recent value available at the receiver. Consistency is the preservation of aggregate and temporal behaviour, such as cumulative sums, state transitions, and counter monotonicity, that downstream calculations rely on.

Table 2. SQuaRE data-quality characteristics mapped to study metrics.

SQuaRE Characteristic	Meaning in This Paper	Metric
Efficiency	Resource reduction in transmission and synchronisation	Bytes saved, message reduction, bytes per synchronised sample (BPSS)
Accuracy	Closeness of reconstructed stream to sampled stream	Root-mean-square error (RMSE), normalised RMSE (NRMSE), 95th-percentile (P95) error
Completeness	Preservation of required changes and excursions	Event miss, spike recall, update coverage
Currentness	Freshness of the receiver-side value	P95 staleness, max staleness
Consistency	Preservation of aggregate and temporal behaviour	Aggregate error, counter/state violation

This mapping defines the evaluation lens used here. A transmission policy is not better merely because it sends fewer bytes. It is better when it achieves a favourable balance between efficiency and the data-quality characteristics required by the receiving service.

The indicators are narrower than the corresponding ISO/IEC 25012 definitions, and the difference matters for interpretation. ISO/IEC 25012 describes the quality of data with respect to the real-world entity they represent, partly as an inherent property of the data and partly as a property that depends on the system that stores and delivers them [23]. In this study the reference is not the physical process but the cleaned archived stream recorded on board. Every indicator therefore measures the degradation introduced by transmission, which is a system-dependent property, and none of them certifies the inherent quality of the sensor data. Three characteristics are used in a deliberately restricted sense. Completeness in ISO/IEC 25012 concerns whether required attribute values are present. Here it concerns whether the changes and excursions present in the archive are also present at the receiver, so an event miss is a completeness defect introduced by the policy, while values missing in the archive itself are reported separately as null and sentinel ratios. Currentness in ISO/IEC 25012 concerns whether data are of the right age for the task. Here it is the age of the receiver-side value at the moments when a fresh value exists on board, measured in grid steps and in elapsed seconds. Consistency in ISO/IEC 25012 concerns freedom from contradiction and coherence with other data. Here it is the agreement between aggregates, state sequences, and counter monotonicity computed from the reduced stream and from the archive. ISO/IEC 25024 measurement functions are used as a template for expressing each indicator as a ratio or bounded quantity [24], not as a claim of conformance to the standard.

2.3. Change-Aware Reporting and Time-Series Compression

Reducing the cost of transmitting repeatedly sampled data has a long industrial history. Two related traditions have developed independently. The historian tradition decides which samples are informative enough to retain or report. The time-series compression and columnar storage tradition compresses the samples that have already been generated. The two address different layers of the same cost model and combine cleanly.

The historian tradition is the older of the two. Industrial process historians have long used exception reporting and deadband-like rules to retain only those samples that deviate from the previously reported value by more than an engineering threshold. Vendor implementations such as the AVEVA PI System separate exception reporting at the interface from compression testing at the archive, transmitting only meaningful changes and storing only the points needed to reconstruct the trend within a tolerance [29]. The same logic is formalised at the subscription layer by OPC Unified Architecture (OPC UA), whose DataChangeFilter suppresses value-change notifications within an absolute or percent deadband while preserving status changes [30]. The swinging-door trending algorithm extended this idea to a piecewise-linear envelope that preserves trend slope while discarding intermediate samples [16]. Subsequent work assessed the practical accuracy and downstream impact of process-data compression and showed that the window-size parameter of box-car back-slope compression could be tuned automatically rather than fixed [17,31]. More recent work on statistical deadband reframes the threshold as an event-based reporting rule whose parameter is set from the signal’s own variability, while Zhang et al. propose an adaptive threshold that responds to concept drift to balance reduction rate and reconstruction accuracy in Internet of Things (IoT) settings [18,32]. The common pattern is to suppress non-informative updates at the source, transmit a heartbeat or checkpoint so that the receiver can distinguish silence from steady state, and reconstruct the signal at the receiver by holding the last observation or by interpolating between received points [33].

Heartbeats add a bounded liveness contract so that the receiver can distinguish an unchanged sensor from a silent or disconnected sensor. Spike-aware variants add an exception that forces transmission when the inter-sample step exceeds a larger threshold so that fast excursions are preserved even for wide deadbands. Counter channels can be reduced further by transmitting deltas with periodic checkpoints. On the receiving side, the operational stream is reconstructed for display, alerting, and aggregation purposes by last-observation-carried-forward (LOCF) for state-like channels, by linear or piecewise interpolation for slowly varying floats, and by checkpoint-plus-delta reconstruction for counters.

The compression and columnar-storage tradition operates after records have already been generated. Time-series database systems such as Gorilla apply delta-of-delta encoding on timestamps and exclusive-or (XOR)-based encoding on values to compress monitoring streams in memory [14]. Lightweight integer codecs such as Sprintz target the same problem for IoT-class devices [34]. Recent floating-point codecs such as ACTF further improve the lossless ratio achievable on sensor traces, while dynamic bit-packing exploits per-channel bit-depth variation [35,36]. Bounded-error piecewise-linear approximation generalises this trade-off to multi-fidelity output streams, and evolving multivariate codecs exploit correlation across channels for IoT settings [37,38]. A recent survey of time-series compression catalogues lossless, error-bounded lossy, online, and segment-based variants of these techniques [15]. Columnar transport formats such as Apache Parquet apply column-wise encodings, including run-length, dictionary, delta, and bit-packing, to repeated and similar values within a column. An empirical evaluation of columnar storage formats shows that the achievable compression ratio depends heavily on dictionary encoding, integer decoding, and block compression [39]. The general-purpose codecs used in transport, such as gzip and zstd, exploit byte-level redundancy in serialised payloads. All of these techniques compress the records that the application chooses to emit. They do not decide whether a record should be emitted, and they do not affect message count, queue length, broker fan-out, or per-record processing cost downstream of the compressor. This per-record cost is significant on constrained collectors and a recent survey of the IoT-edge-cloud continuum identifies it as a first-class concern alongside payload size [40,41].

Industrial historian methods and time-series compression therefore reduce different parts of the communication cost rather than the same part. The present study does not propose a new compression algorithm. It evaluates whether simple change-aware reporting policies, in the historian tradition, preserve SQuaRE-inspired data-quality dimensions on multi-vessel shipboard traces while keeping general-purpose compression as a baseline for the byte-size layer.

Table 3 summarises the part of the cost model that each technique addresses and the part it does not.

Table 3. Cost components reduced by compression and change-aware transmission.

Approach	What It Reduces	What It Does Not Decide
General compression	Byte size of generated records	Whether a record should be generated
Columnar storage	Archive and batch-transfer size	Receiver-side currentness of operational values
Change-only reporting	Repeated unchanged records	Bounded liveness without heartbeat
Deadband reporting	Small non-meaningful numeric changes	Spike preservation unless explicitly handled
Heartbeat	Staleness uncertainty	Payload size of each update

The relevant research question is therefore not whether compression or change-aware transmission is superior in general but how they affect different cost and quality dimensions when applied to repeatedly sampled shipboard sensor streams.

2.4. Literature Review

Recent work has refined the change-aware transmission idea along three lines that are closely related to this paper. The first line is event- and self-triggered control, where the trigger rule itself is designed from observed data rather than from a fixed model. De Persis et al. derive a data-based event-triggered controller and trigger rule for unknown continuous-time linear systems while preserving stability [19]. Liu et al. design a data-driven self-triggered law based on trajectory prediction to reduce communication overhead while maintaining performance [20]. Wang et al. extend the comparison of model-based and data-driven event/self-triggered designs to discrete-time linear systems [42]. These studies focus on closed-loop stability and on the design of the trigger itself rather than on the data-quality implications of the resulting reduced stream.

The second line is prediction- and estimator-driven transmission for sensor networks. Płaczek proposes prediction-based data reduction with dynamic target-node selection for IoT sensor networks, reporting substantial reductions in transmitted samples while preserving downstream selection accuracy [43]. Lee et al. couple an event-triggered transmission rule with twin hybrid filters to reduce sensor traffic while maintaining state-estimation quality in renewable energy resource management systems [44]. Yang et al. propose a semantic-based multi-packet parallel transmission scheme that performs analysis before transmission to mitigate limited-bandwidth constraints [21]. These works share the present paper’s premise that not every sample needs to be transmitted, but they are oriented toward control loops, sensor-network monitoring, or networked control systems rather than toward multi-channel operational shipboard streams evaluated against external data-quality requirements.

The third line is maritime telemetry and analytics, where the demand for shipboard sensor data is treated as given. Liu et al. survey air-to-sea integrated maritime IoT, including enabling technologies and open challenges [2]. Rigas et al. propose an end-to-end deep-learning framework for fault detection in marine machinery based on shipboard sensor time series [3]. Lee et al. extend the IMO Compendium with NAVTEX safety-information messages and demonstrate transport over Message Queuing Telemetry Transport (MQTT) [5]. Downstream anomaly-detection studies on shipboard machinery underscore that preserving rare excursions is operationally important, and recent work on range-aware time-series anomaly metrics shows that point-wise recall undercounts the cost of missed excursion ranges, motivating excursion-recall measures that operate over the surrounding window [45,46]. These studies confirm that shipboard sensor data are increasingly used as an analytics input and as a digital service across ship and shore, but the question of how aggressively the operational stream can be reduced while keeping the downstream service viable has received comparatively little attention.

A small number of maritime studies address telemetry reduction and edge-gateway processing directly. Surveys of the Internet of Ships list satellite communication, maritime data collection, and data management among its open challenges [47], and identify edge computing as the means of meeting the latency and processing requirements of ships close to the data source [48]. Ferreira and Martins propose an edge computing approach for a fishing-vessel-monitoring system that transmits in real time only data indicative of abnormal behaviour and defers the rest to port, reporting communication savings of 70–90% [49]. Michala et al. propose edge processing of machinery vibration for vessel condition monitoring and, using laboratory measurements and an open bearing dataset, report a reduction in the transmitted volume by about three orders of magnitude without changing the decision-support output [50]. Jurdana et al. propose an adaptive shipboard data compression method based on differential binary encoding for remote voyage monitoring of autonomous ships [51], and Zhang and Zeng combine quantisation, predictive coding, and arithmetic coding to fit ship status data into narrow-band BeiDou short messages [52]. These studies demonstrate the value of reducing data on board, but each addresses a single signal class, such as vibration or vessel position, a single encoding, or a bandwidth target. They do not profile the whole multi-type channel inventory of a shipboard data server, do not separate record suppression from byte compression on the same records, and do not state which data-quality properties the reduced stream must retain for a given shore-side use.

Across all three lines, data quality appears to be a dimension that is seldom named explicitly. Transmission reduction is reported in bytes, packets, or trigger rate, while the implications for accuracy, completeness, currentness, and consistency are typically left implicit. Maritime data standards and reporting frameworks (Section 2.1) define what each channel means and what evidence the shore side must obtain, but they do not specify a transmission policy. The SQuaRE data-quality model (Section 2.2) defines a measurable language for those properties but has, to our knowledge, mainly been applied to general information systems rather than to shipboard telemetry. The industrial historian tradition (Section 2.3) suppresses non-informative updates at the source, often on single signals in a single process, rather than on multi-vessel multi-channel shipboard traces and under an explicit data-quality budget. The gap that this paper seeks to address is therefore the combination, namely, an empirical evaluation of change-aware transmission on real shipboard sensor streams for both the maritime-standard semantic layer and the SQuaRE data-quality layer. Relative to the historian and deadband literature, the difference is in the unit of evaluation rather than in the mechanism. Historian studies tune one rule for one signal and judge it by trend fidelity. Here the same small rule set is applied to every channel of five data servers, the rule is selected from a measured profile of each channel, and the outcome is judged against several data-quality characteristics at once, including staleness in elapsed time, excursion preservation over several samples, and robustness to lost and reordered records, which single-signal studies rarely report together.

Table 4 summarises this position. Each row is a research stream rather than a single paper. Y indicates a dimension that the stream treats explicitly, ∼ indicates partial or implicit treatment, and – indicates that it is outside the stream’s usual scope. The column headings abbreviate shipboard data (Ship. data), compression (Comp.), change-aware reporting (Change), data quality (DQ), and receiver-side reconstruction (Recon.).

Table 4. Position of this paper relative to related research streams.

Research Stream	Ship. Data	Comp.	Change	DQ	Recon.
Maritime data standards (ISO 19847, 19848)	Y	–	–	∼	–
Maritime regulatory reporting (MSW, DCS, CII, EU)	∼	–	–	∼	–
SQuaRE data-quality model	–	–	–	Y	–
Time-series compression and columnar storage	–	Y	–	–	∼
Industrial historian and deadband	∼	–	Y	–	∼
Event/self-triggered control and prediction	–	–	Y	∼	∼
Maritime IoT and analytics	Y	–	–	∼	–
Maritime edge reduction and encoding	Y	Y	∼	–	∼
This work	Y	Y	Y	Y	Y

This paper seeks to address this gap by profiling repeatedly sampled shipboard sensor channels for ISO 19848-style channel semantics, applying full, compressed, change-only, heartbeat, deadband, spike-aware, and adaptive transmission policies, reconstructing the receiver-side stream, and evaluating each policy through SQuaRE-inspired efficiency, accuracy, completeness, currentness, and consistency metrics.

3. Methodology

This study evaluated change-aware transmission policies for repeatedly sampled shipboard sensor data through a controlled trace-replay and reconstruction study, summarised in Figure 1. The workflow had five stages. Per-vessel Parquet traces were loaded, and no-signal sentinels were replaced with nulls. Each channel was then typed and profiled by temporal behaviour. Seven transmission policies were applied to the cleaned traces. The shore-side time series was reconstructed at the receiver. Finally, the reconstructed and original streams were evaluated with SQuaRE-inspired data-quality characteristics and aggregated across the five vessels.

Figure 1. Five-stage methodology workflow.

The methodology did not involve the design of a new compression algorithm. It tested whether transmission frequency can be decoupled from acquisition frequency while preserving the data quality required by shore-side services. Compression was treated as a baseline, while change-aware transmission was evaluated as a policy that reduces the generation and transmission of redundant records.

3.1. Dataset and Scope

The dataset consists of operational sensor traces collected from five large LNG carriers of similar class, referred to in the remainder of the paper as V1 through V5 to preserve operator confidentiality. Each vessel was stored as a single Parquet file with a sub-minute sampling cadence whose effective median interval differs per vessel. The traces covered approximately 9.8 million timestamped rows in total, with 1300 to 1870 sensor columns per vessel. Four timestamp and metadata columns were excluded from sensor-channel profiling. The remaining channels included navigation, machinery, cargo, fuel, environmental, alarm, status, counter, and mode-related data.

Table 5 summarises the five-vessel dataset. The reported duration is the calendar span between the first and last recorded timestamps for each vessel. The median inter-row interval ranges from 8 s to 60 s across vessels and reflects the per-vessel acquisition system rather than a uniform 15 s grid. All policy and evaluation metrics in this paper were computed in grid steps, with one row per step, so that the comparison across vessels is independent of the absolute time interval. Because the same number of grid steps corresponds to different elapsed times on different vessels, heartbeat intervals and staleness are additionally reported in elapsed time computed from the recorded timestamps of each vessel, and no nominal cadence is assumed. The precise operator identity and collection period are not disclosed under the data-sharing agreement. The LNG carrier traces are used as a high-complexity shipboard sensor workload rather than as a claim that the proposed method applies only to LNG carriers.

Table 5. Per-vessel dataset summary.

Vessel	Rows	Sensor Columns	Calendar Duration	Median Interval
V1	∼3.5 M	1300	∼11 months	8 s
V2	∼3.3 M	1297	∼17 months	15 s
V3	∼1.3 M	1299	∼5 months	12 s
V4	∼0.9 M	1870	∼14 months	49 s
V5	∼0.8 M	1870	∼17 months	60 s
Total	∼9.8 M	union 2684	–	–

The five vessels share a ship type and an acquisition-system family, but their channel inventories and operating profiles differ. Table 6 gives the functional composition of the channels. V1–V3 carry about 1300 channels each and V4 and V5 about 1870, mainly because of a larger engine-room inventory, and between 234 and 277 channels per vessel are alarm, status, or mode channels according to the catalogue rule. The operating condition is characterised by the Global Positioning System (GPS) speed over ground (SOG). Among the grid steps with a valid speed, the vessels are underway, defined as at least 3 kn, for 56–87% of the time, and the rest covers port stays, anchorage, and manoeuvring. The traces therefore contain both seagoing and stationary operation, and Section 4.1 reports the policy results separately for the two phases. The study does not cover other ship types, other acquisition systems, or sub-second control and vibration data.

Table 6. Functional composition of the channel inventory and operating profile per vessel.

Vessel	Engine Room	Cargo	Navigation	Weather	Alarm/Status/Mode	Underway (SOG ≥ 3 kn)
V1	842	344	99	11	277	81%
V2	837	344	99	11	277	87%
V3	841	344	99	11	277	56%
V4	1362	434	59	11	234	69%
V5	1362	434	59	11	234	78%

3.2. Sentinel Cleanup and Numeric Coercion

Removing no-signal sentinel values is a required preprocessing step. The raw export uses values such as -9998 and -9999 to indicate missing samples or communication errors. These are not physical sensor readings. If treated as ordinary values, they create false changes and distort stability metrics such as ZCR and run length. In a representative window of 100,000 rows and 300 columns, sentinel values accounted for approximately 45% of cells, so sentinel cleanup must precede any temporal-behaviour analysis. Over the full traces, the mean sentinel ratio per channel ranges from 0.12 to 0.42 across vessels and the mean null ratio after cleanup from 0.24 to 0.49 (Section 4.1). Because all stability metrics were computed over consecutive valid samples, a high missing-data ratio could in principle make a channel look more stable than it is. Section 4.1 therefore stratifies the policy results by the null ratio.

The cleanup rule replaces a predefined set of string and numeric sentinels with null before type inference, equality checks, or difference calculations. The sentinel set includes -9999, -9998, -9997, -9996, NaN, nan, NULL, null, and empty strings. After cleanup, each column is numerically coerced when at least 95% of its non-null values can be parsed as numeric. This step is necessary because the raw exports store all sensor columns as text, including floating-point values.

3.3. Value-Type Inference and Temporal Profiling

Each cleaned channel is classified by value type and temporal behaviour. Value type describes the form of the recorded values, while temporal behaviour describes how those values evolve over time. The two dimensions need separate treatment. A floating-point channel may be quasi-static, slowly varying, or continuously varying, while an integer channel may be a categorical code or a monotonic counter.

The value-type inference rules are summarised in Table 7. The rules are evaluated in the order listed in the table, and the first rule that matches assigns the type. A column is treated as numeric when at least 95% of its non-null values parse as numbers, and a numeric column is integer-like when every non-null value equals its rounded value. A channel is classified as boolean when it has two or fewer unique non-null values. Numeric integer-like channels with a small number of unique values are treated as enumeration channels, while numeric integer-like channels that are mostly non-decreasing are classified as counters. Remaining numeric channels are classified as floating-point channels. Non-numeric channels with small cardinality are treated as enumeration channels, while other non-numeric channels are classified as string channels. Channels with no usable non-null data after cleanup are marked as empty.

Table 7. Value-type inference rules.

Order	Predicate	Inferred Type
1	No usable non-null values after cleanup	Empty
2	Non-null numeric values, unique count $\le 2$	Boolean
3	Numeric, integer-like, unique count $\le 32$	Enumeration
4	Numeric, integer-like, monotonicity score $\ge 0.95$	Counter
5	Numeric, otherwise	Float
6	Non-numeric, unique count $\le 32$	Enumeration
7	Non-numeric, otherwise	String

Because no vendor tag dictionary was available, the inferred types were validated against a semantic label derived from the ISO 19848-style channel path. A channel was labelled state when one of the last path elements named an alarm, trip, fault, warning, shutdown, status, mode, running, open or closed state, a command, or an acknowledgement. It was labelled counter when one of the last elements named run hours, a count, or a total and continuous when one of the last elements named a physical quantity such as temperature, pressure, flow, speed, level, power, current, or position. The labels were checked in that order, and channels without a match remained unlabelled. Table 8 cross-tabulates the semantic label against the inferred type for all 7614 channel instances of the five vessels. Of these, 86.4% receive a semantic label, and the inferred type agrees with the label for 81.6% of the labelled channels. Agreement is 97.7% for state channels and 84.5% for continuous channels.

Table 8. Validation of value-type inference against path-derived semantic labels for all channel instances.

Semantic label	Boolean	Enum.	Counter	Float	String	Agreement
State (alarm, status, mode)	384	892	16	14	0	97.7%
Continuous (physical quantity)	629	61	50	4062	6	84.5%
Counter (run hours, totals)	364	45	26	26	0	5.6%
Unlabelled	367	89	37	542	4	–

The disagreements fall into three groups, and their consequence for transmission differs. First, 629 channels named after a physical quantity are interpreted as boolean. Of these, 313 are constant over the whole trace and 308 take only two values in the recorded stream, for example, a generator-engine turbocharger speed or a cylinder combustion pressure that takes only two distinct values over the whole export. These channels receive the lossless change-plus-heartbeat rule of boolean channels, so the misclassification costs some heartbeat traffic but cannot introduce reconstruction error. Second, most channels whose name refers to run hours take only two values in the recorded export and are therefore interpreted as boolean, which again leads to lossless treatment. Conversely, 16 channels with a Mode suffix for a run-hour branch, for example, /Engine/GeneratorEngine1/RunHourGas/Mode, carry several thousand monotonically increasing values and are correctly interpreted as counters even though their last path element suggests a state. Counter and float channels receive the same deadband rule in P6, so confusion between these two types does not change the transmitted stream. Third, 30 of the 1306 state-labelled channels (2.3%) are interpreted as float or counter and would be deadband-coded. For integer state codes, a change of one code unit exceeds the deadband whenever the channel scale is below 100 code units for the 1% threshold, so a transition is still transmitted, but this group is the one in which a metadata-based override is needed. Counters that reset after maintenance or rollover are covered by the monotonicity threshold of 0.95. Of the 129 inferred counters, 116 contain at least one decrease and 29 have a monotonicity score below 0.99, and their reconstruction is evaluated in Section 4.7.

Temporal behaviour was then profiled using the metrics in Table 9. All temporal metrics were computed over consecutive non-null observations rather than over the full timestamp grid. This prevented sensors with sparse but valid reporting from being misclassified as unstable simply because they contain many null grid positions.

Table 9. Temporal-behaviour profiling metrics.

Metric	Definition	Interpretation
ZCR	Fraction of consecutive non-null pairs with no value change	Exact repeat stability
Unique Ratio (UR)	Number of unique non-null values divided by non-null count	Value diversity
DSR	Fraction of consecutive changes below a relative threshold	Engineering-level stability
Run-length p50/p95	Percentiles of contiguous identical-value runs	Duration of unchanged states
Monotonicity score	Fraction of non-null differences that are non-negative	Counter-like behaviour
Null ratio	Fraction of grid steps that are null after cleanup	Reporting sparsity
Sentinel ratio	Fraction of grid steps removed as sentinels	Export-quality diagnostic

For floating-point and counter channels, the DSR was computed at five relative thresholds of 0.1%, 0.5%, 1%, 2%, and 5% of an engineering scale. Let $x_{i,t}$ denote the cleaned value of channel i at grid step t, and let $|x_i|$ denote the absolute values of its valid samples. For channel i, the scale is

$$s_i=\max \left(\mathrm{median}\left(\right|x_i\left|\right),P_{95}\left(\right|x_i\left|\right),{10}^{-9}\right),$$

(1)

where $\mathrm{median}(·)$ and $P_{95}(·)$ denote the median and the 95th percentile, and the constant ${10}^{-9}$ prevents division by zero for channels whose cleaned values are all zero or extremely close to zero. The same scale $s_i$ is used for both deadband triggering and NRMSE normalisation, so the reported errors should be interpreted as errors relative to the channel’s observed operational scale rather than relative to a manufacturer-specified physical range. With $x_{i,\left(1\right)},\dots ,x_{i,\left(n_i\right)}$ the $n_i$ valid samples of channel i in time order, the ZCR and the DSR at a relative threshold $\epsilon$ are

$${\mathrm{ZCR}}_i={\displaystyle \frac{\left|\{k:x_{i,\left(k\right)}=x_{i,(k-1)}\}\right|}{n_i-1}},{\mathrm{DSR}}_i\left(\epsilon \right)={\displaystyle \frac{\left|\{k:|x_{i,\left(k\right)}-x_{i,(k-1)}|<\epsilon s_i\}\right|}{n_i-1}},$$

(2)

where $k=2,\dots ,n_i$ and $|·|$ applied to a set denotes its number of elements.

3.4. Transmission Policies

Seven transmission policies were evaluated, as shown in Table 10. The policies are designed to separate three mechanisms, namely, full transmission, byte-level compression, and change-aware record suppression. P0 sends every valid non-null sample and serves as the full-transmission baseline. P1 applies gzip compression to the same records as P0, thereby isolating byte-level compression from record reduction. P2 sends only exact changes. P3 adds heartbeat messages to change-only transmission to bound receiver-side staleness. P4 sends floating-point and counter values only when a deadband threshold is exceeded or when a heartbeat interval elapses. P5 adds a spike exception to the deadband policy. P6 applies different policies according to value type and temporal behaviour. Pseudocode for all policies, including the initialisation of the policy state, is given in Appendix B.

Table 10. Evaluated transmission policies.

Code	Name	Description
P0	Full transmission	Send every valid non-null grid value
P1	Full + gzip	Same send mask as P0, compressed with gzip
P2	Exact change-only	Send only when the current value differs from the last sent value
P3	Change + heartbeat	P2 plus periodic heartbeat to bound staleness
P4	Deadband + heartbeat	Send numeric values when deadband or heartbeat condition is met
P5	Spike-aware deadband	P4 plus mandatory sending of large step changes; evaluated with base deadbands of 0.5%, 2%, and 5%
P6	Type-and-behaviour adaptive	Select policy by value type and temporal profile

For P3, the heartbeat interval is set to 60 grid steps for boolean and enumeration channels and to 240 grid steps for numeric channels. Heartbeats are counted in grid steps, so their elapsed duration depends on the vessel’s sampling interval. With the median intervals of Table 5, the 60-step heartbeat corresponds to 8, 15, 12, 49, and 60 min, and the 240-step heartbeat to 0.53, 1.0, 0.8, 3.3, and 4.0 h for V1–V5. All currentness results are therefore reported in elapsed time per vessel as well as in grid steps (Section 4.6). For P4, the deadband thresholds are 0.1%, 0.5%, 1%, 2%, and 5% of the channel scale, applied with the 240-step numeric heartbeat. For P6, boolean and enumeration channels use change plus the 60-step heartbeat. Floating-point and counter channels are assigned deadband thresholds according to their ZCR, with the 240-step heartbeat. High-ZCR channels with ZCR above 0.9 receive a 1% deadband, medium-ZCR channels with 0.5 < ZCR ≤ 0.9 receive 0.5%, and low-ZCR channels with ZCR ≤ 0.5 receive 0.1%.

Formally, let ${\tilde{x}}_{i,t}$ be the last value of channel i transmitted before step t, and let $t_i^{\ast }$ be the step at which it was transmitted. With a deadband fraction $\epsilon$ and a heartbeat interval h in grid steps, P4 transmits a valid sample $x_{i,t}$ when

$$|x_{i,t}-{\tilde{x}}_{i,t}|>\epsilon s_i\mathrm{or}t-t_i^{\ast }\ge h.$$

(3)

P2 and P3 are the special cases $\epsilon =0$ without and with a heartbeat, and P5 additionally transmits $x_{i,t}$ when $|x_{i,t}-x_{i,t^{\prime }}|>\sigma s_i$, where $t^{\prime }$ is the previous valid step and $\sigma$ is the spike fraction. For boolean and enumeration channels the deadband condition becomes $x_{i,t}\ne {\tilde{x}}_{i,t}$. The first valid sample of every channel is always transmitted.

P5 sends a sample when the deadband or heartbeat condition of P4 is met, or when the step from the previous valid sample exceeds a spike threshold $\sigma$, here 5% of scale. Whether the spike exception adds anything depends on the base deadband. After every valid sample, a deadband policy with LOCF reconstruction keeps the receiver value within $\epsilon s_i$ of that sample because otherwise the sample would have been sent. A step larger than $\sigma s_i$ therefore moves the new sample at least $(\sigma -\epsilon )s_i$ away from the receiver value, and whenever $\sigma >2\epsilon$ the deadband condition already fires. The spike exception can only add transmissions when $\epsilon \ge \sigma /2$. P5 was therefore evaluated with base deadbands of 0.5% and 2%, below this bound, and 5%, above it, where the spike exception becomes operative.

The deadband ladder spans two orders of magnitude so that the threshold can be selected from the resulting curve (Section 4.4) rather than fixed in advance. The lower end is set by the export resolution of the data. The smallest non-zero step of a float channel is 0.10% of its scale at the median and 0.22% at the upper quartile, so a 0.1% deadband is close to the quantisation step and suppresses mainly repeated or last-digit changes. The upper end, 5%, equals the spike threshold and is where step recall starts to fall. On V1, for a main-engine exhaust-gas temperature, whose recorded resolution is 0.28% of scale, deadbands of 0.5% and 1% correspond to about two and four resolution steps, and for the SOG, whose resolution is 0.56% of scale, to about one and two steps. The P6 assignment uses the wider 1% deadband only where ZCR exceeds 0.9, that is, where the channel repeats its value in more than 90% of consecutive samples and the deadband rarely truncates genuine variation, and uses the tightest 0.1% threshold for low-ZCR channels, where a wide deadband would produce the largest reconstruction error. For a specific deployment the thresholds can be replaced by the measurement uncertainty or alarm hysteresis of each instrument when that information is available from ISO 19848 data-channel properties or vendor documentation.

P6 does not optimise thresholds per channel. It applies a simple reproducible rule that selects the transmission policy from the channel’s measured value type and temporal behaviour, which keeps the policy lightweight enough for a shipboard gateway.

3.5. Receiver-Side Reconstruction

For each policy, the receiver reconstructs the full per-vessel sampling grid from the transmitted samples. The default reconstruction method is LOCF. After the receiver obtains a value, it holds that value until the next value for the same channel is received. LOCF matches the semantics of many operational monitoring systems, in which the latest received sensor value is the current state until updated.

For boolean and enumeration channels, LOCF preserves state semantics when all transitions are transmitted. For counters, reconstruction was evaluated against the transmitted checkpoints or changes. For continuously varying floating-point channels, LOCF is used for three reasons. First, it is causal. The receiver can display a held value as soon as a record arrives, whereas linear interpolation (LERP) between two received samples cannot be computed until the next sample arrives, which for a heartbeat-bounded deadband can be up to one heartbeat interval later. Second, it inherits a hard error bound from the deadband. At every valid step the LOCF value differs from the recorded value by at most $\epsilon s_i$, except at steps between a dropped or delayed record and its successor, while interpolation has no such bound across a step change. Third, it is the receiver behaviour assumed by OPC UA data-change subscriptions and by historian exception reporting [29,30]. LERP was evaluated as an alternative in Appendix A, and representative reconstructed series are shown in Section 4.3.

3.6. Evaluation Metrics

The policies were evaluated using communication metrics and SQuaRE-inspired data-quality metrics. Communication metrics quantify the reduction in transmitted records and bytes. Data-quality metrics quantify how well the receiver-side reconstructed stream preserves the original sampled stream.

Let $x_{i,t}$ be the original cleaned value of channel i at grid step $t\in \{1,\dots ,T\}$, let ${\widehat{x}}_{i,t}$ be the receiver-side reconstructed value under a given policy, let ${\mathcal{V}}_i\subseteq \{1,\dots ,T\}$ be the set of grid steps at which channel i has a valid non-null sample after sentinel cleanup, and let ${\mathcal{S}}_i\subseteq {\mathcal{V}}_i$ be the set of steps at which the policy transmits a record. Each transmitted record is charged $b=24$ bytes in the logical accounting model. Let ${\tau }_t$ be the recorded timestamp of grid step t in seconds. For a set, $|·|$ denotes its number of elements and ∖ the set difference, and $P_{95}{(·)}_{t\in {\mathcal{V}}_i}$ denotes the P95 over the valid steps. Table 11 summarises the notation.

Table 11. Notation used in Section 3.3, Section 3.4, Section 3.5 and Section 3.6.

Symbol	Meaning
i, t, T	Channel index, grid step, number of grid steps of a vessel
$x_{i,t}$, ${\widehat{x}}_{i,t}$	Cleaned recorded value and receiver-side reconstructed value
${\tilde{x}}_{i,t}$, $t_i^{*}$	Last transmitted value before step t and the step of that transmission
${\tau }_t$	Recorded timestamp of grid step t (s)
$s_i$	Engineering scale of channel i (Equation (1))
${\mathcal{V}}_i$, ${\mathcal{S}}_i$, ${\mathcal{T}}_i$	Valid steps, transmitted steps, and state-transition steps
$\epsilon$	Deadband as a fraction of $s_i$ (0.001–0.05)
$\sigma$	Spike threshold of P5 as a fraction of $s_i$ (0.05)
h	Heartbeat interval in grid steps (60 or 240, or 15 or 60 min when time-based)
$\theta$	Step or excursion size for recall, as a fraction of $s_i$ (0.01, 0.02, 0.05)
W	Window of the windowed excursion recall in grid steps (4 or 20)
b	Logical record size (24 B)

Communication metrics. The send ratio, byte rate, and bytes saved for channel i are

$${\mathrm{SendRatio}}_i={\displaystyle \frac{|{\mathcal{S}}_i|}{T}},$$

(4)

$${\mathrm{BPSS}}_i={\displaystyle \frac{b|{\mathcal{S}}_i|}{T}},$$

(5)

$${\mathrm{BytesSaved}}_i=1-{\displaystyle \frac{|{\mathcal{S}}_i|}{|{\mathcal{V}}_i|}}.$$

(6)

The send ratio uses the full timestamp-by-channel grid as the denominator so that null or no-signal positions are not double-counted as transmitted samples, while bytes saved is referenced to the P0 logical baseline that transmits every valid sample. Because every record is charged the same 24 B, logical bytes saved and record reduction are the same quantity for P0 and P2–P6. They differ only for compressed streams. Three levels of cost are therefore kept apart in the results. Logical record reduction counts records and is what a broker, queue, or ingestion service handles. Compressed payload size is measured by serialising the records of each policy into the same text format and passing them through the same codec (Section 4.5). Network overhead, such as per-message headers, topic strings, and Transport Layer Security (TLS) records, is not measured and is discussed qualitatively. The results are reported per channel and then averaged within each vessel, which is the convention of all tables unless stated otherwise. For the whole-stream comparison (Section 4.2), the records of all channels of a vessel are pooled, $1-{\sum }_i|{\mathcal{S}}_i|/{\sum }_i\left|{\mathcal{V}}_i\right|$, so that channels with many valid samples carry proportionally more weight. The 24-byte record model is a logical record-accounting baseline used to compare policies under identical assumptions and should not be interpreted as a packet-level wire-size estimate. Real transport will add per-message protocol headers, topic strings or identifiers, batching framing, and TLS overhead, all of which shift absolute byte counts but not the relative ordering of policies that differ in record count.

Accuracy. Accuracy is measured by RMSE, NRMSE, and the P95 absolute error between the original and reconstructed streams. For channel i, with $s_i$ the engineering scale from Equation (1), these are

$${\mathrm{RMSE}}_i=\sqrt{{\displaystyle \frac{1}{|{\mathcal{V}}_i|}}\sum _{t\in {\mathcal{V}}_i}{({\widehat{x}}_{i,t}-x_{i,t})}^2},$$

(7)

$${\mathrm{NRMSE}}_i={\displaystyle \frac{{\mathrm{RMSE}}_i}{s_i}},$$

(8)

$$\mathrm{P}95{\mathrm{Err}}_i=P_{95}{\left(|{\widehat{x}}_{i,t}-x_{i,t}|\right)}_{t\in {\mathcal{V}}_i}.$$

(9)

RMSE and P95 error are also reported in the recorded engineering unit for representative channels (Section 4.3).

Completeness. For boolean and enumeration channels, let ${\mathcal{T}}_i=\{t\in {\mathcal{V}}_i:x_{i,t}\ne x_{i,t-1}\}$ be the set of state-transition steps. The event miss ratio is the fraction of those transitions whose grid step was not transmitted,

$${\mathrm{EventMiss}}_i={\displaystyle \frac{|{\mathcal{T}}_i\setminus {\mathcal{S}}_i|}{|{\mathcal{T}}_i|}}.$$

(10)

For numeric channels, the step recall at threshold $\theta$, a step size expressed as a fraction of $s_i$, is defined per channel i as

$${\mathrm{StepRecall}}_i\left(\theta \right)={\displaystyle \frac{\left|\left\{t:|x_{i,t}-x_{i,t-1}|>\theta s_i\mathrm{and}t\in {\mathcal{S}}_i\right\}\right|}{\left|\left\{t:|x_{i,t}-x_{i,t-1}|>\theta s_i\right\}\right|}}.$$

(11)

The spike recall used below is ${\mathrm{StepRecall}}_i\left(0.05\right)$. Because a 5% step exceeds every deadband below 2.5% by the argument of Section 3.4, its value is one by construction for those deadbands, so the step recall is also reported at $\theta =1\%$ and $2\%$, which are comparable to or smaller than the evaluated deadbands. To cover gradual excursions that build up over several samples, the windowed excursion recall counts every step t with $|x_{i,t}-x_{i,t-W}|>\theta s_i$ and treats it as detected if the receiver series shows a change of the same size, $|{\widehat{x}}_{i,u}-{\widehat{x}}_{i,u-W}|>\theta s_i$, for some step u within the W steps that follow t, that is, $u\in [t,t+W]$,

$${\mathrm{WinRecall}}_i(W,\theta )={\displaystyle \frac{\left|\{t:|x_{i,t}-x_{i,t-W}|>\theta s_i,\exists u\in [t,t+W]:|{\widehat{x}}_{i,u}-{\widehat{x}}_{i,u-W}|>\theta s_i\}\right|}{\left|\{t:|x_{i,t}-x_{i,t-W}|>\theta s_i\}\right|}},$$

(12)

with $\theta =5\%$ and $W\in \{4,20\}$ grid steps. A receiver-side monitor that applies the same rate-of-change threshold over the same window would therefore raise the same alert within W steps. Events shorter than the sampling interval are not represented in the recorded stream and cannot be evaluated from it. Completeness for lost and reordered records was evaluated separately (Section 4.8).

Currentness. Currentness is the age of the receiver-side value at the moments when a fresh value exists on board. At every valid step $t\in {\mathcal{V}}_i$, the age is measured both in grid steps and in elapsed time from the recorded timestamps,

$${\mathrm{Age}}_{i,t}=t-r_{i,t},{\mathrm{AgeSec}}_{i,t}={\tau }_t-{\tau }_{r_{i,t}},r_{i,t}=\max \{r\in {\mathcal{S}}_i:r\le t\},$$

(13)

$$\mathrm{P}95{\mathrm{Stale}}_i=P_{95}{\left({\mathrm{Age}}_{i,t}\right)}_{t\in {\mathcal{V}}_i},$$

(14)

and analogously for the elapsed-time age. For P0 the age is zero at every valid step, so the reported values are the staleness added by the policy.

Consistency. Aggregate mean relative error between the reconstructed and original streams serves as a proxy for preserving fuel- and energy-aggregate evidence,

$${\mathrm{AggErr}}_i={\displaystyle \frac{\left|{\overline{\widehat{x}}}_i-{\overline{x}}_i\right|}{s_i}},$$

(15)

where ${\overline{x}}_i$ and ${\overline{\widehat{x}}}_i$ are the means of $x_{i,t}$ and ${\widehat{x}}_{i,t}$ over ${\mathcal{V}}_i$. The cumulative-sum error normalised by $|{\mathcal{V}}_i|s_i$, is algebraically identical to ${\mathrm{AggErr}}_i$ and is therefore not reported separately. Hourly aggregates of compliance-relevant channels and counter monotonicity are evaluated in Section 4.7.

Transport perturbations. The P6 record stream, and for reference the P0 stream, is replayed under two disturbance conditions. In the first, 1% of records are dropped independently at random. In the second, every record is delayed by an integer number of grid steps drawn uniformly from 0 to 8, so records can arrive out of order within an eight-step window. The receiver either applies records in arrival order, which is plain LOCF, or keeps a per-channel sequence number, here the source step, and discards any record older than the one already applied. The same random draws are used for all channels and policies of a vessel. Table 12 summarises the metrics by data-quality characteristic.

Table 12. Evaluation metrics by SQuaRE characteristic.

Data-Quality Characteristic	Operational Metric	Purpose
Efficiency	Bytes saved, records sent, same-format compressed bytes	Communication and processing reduction
Accuracy	RMSE, NRMSE, P95 absolute error	Reconstruction fidelity
Completeness	Event miss ratio, step recall at 1, 2, 5%, windowed excursion recall	Preservation of required changes
Currentness	P95 and maximum staleness in steps and seconds	Freshness of receiver-side values
Consistency	Aggregate mean error, hourly key performance indicator (KPI) error, counter violations	Preservation of aggregate behaviour

3.7. Data-Quality Acceptance Profiles

To make the efficiency–quality balance explicit, three acceptance profiles are defined for typical shore-side services (Table 13). The thresholds follow common engineering practice, namely, an error well inside the deadband ladder, no lost state transitions, an alert-preserving excursion recall, and staleness of the order of the heartbeat. A policy is accepted for a service on a vessel when at least 95% of the relevant channels satisfy every criterion of the profile. The preferred policy for that service is the accepted policy with the fewest transmitted records. Other thresholds can be substituted for a given service, and the same procedure then selects the operating point.

Table 13. Data-quality acceptance profiles used to select an operating point.

Profile (Service)	Channels	Acceptance Criteria (Per Channel)
A: Alarm and state monitoring	Boolean, enumeration	Event miss $=0$; P95 staleness $\le 15$ min
B: Condition-monitoring dashboard	Float, counter	NRMSE $\le 0.5\%$; P95 error $\le 1\%$ of scale; StepRecall(5%) $\ge 0.99$; WinRecall(20, 5%) $\ge 0.95$; P95 staleness $\le 60$ min
C: Aggregate and compliance evidence	Float, counter	AggErr $\le 0.1\%$ of scale; NRMSE $\le 1\%$

3.8. Cross-Vessel Aggregation

All policy metrics were first computed per channel and then aggregated within each vessel. Cross-vessel results are reported as the mean and standard deviation over the five vessel-level aggregates. This aggregation strategy prevents vessels with more rows or more channels from dominating the overall result.

Two predefined go criteria were used to determine whether the dataset contains enough quasi-constant behaviour to justify change-aware transmission analysis. First, at least 40% of channels in each vessel should have a ZCR above 0.9. Second, at least 30% of floating-point channels should have a 0.5% DSR above 0.9. These thresholds are not used to tune policies. They are used only to confirm that repeatedly sampled but slowly changing data are sufficiently common across vessels.

Sensitivity analysis was conducted for the deadband threshold by evaluating 0.1%, 0.5%, 1%, 2%, and 5% thresholds. The purpose is to avoid presenting a single arbitrary threshold as universally optimal. Instead, this paper reports the trade-off curve between traffic reduction, reconstruction error, and spike recall. In addition, the heartbeat interval is swept over 4, 20, 60, and 240 steps for boolean and enumeration channels and over 20, 60, 240, and 960 steps for P6 on numeric channels. The results are split by operating phase, using GPS SOG of at least 3 kn as underway and below 3 kn as not underway, and by the null ratio of each channel.

3.9. Implementation

The analysis pipeline was implemented in Python using Polars for columnar data loading and processing, with Numba used for state-propagating loops such as policy simulation and reconstruction. Each vessel was processed in column batches to control memory usage. The profiling stage produces one row per channel, while the policy stage produces one result row per channel-policy combination. All analyses were run on a desktop computer with an AMD Ryzen 7 9800X3D eight-core processor, 32 GB of DDR5-5600 memory, and Windows 11 Education version 10.0.26200, using Python 3.10.6, Polars 1.41.0, Numba 0.65.1, NumPy 2.2.5, zstandard 0.25.0, and the gzip module of the Python standard library. Each vessel was processed as in-memory column batches of 100 to 200 channels read from the Parquet file. The policies were evaluated offline on the stored traces, while the gateway benchmark of Section 4.9 evaluated P6 step by step as a streaming gateway would. The random draws of the stratified samples and of the perturbation experiments used the fixed seeds 20260525 and 20261016. Pseudocode of the policies is given in Appendix B, and pseudocode of the cleanup, profiling, reconstruction, metrics, and perturbation procedures in Appendix C.

All vessels were processed through the same sequence of sentinel cleanup, type inference, temporal profiling, policy simulation, reconstruction, metric calculation, and vessel-level aggregation. Cross-vessel differences therefore reflect the data rather than the implementation.

4. Results

Table 14 summarises the main findings, and the following subsections develop each row. Unless a subset is named, every value refers to the whole channel population to which a policy applies, and values are per-channel means within a vessel averaged over the five vessels and reported as the mean and standard deviation.

Table 14. Headline results of the evaluation.

Metric	Headline Value
Channel profile (Section 4.1)
ZCR > 0.9 fraction per vessel	42.6–59.7%
DSR(0.5%) > 0.9 fraction (float) per vessel	49.2–77.5%
Whole-stream comparison, all channels (Section 4.2)
P1 gzip, bytes saved/records saved	86.0 ± 0.3% (pooled 85.9%)/0%
P2 change-only (lossless), bytes and records saved	71.0 ± 5.6% (pooled 70.7%)
P6 adaptive, bytes and records saved	82.8 ± 4.0% (pooled 82.8%)
Float channels, P6 adaptive (Section 4.3)
All float channels: bytes saved, NRMSE	73.9 ± 5.2%, 0.0008
ZCR > 0.9 subset only: bytes saved, NRMSE	98.7 ± 0.4%, 0.0012
Deadband and P5 on float channels (Section 4.4)
P4 bytes saved over 0.5–5% deadband	84.6–95.8%
Step recall (5% step) at 5% deadband: P4/P5	0.882/1.000
Same-format compression, V1 sample (Section 4.5)
zstd bytes: P0/P6/P4 1%	563/169/93 MB
Currentness and acceptance (Section 4.6 and Section 4.10)
P95 staleness of P6 float channels, 240-step heartbeat	29–178 min (209 steps)
Policy accepted for profiles A/B/C on all vessels	P6, time-based heartbeat/P6, time-based heartbeat/P4 1%

4.1. Channel Inventory and Temporal Stability

Table 15 reports the per-vessel value-type inventory and the two go-criterion metrics after sentinel cleanup, and Figure 2 compares the latter with the go criteria. Float DSR is at 0.5% of engineering scale. The four timestamp and metadata columns are excluded from the totals.

Table 15. Per-vessel value-type inventory and stability after sentinel cleanup.

Vessel	Total	Float	Cnt.	Bool.	Enum	Str.	ZCR > 0.9	DSR0.5% > 0.9
V1	1296	701	21	280	294	0	55.6%	72.8%
V2	1293	663	13	317	292	6	59.7%	77.5%
V3	1295	906	19	39	331	0	45.3%	73.7%
V4	1866	1182	41	561	80	2	42.6%	49.2%
V5	1866	1192	35	547	90	2	44.3%	56.0%

Figure 2. Per-vessel stability profile against the two go criteria.

All five vessels pass both predefined criteria. The ZCR > 0.9 fraction is in the 42–60% range, well above the 40% threshold. The float DSR(0.5%) > 0.9 fraction is in the 49–78% range, well above the 30% threshold. Boolean channels are 99.6–100% stable and enumeration channels are 90.9–100% stable in every vessel after sentinel cleanup. The recorded shipboard stream is therefore dominated by exact repeats, quasi-static signals, and slowly varying floats whose update value does not differ meaningfully from the previously sent value.

The number of float channels differs across vessels from 663 to 1192. The two vessels with the largest channel inventories, V4 and V5, have the lowest stability rates, while V2, with the smallest float inventory, has the highest. The variation does not invalidate the framing. Even the lowest-stability vessel V4, at 49.2% float DSR(0.5%) above 0.9, is well above the threshold.

Table 16 reports the per-vessel null and sentinel diagnostics as dimensionless fractions in $[0,1]$, giving the mean and P95 across channels. Because ZCR and DSR were computed over consecutive non-null observations (Section 3.3), a channel with a high null ratio may appear stable simply because it reports infrequently. The diagnostics show that null and sentinel ratios vary across vessels but are below 50% on average for every vessel. Stability conclusions in the next subsections should therefore be read together with the channel’s reporting sparsity rather than as claims about the underlying physical process.

Table 16. Per-vessel null and sentinel ratios.

Vessel	Mean Null Ratio	P95 Null Ratio	Mean Sentinel Ratio	P95 Sentinel Ratio
V1	0.489	0.494	0.382	0.387
V2	0.242	0.441	0.124	0.324
V3	0.389	0.395	0.120	0.124
V4	0.422	0.505	0.422	0.505
V5	0.292	0.501	0.292	0.501

Table 17 tests whether the missing-data level drives the stability or the policy results. Float channels are grouped by their null ratio after sentinel cleanup. Most channels fall in the 25–50% stratum because on several vessels most channels are written only on part of the grid rows. Across the strata, the P6 bytes saved range from 69.7 to 76.4% without a monotonic trend, and the P6 NRMSE stays between 0.0005 and 0.0009, decreasing slightly as the null ratio increases. The rank correlation between the null ratio and P6 bytes saved is −0.05, and between the null ratio and P6 NRMSE −0.02. The fraction of channels with ZCR above 0.9 is highest in the least-missing stratum, which indicates that missing data do not make channels look artificially stable in this dataset. The extreme strata contain few channels and are reported for completeness rather than as stable estimates.

Table 17. Float-channel stability and policy results by null-ratio stratum over all vessels.

Null Ratio	Channels	ZCR > 0.9	DSR0.5% > 0.9	P6 Saved	P6 NRMSE	P4 1% Saved	P4 1% NRMSE
0–25%	921	26.4%	71.0%	76.4%	0.0009	88.9%	0.0023
25–50%	3616	14.5%	62.3%	71.8%	0.0008	88.4%	0.0025
50–75%	81	17.3%	32.1%	73.6%	0.0006	81.8%	0.0019
75–100%	26	19.2%	42.3%	69.7%	0.0005	79.4%	0.0020

Table 18 splits the float-channel results by operating phase. Both P4 and P6 save more records when the vessel is not underway because machinery and navigation channels are more often idle in port or at anchor, but the reconstruction error is almost unchanged between the phases. The policies therefore do not trade accuracy for savings when operating conditions change. They only send more records when the signals are more active, which is the intended behaviour of a change-aware rule.

Table 18. Float-channel results by operating phase averaged over the five vessels.

	Bytes Saved		NRMSE
Policy	Underway	Not Underway	Underway	Not Underway
P4 deadband 1%	87.9 ± 3.8%	92.3 ± 2.6%	0.0024	0.0023
P6 adaptive	71.7 ± 6.1%	79.8 ± 3.9%	0.0008	0.0008

4.2. Cross-Vessel Policy Comparison

Table 19 reports the cross-vessel policy comparison. Each row is the mean and standard deviation across the five vessels of the per-vessel mean of that metric, and n is the number of channel instances. The send ratio is the fraction of grid positions the policy transmits. Bytes saved is one minus the policy’s transmitted bytes divided by the P0 logical-record baseline at 24 B per record. Event miss is defined only for boolean and enumeration channels, while spike recall, the step recall at 5%, is defined only for numeric channels. The send ratio, event miss, and spike recall are dimensionless fractions in $[0,1]$, and NRMSE is reported relative to the engineering scale $s_i$ defined in Equation (1). P6 is reported for all numeric channels to which it applies, together with the row of its 1% sub-rule, which covers the high-ZCR float channels. Figure 3 shows the bytes saved with the standard deviation over the vessels, and its light bar is P6 restricted to the high-ZCR float channels.

Table 19. Mean and standard deviation of the policy metrics across the five vessels.

Policy	n	Send Ratio	Bytes Saved (%)	NRMSE	Event Miss	Spike Recall
P0 full	7614	0.633 ± 0.089	0.0 ± 0.0	0.0000	0	1.000
P1 full + gzip (per-channel JSON)	7614	0.633 ± 0.089	86.0 ± 0.3	0.0000	0	1.000
P2 change-only (lossless)	7614	0.185 ± 0.040	71.0 ± 5.6	0.0000	0	1.000
P3 event/state, 60-step heartbeat	2831	0.018 ± 0.005	97.1 ± 0.9	–	0	–
P3 numeric, 240-step heartbeat	4783	0.297 ± 0.056	53.7 ± 6.1	0.0000	0	1.000
P4 deadband 0.1%	4773	0.203 ± 0.033	68.2 ± 3.0	0.0001	–	1.000
P4 deadband 0.5%	4773	0.096 ± 0.027	84.9 ± 4.1	0.0013	–	1.000
P4 deadband 1%	4773	0.068 ± 0.022	89.3 ± 3.3	0.0024	–	1.000
P4 deadband 2%	4773	0.046 ± 0.016	92.8 ± 2.5	0.0041	–	1.000
P4 deadband 5%	4773	0.026 ± 0.010	95.9 ± 1.5	0.0078	–	0.885
P6 adaptive, numeric (all)	4773	0.163 ± 0.036	74.4 ± 5.1	0.0008	–	1.000
of which float, ZCR > 0.9 subset	786	0.008 ± 0.002	98.7 ± 0.4	0.0012	–	1.000
P6 adaptive, boolean	1744	0.015 ± 0.001	97.5 ± 0.4	–	0	–
P6 adaptive, enumeration and string	1097	0.026 ± 0.006	95.8 ± 0.9	–	0	–

Figure 3. Cross-vessel bytes saved by policy.

P1 gzip in Table 19 and Table 20 compresses a per-channel JSON array of all valid records and is compared with the 24-byte logical record count of P0. Its bytes saved therefore combines a change of format with compression, and Section 4.5 compares all policies with the same format and codec.

Table 20. Comparison of policies on identical channel populations.

Population	Policy	n	Bytes Saved, Per-Channel Mean (%)	Bytes Saved, Pooled (%)	NRMSE
All float channels	P1 gzip	4644	83.9 ± 0.3	83.8 ± 0.3	0.0000
	P2 change-only	4644	52.8 ± 6.3	52.7 ± 6.6	0.0000
	P4 0.5%	4644	84.6 ± 4.3	84.7 ± 4.2	0.0014
	P4 1%	4644	89.1 ± 3.4	89.1 ± 3.4	0.0024
	P6 adaptive	4644	73.9 ± 5.2	73.9 ± 5.3	0.0008
All numeric channels	P1 gzip	4773	84.0 ± 0.3	84.0 ± 0.3	0.0000
	P2 change-only	4773	53.9 ± 6.1	53.8 ± 6.4	0.0000
	P4 0.5%	4773	84.9 ± 4.1	85.0 ± 4.1	0.0013
	P4 1%	4773	89.3 ± 3.3	89.4 ± 3.3	0.0024
	P6 adaptive	4773	74.4 ± 5.1	74.5 ± 5.2	0.0008
All channels (whole stream)	P1 gzip	7614	86.0 ± 0.3	85.9 ± 0.3	0.0000
	P2 change-only	7614	71.0 ± 5.6	70.7 ± 5.2	0.0000
	P6 adaptive	7614	82.8 ± 4.0	82.8 ± 3.8	0.0008

The two P3 rows should not be read as the same policy applied to the same channels. The 60-step heartbeat row applies only to boolean and enumeration channels, where the heartbeat is short and the underlying change rate is low. The 240-step heartbeat row applies only to numeric channels, where the longer heartbeat dominates the send pattern for stable signals. The different send ratios therefore reflect both heartbeat interval and channel-type composition, not a single policy evaluated using two settings.

Table 20 answers the question of which reduction applies to which population on one consistent baseline. For each population, every policy was evaluated on the same channels, and bytes saved are given both as the per-channel mean and pooled over all records of the vessel. On all channels of a vessel, P6 removes 82.8% of the records, P2 70.7%, and P1 gzip none, while P1 reduces the byte volume by 85.9%. On all float channels, P6 saves 73.9% of the bytes at an NRMSE of 0.0008, which is less than P4 at a uniform 0.5% or 1% deadband, which save 84.6% and 89.1%, but at a lower error. Savings close to 99% are confined to the high-ZCR float channels, which make up 17% of the float channel instances.

The five-vessel standard deviation of bytes saved is at most 6.1 percentage points across the reduction policies, and the relative ordering of policies is the same on every vessel.

4.3. Results by Value Type

Table 21 reports the per-value-type aggregates. Each policy row aggregates across vessels using rows = channels_per_vessel × vessels. For boolean and enumeration channels we report event miss, and for numeric channels we report NRMSE and spike recall. NRMSE is expressed relative to the engineering scale, and event miss and spike recall are fractions in $[0,1]$.

Table 21. Per value-type policy results, cross-vessel aggregate.

Type	Policy	n	Bytes Saved (%)	Error Metric	Spike Recall
Float	P6 adaptive (all float)	4644	72.7	NRMSE 0.0008	1.000
	P6 sub-rule 1% (ZCR > 0.9)	786	98.8	NRMSE 0.0012	1.000
	P6 sub-rule 0.5%	1581	90.7	NRMSE 0.0014	1.000
	P6 sub-rule 0.1%	2277	51.3	NRMSE 0.0002	1.000
	P4 deadband 2%	4644	92.1	NRMSE 0.0043	1.000
	P4 deadband 1%	4644	88.3	NRMSE 0.0024	1.000
	P4 deadband 0.5%	4644	83.7	NRMSE 0.0013	1.000
	P4 deadband 0.1%	4644	66.9	NRMSE 0.0001	1.000
	P2 change-only	4644	51.5	NRMSE 0.0000	1.000
	P1 gzip	4644	83.8	NRMSE 0.0000	1.000
Counter	P6 adaptive	129	93.3	NRMSE 0.0007	1.000
	P4 deadband 5%	129	99.1	NRMSE 0.0056	0.982
	P4 deadband 2%	129	98.5	NRMSE 0.0023	1.000
	P2 change-only	129	92.3	NRMSE 0.0000	1.000
	P1 gzip	129	88.1	NRMSE 0.0000	1.000
Boolean	P2 change-only (lossless)	1744	99.9	event miss 0	–
	P3 change + 60-step heartbeat	1744	97.6	event miss 0	–
	P1 gzip	1744	89.4	event miss 0	–
Enumeration	P2 change-only (lossless)	1087	99.2	event miss 0	–
	P3 change + 60-step heartbeat	1087	96.7	event miss 0	–
	P1 gzip	1087	89.2	event miss 0	–

For boolean and enumeration channels, change-only transmission is lossless and saves 99.9% and 99.2% of the records, and a 60-step heartbeat costs 2.4 percentage points of that saving in exchange for bounded staleness. For counter channels, change-only is lossless and the deadband variants and P6 reach NRMSE in the ${10}^{-3}$ range. For float channels, P6 combines three sub-rules. The 1% sub-rule on high-ZCR channels saves 98.8%, the 0.5% sub-rule on medium-ZCR channels 90.7%, and the 0.1% sub-rule on low-ZCR channels 51.3%. The low-ZCR channels are about half of all float channels and carry most of the records, so the P6 result on all float channels is dominated by the conservative 0.1% sub-rule.

To relate the normalised errors to engineering quantities, Table 22 lists representative channels for P6 with their physical unit. Absolute values are not reported so that the operating data remain confidential, and the errors are expressed relative to the recorded resolution, that is, the smallest non-zero change of the channel in the export, and relative to the deadband. Because the export carries no unit metadata, the units were determined from physical relations in the V1 trace rather than from the channel names. The recorded shaft power equals $2\pi /60$ times the product of shaft speed and torque, with a median ratio of 0.10472 and a correlation of $r=0.9995$ over 1.46 million running samples, so speed, torque, and power are recorded in rpm, kN m, and kW. The ratio of fuel-gas mass flow to shaft power implies a thermal efficiency of 43% at the median with a methane lower heating value of 50 MJ/kg when the flow is in kg/h, whereas t/h or kg/s would imply efficiencies below 0.1%. The SOG agrees with the speed derived from successive GPS positions to within 0.5% when both are expressed in knots. The cargo tank pressure equals the difference between the absolute vapour-header pressure and the atmospheric pressure, both recorded in hPa, with a slope of 0.99 and $r=0.998$, so it is a gauge pressure in mbar. Finally, the condensate liquid header reaches $-160.8$, the boiling temperature of LNG in degrees Celsius, which fixes the temperature convention of the data server. The same relations hold on V2 and V4, with power-to-speed-times-torque ratios of 0.10473 and 0.10483, implied thermal efficiencies of 44.6% and 43.9%, and minimum condensate-header temperatures of $-161.4$ and $-155.0$. For channels recorded with a coarse resolution, the error is of the order of one resolution step. The median RMSE of the main-engine exhaust-gas outlet temperatures is 0.66 resolution steps, with a P95 error of 1.0 step, and that of the SOG is 0.54 steps. For finely resolved channels such as the shaft speed, the error is set by the deadband rather than by the resolution, and in every group the P95 error stays below 0.87 of the deadband. In both cases the error remains below the variation that an operator would act on in condition monitoring. Figure 4 shows reconstructed series for a six-hour window on V1 that contains an engine start-up and departure, with values divided by the channel scale and dots marking the transmitted records. During the steady and idle periods, P6 sends almost nothing. During the transient it sends almost every sample so that the LOCF series follows the ramp. LERP lies close to LOCF on the ramp but deviates from it ahead of each step because it anticipates a change that has not yet happened.

Table 22. Normalised reconstruction errors of representative channels with P6.

Channel Group	Channels	Unit	Resolution	Deadband	Saved	NRMSE	RMSE/Resolution	P95 Error/Deadband
Main-engine exhaust-gas outlet temperature	50	°C	0.27%	0.5/1%	94.7%	0.177%	0.66	0.53
Main-engine air-cooler water outlet temperature	10	°C	0.12%	0.1/0.5%	89.6%	0.183%	1.06	0.79
Cargo tank pressure	20	mbar (gauge)	0.0094%	0.1%	66.7%	0.042%	4.47	0.87
Propeller shaft speed	10	rpm	0.0015%	0.1/0.5/1%	66.2%	0.020%	13.88	0.57
Propeller shaft power	10	kW	0.012%	0.1%	41.6%	0.016%	1.34	0.37
Main-engine fuel-gas mass flow	10	kg/h	0.01%	0.1/0.5%	40.0%	0.014%	1.39	0.16
SOG	5	kn	0.054%	0.1/0.5%	72.2%	0.029%	0.54	0.32

Figure 4. Recorded and receiver-side series of three V1 channels for P6: (a) main-engine exhaust-gas outlet temperature, (b) speed over ground, and (c) cargo tank pressure.

4.4. Deadband Sensitivity and Spike-Aware Deadband

Table 23 reports the float-channel deadband sweep. The 240-step numeric heartbeat is applied in all cases. NRMSE and P95 absolute error are reported relative to the engineering scale $s_i$, and recall values are fractions in $[0,1]$. Besides the 5% step recall, the table gives the step recall at 1% and 2%, the windowed excursion recall, and the three P5 settings.

Table 23. Deadband sensitivity and spike-aware deadband for float channels.

				Step Recall			Windowed Recall, 5%
Policy	Saved (%)	NRMSE	P95 Err.	1%	2%	5%	W = 4	W = 20
P4 deadband 0.5%	84.6	0.0014	0.0028	1.000	1.000	1.000	0.993	0.991
P4 deadband 1%	89.1	0.0024	0.0053	0.904	1.000	1.000	0.975	0.979
P4 deadband 2%	92.6	0.0042	0.0091	0.543	0.897	1.000	0.946	0.944
P4 deadband 5%	95.8	0.0079	0.0168	0.291	0.461	0.882	0.926	0.953
P5 0.5% + spike 5%	84.6	0.0014	0.0028	1.000	1.000	1.000	0.993	0.991
P5 2% + spike 5%	92.6	0.0042	0.0091	0.543	0.897	1.000	0.946	0.944
P5 5% + spike 5%	95.6	0.0079	0.0168	0.301	0.483	1.000	0.939	0.959
P6 adaptive	73.9	0.0008	0.0017	0.996	1.000	1.000	0.997	0.995

The curve in Figure 5 is monotonic and smooth. NRMSE rises near-linearly with the deadband threshold and remains below the deadband itself, which is the expected behaviour of a deadband-quantised LOCF reconstruction. The 5% step recall is 1.000 for deadbands up to 2% because of the structural argument of Section 3.4, so it says little about excursion preservation. The more informative indicators are the step recall at smaller steps and the windowed recall. Step recall at a 1% step falls from 1.000 at a 0.5% deadband to 0.291 at 5%, that is, small but sudden changes are increasingly absorbed into the deadband. The windowed recall over 20 steps stays at or above 0.944 for every deadband, so gradual excursions of 5% of scale remain visible at the receiver even when individual steps are suppressed.

Figure 5. Deadband sensitivity for float channels: bytes saved, step and windowed recall (top) and reconstruction error (bottom).

The P5 rows confirm the structural argument. With base deadbands of 0.5% and 2%, P5 transmits exactly the same records as P4 on every channel. With a 5% base deadband, the spike exception adds 12.40 million records on 60% of the float channels, restores the 5% step recall from 0.882 to 1.000, and costs 0.3 percentage points of bytes saved. A spike-aware deadband is therefore useful as a way to run a wide deadband for quasi-static channels while still catching abrupt changes, not as a refinement of a narrow deadband.

The sensitivity curve recasts the choice from “which deadband?” to “which point on the curve is acceptable?”. Against profile B of Table 13, the error criteria alone are met for most channels up to a 1% deadband, and Section 4.10 shows which criterion binds.

4.5. Combined Compression and Change-Aware Transmission

To compare compression and record suppression on equal terms, the records sent by each policy are serialised into the same line-oriented step,channel,value text format and compressed with the same stream-mode gzip compressor at level 6 and zstd compressor at level 3, with identical settings for all policies including P0. Table 24 reports the result on stratified channel samples of 149 channels for V1, 150 channels for V4, 150 channels for V5. The serialised P0 text is 20.6 GB for the V1 sample, so the 24-byte logical model of Section 3.6 understates the uncompressed size of a text format by a factor of about three.

Table 24. Same-format, same-codec comparison of compression and change-aware transmission on stratified channel samples.

			Size (MB)			Reduction vs. P0 with Same Codec
Vessel	Policy	Records (M)	Text	gzip	zstd	gzip	zstd
V1	P0 full	266.0	20,606	910.5	562.8	–	–
	P2 change-only	63.3	4660	339.7	306.2	62.7%	45.6%
	P4 deadband 1%	19.6	1341	110.9	92.6	87.8%	83.5%
	P6 adaptive	35.1	2479	198.0	168.9	78.3%	70.0%
V4	P0 full	76.7	4995	272.5	176.9	–	–
	P2 change-only	27.8	1799	136.4	126.6	50.0%	28.4%
	P4 deadband 1%	9.0	546	46.4	46.2	83.0%	73.9%
	P6 adaptive	18.0	1172	91.1	86.6	66.6%	51.0%
V5	P0 full	89.2	5851	308.5	183.9	–	–
	P2 change-only	27.2	1657	135.7	127.1	56.0%	30.9%
	P4 deadband 1%	8.6	488	43.5	41.2	85.9%	77.6%
	P6 adaptive	15.9	925	80.4	75.7	73.9%	58.8%

Three observations follow. First, with the format and codec held fixed, compression alone reduces the V1 text stream by 95.6% with gzip and 97.3% with zstd, which is the byte-level redundancy that P1 exploits. Second, applying the same codec to the reduced streams removes a further 51–78% of the compressed bytes for P6 and 74–88% for P4 at 1%. The two mechanisms are therefore complementary and multiply because record suppression removes records that the codec would otherwise have to encode, while the codec removes redundancy within the records that remain. Third, compression shrinks the reduced streams less than the full stream because the records that remain after suppression are the less repetitive ones. Within these samples P4 at 1% sends fewer records than P6 because P6 uses tighter deadbands on low-ZCR channels in order to protect their reconstruction error. Figure 6 places the policies in the plane of bytes saved and NRMSE for all float channels, with the dashed line marking the bytes saved by P1 gzip, which leaves the number of records unchanged.

Figure 6. Efficiency–quality trade-off on float channels.

The 24-byte logical record model abstracts away protocol framing. To make the policy ordering robust to that abstraction, Table 25 summarises the expected direction in which common transport-overhead sources move the comparison. The pattern is consistent. Per-record overheads such as headers, identifiers, and TLS records penalise high-record-count streams and therefore strengthen the change-aware policies, while batch framing and binary or columnar encodings reduce absolute bytes without affecting the record-count difference. None of the listed overheads invert the ordering between P1 and P6.

Table 25. Expected sensitivity of policy ordering to common transport-overhead sources.

Overhead Source	Expected Effect	Effect on Conclusion
Per-message protocol headers	Penalises high-record-count streams	Strengthens change-aware policies
Topic strings/identifiers	Penalises per-record streaming	Strengthens record suppression
Batch framing	Reduces overhead for full streams	Narrows byte gap, not message-count gap
TLS records	Adds transport overhead	Does not alter logical record count
Binary encoding/zstd	Lowers absolute bytes	Does not remove record-generation difference

4.6. Currentness and Staleness

Table 26 reports the measured P95 staleness. For each channel the P95 of the receiver-side age over its valid steps was computed, and the table gives the median over the channels of a vessel, in grid steps averaged over the vessels and in minutes for each vessel from the recorded timestamps.

Table 26. Median measured P95 staleness over channels.

		Minutes
Policy	Grid Steps	V1	V2	V3	V4	V5
P3 numeric, 240-step heartbeat	103	16	22	23	44	80
P4 0.5%, 240-step heartbeat	217	30	54	49	184	205
P4 1%, 240-step heartbeat	223	30	56	52	197	214
P4 2%, 240-step heartbeat	226	32	56	53	208	221
P4 5%, 240-step heartbeat	227	33	56	53	214	224
P6 numeric, 240-step heartbeat	209	29	52	48	160	178
P6 numeric, time-based heartbeat (60 min)	237	53	54	54	51	52
P3 state, 60-step heartbeat	56	8	14	13	54	56
P6 state, time-based heartbeat (15 min)	68	14	14	14	14	14
P2 change-only (no heartbeat)	unbounded for static channels

Three results follow. First, under deadband policies the measured P95 staleness of float channels is below the 240-step heartbeat but close to it, at 209 steps for P6, because most stable channels are refreshed only by the heartbeat. Second, the same grid-step heartbeat gives very different elapsed staleness on different vessels, from 29 min on V1 to 178 min on V5 for P6. Third, when the heartbeat is defined in elapsed time, that is, a record is sent whenever 15 min have passed for state channels or 60 min for numeric channels since the last record according to the recorded timestamps, as in the time-based rows of the table, the staleness is bounded by the same duration on every vessel. This bound holds by construction, so the relevant result is its cost, which is reported in Table 27. Converting a duration into a fixed number of grid steps with the median sampling interval is not sufficient because the actual interval between rows varies within a trace. Change-only transmission without a heartbeat (P2) remains unsuitable as a currentness contract because a static channel can hold its initial value for the entire trace without retransmission.

Table 27. Bytes saved and median measured P95 staleness for different heartbeat intervals.

				P95 Staleness (min)
Channels	Heartbeat	Saved (%)	NRMSE	V1	V2	V3	V4	V5
Boolean, enum.	4 steps	63.6	–	0	1	1	3	3
	20 steps	92.1	–	3	4	4	18	18
	60 steps	96.9	–	8	14	13	54	56
	240 steps	98.7	–	32	56	53	216	225
	15 min (time-based)	95.6	–	14	14	14	14	14
Numeric, P6	20 steps	70.5	0.0006	2	4	4	16	17
	60 steps	73.4	0.0007	7	14	12	45	51
	240 steps	74.4	0.0008	29	52	48	160	178
	960 steps	74.7	0.0010	111	195	156	453	568
	60 min (time-based)	74.3	0.0008	53	54	54	51	52

Table 27 gives the heartbeat sweep. For state channels, shortening the heartbeat from 240 to four steps reduces bytes saved from 98.7% to 63.6%, with zero event miss throughout because transitions are always sent. For P6 on numeric channels the heartbeat costs much less. Shortening it from 960 to 20 steps changes bytes saved only from 74.7% to 70.5% because most numeric records are triggered by the deadband rather than by the heartbeat. The heartbeat can therefore be set from the currentness requirement of the receiving service at a small efficiency cost for numeric channels and a moderate cost for state channels.

4.7. Consistency and Aggregate Fidelity

Table 28 reports the aggregate mean error, normalised by the engineering scale as in Equation (15), and the state mismatch at the receiver.

Table 28. Consistency and aggregate-fidelity results, cross-vessel mean.

Policy	AggErr (% of Scale), Mean/Median over Channels	State Mismatch
P0 full	0.0000/0.0000	–
P3 numeric, 240-step heartbeat	0.0000/0.0000	–
P4 0.5%	0.0072/0.0024	–
P4 1%	0.0134/0.0043	–
P4 2%	0.0211/0.0069	–
P4 5%	0.0340/0.0101	–
P5 5% + spike	0.0343/0.0104	–
P6 numeric	0.0048/0.0008	–
P6 numeric, time-based heartbeat	0.0047/0.0008	–
P3 state, 60-step heartbeat	–	0
P6 state, time-based heartbeat	–	0

To make the counter and compliance-aggregate analysis explicit, the consistency evaluation was extended in two directions. First, monotonicity violations, that is, decreases between consecutive valid samples, were counted for all counter channels in the cleaned trace and in the P6 LOCF reconstruction. Second, a compliance-relevant proxy KPI was formed from float channels whose names refer to fuel, power, shaft, flow, consumption, load, or speed of rotation, by comparing calendar-hour means of the original and the reconstructed series at the valid steps. Up to 80 such channels per vessel were sampled with a fixed seed. Table 29 summarises the results, where the KPI errors are medians over channels of the per-channel mean and 95th-percentile hourly error, in percent of scale.

Table 29. Counter-monotonicity violations and hourly compliance-KPI error with P6.

Vessel	Counters	Viol. Raw (%)	Viol. P6 (%)	KPI Ch.	KPI Hourly Mean (%)	KPI Hourly P95 (%)
V1	21	0.57	0.41	80	0.0029	0.0114
V2	13	0.68	0.36	80	0.0022	0.0084
V3	19	0.75	0.39	80	0.0018	0.0033
V4	41	0.74	0.63	80	0.0060	0.0203
V5	35	0.56	0.37	80	0.0050	0.0200
Overall	129	0.65	0.42	400	0.0035	0.0140

The P6 reconstruction never has more decreases than the original counter on any channel. The violation rate is lower after reconstruction because the deadband suppresses many of the small decrements present in the raw counter stream so that the reconstruction is not a faithful copy of these decrements. For the KPI channels, the hourly aggregate error is 0.0035% of scale at the median channel, and its 95th percentile over the hours of a channel is 0.014% at the median channel.

The headline results use LOCF because the dominant signal pattern in shipboard channels is a step or plateau, which LOCF reproduces exactly between received samples. A comparison with LERP on float channels, reported in Appendix A (Table A1), shows larger NRMSE, larger P95 error, and larger aggregate error for LERP under all three evaluated policies. Figure 4 shows the mechanism. LERP and LOCF agree on ramps, but before every step LERP starts to move towards the next received value and therefore shows a change before it has happened.

4.8. Robustness to Transport Perturbations

Maritime ship-to-shore transport can drop, reorder, or delay records. Table 30 reports the effect of the perturbations of Section 3.6 on the reconstruction of all float channels and on the state channels of all vessels, with P0 under the same perturbation conditions as the reference. For float channels the table gives the median per-channel NRMSE of each vessel averaged over the vessels, and for state channels the rates over all transitions or valid steps.

Table 30. Reconstruction under transport perturbation conditions.

	Float Channels		State Channels
Scenario	NRMSE (%)	Step Recall, 5%	Event Miss	State Mismatch
P0 full, no perturbation	0.000	1.000	0.0000	0.0000
P6, no perturbation	0.067	1.000	0.0000	0.0000
P0, 1% random loss	0.059	0.990	0.0100	0.0001
P6, 1% random loss	0.181	0.990	0.0100	0.0001
P0, delay 0–8 steps, plain LOCF	1.517	–	–	0.0057
P0, delay 0–8 steps, sequence check	1.248	–	–	0.0052
P6, delay 0–8 steps, plain LOCF	1.964	–	–	0.0065
P6, delay 0–8 steps, sequence check	1.327	–	–	0.0056

A random loss of 1% of the records has a larger effect on the reduced stream than on the full stream. For P0 a lost record is replaced by the next sample one step later. For P6 a lost record is replaced only by the next change or heartbeat, so the receiver holds a wrong value for longer. The median NRMSE with 1% loss is 0.181% for P6, compared with 0.059% for P0. For state channels, 1% loss misses 1% of the transitions for both P0 and P6, but the wrong state persists until the next heartbeat with P6 instead of until the next sample, which raises the state mismatch from 0.00005 to 0.00013. A delay of up to eight grid steps increases the error of both streams by a similar amount, and most of this error is the delay itself because P0 with the same delay shows almost the same NRMSE. The sequence check removes the part of the error caused by reordering, reducing the NRMSE of P6 from 1.96% to 1.33% and the state mismatch from 0.00651 to 0.00562. These results argue for three receiver-side measures in a deployment, namely, a per-channel sequence number or source timestamp so that late records do not overwrite newer ones, acknowledged delivery or a store-and-forward buffer for state transitions, and a shorter heartbeat for channels whose wrong value would be costly. The simulation assumes independent losses and a uniform delay. It does not model the burst losses, multi-hour outages, or bandwidth limits of a satellite link.

4.9. Gateway Resource Footprint

A shipboard gateway has to apply the P6 decision rule to every channel at every grid step in real time. To estimate the per-step cost, the P6 decision was run as a streaming loop. At each grid step the gateway reads the current sample of every channel, updates the per-channel state of Appendix B, and emits the records to be sent, which are then serialised and compressed with gzip level 6 as one batch per step. The benchmark ran in a single Python 3.10.6 process on one core of the AMD Ryzen 7 9800X3D computer described in Section 3.9, using Windows 11, without Numba acceleration of the decision loop. Elapsed times were taken with time.perf_counter around the decision pass and around the compression call of every step, and the resident set size (RSS) was read with psutil before the loop and after every step. The channel samples were loaded into memory before the loop started, so the loop reproduced the computation of a streaming gateway but not its input–output path. For simplicity the deadband threshold in this loop was computed from the current value rather than from the precomputed channel scale, which had the same computational cost. The benchmark used real channel traces taken from V1 onwards, unioning channels across vessels to reach 1000, 2000, and 3000 channels. Each test ran 20,000 grid steps. Table 31 reports the results, where P6 time is the decision pass per step and gzip time is the per-step batch compression.

Table 31. Gateway resource footprint of the P6 adaptive policy on a single processor core.

Channels	Records/Step	P6 Mean/P95 (μs)	Gzip (μs)	Gzip B/Step	RSS Base (MiB)	RSS Increase (MiB)
1000	86	545/919	102	2055	1133	2.5
2000	199	1118/1768	169	3111	2225	0.9
3000	349	1827/2511	302	5217	2742	0.2

Even at 3000 channels, the P6 decision pass takes about 1.8 ms per step on average and 2.5 ms at the P95. The shortest sampling interval in the dataset is 8 s (V1), so the decision and compression together use less than 0.03% of the available time per step. Gzip compression of the emitted batch adds about 0.3 ms per step. The resident memory of 1.1–2.7 GiB is taken up by the preloaded channel samples and the Python and Polars runtime. Within the loop the memory grew by at most 2.5 MiB, the per-channel state of a few values per channel. The decision rule itself is therefore light in both computation and memory. Its integration into a specific gateway, with a live acquisition interface, a messaging stack, and a power budget, is a deployment step beyond the scope of this study.

4.10. Acceptance-Profile Synthesis and Recommended Policy Map

Table 32 applies the acceptance profiles of Table 13 to every policy. For each vessel it gives the share of the relevant channels that meet all criteria of the profile, and a policy is accepted, marked with an asterisk, when this share is at least 95% on every vessel. The last column gives the bytes saved averaged over the vessels. Among the accepted policies, the one with the highest bytes saved is the operating point for that service.

Table 32. Share of channels meeting each acceptance profile.

Profile	Policy	V1	V2	V3	V4	V5	Saved (%)
A	P0 full *	100.0	100.0	100.0	100.0	100.0	0.0
	P3, 4-step heartbeat *	100.0	100.0	100.0	100.0	100.0	63.6
	P3, 20-step heartbeat	100.0	100.0	100.0	0.6	0.6	92.1
	P3, 60-step heartbeat	100.0	100.0	100.0	0.3	0.3	96.9
	P6, time-based heartbeat *	100.0	100.0	100.0	100.0	100.0	95.6
B	P3, 240-step heartbeat	100.0	100.0	100.0	52.9	46.3	53.8
	P4 0.5%	97.9	97.9	97.5	11.4	10.4	84.9
	P4 1%	89.2	90.4	87.2	6.6	7.7	89.3
	P4 2%	54.0	53.6	50.3	1.1	1.5	92.8
	P5 5% + spike	50.3	37.6	43.5	0.4	0.7	95.7
	P6, 240-step heartbeat	99.3	99.3	98.8	29.9	23.1	74.4
	P6, 60-step heartbeat *	99.4	99.4	98.9	99.4	99.5	73.4
	P6, time-based heartbeat *	99.3	99.3	98.8	99.3	99.5	74.3
C	P4 0.5% *	99.9	99.9	99.4	98.9	98.9	84.9
	P4 1% *	99.9	99.3	99.0	97.9	97.4	89.3
	P4 2%	99.6	98.2	97.8	95.4	94.3	92.8
	P4 5%	80.3	74.1	77.4	52.1	53.9	95.9
	P5 5% + spike	80.1	74.1	78.1	52.0	54.2	95.7
	P6, 240-step heartbeat *	100.0	99.9	99.6	99.3	99.3	74.4
	P6, time-based heartbeat *	100.0	99.9	99.4	99.3	99.4	74.3

For profile A, alarm and state monitoring, no change-based policy misses a transition, so acceptance is decided by staleness alone. Heartbeats counted in grid steps fail on the vessels with long sampling intervals, whereas the time-based heartbeat of 15 min is accepted on every vessel and saves 95.6% of the records. For profile B, the condition-monitoring dashboard, P6 meets the error and recall criteria on at least 99% of the channels of every vessel, but with its 240-step heartbeat only 23–100% of the channels stay within the 60-min staleness bound. With the time-based heartbeat, P6 is accepted on every vessel at 74.3% bytes saved. Uniform deadbands fail for two further reasons. At 1% the windowed excursion recall reaches the bound on only 88–95% of the channels, and at 2% the NRMSE bound is also missed on 29–49% of the channels. For profile C, aggregate evidence, which has no staleness criterion, the accepted policy with the largest saving is P4 1%, which saves 89.3% of the bytes. The criterion that binds therefore differs by service, namely, staleness and excursion preservation for monitoring and the aggregate error for evidence, and the same channel inventory supports different operating points for different services.

Table 33 summarises the recommended transmission policy per channel class, derived directly from the per-class results and the acceptance-profile check. The map is parameter-light because each channel selects its policy from its value type and from its profile-measured ZCR, both of which were computed once from the channel inventory.

Table 33. Recommended transmission policy per channel class.

Channel Class	Recommended Policy	Rationale
Boolean alarm/status	Change + heartbeat set in elapsed time from the service requirement, 15 min in profile A	Lossless transitions with bounded staleness
Enumeration/mode	Same as boolean	Same rationale with small cardinality
Counter	ZCR-based deadband as for floats, or change-only where every increment is needed	Preserves rate within tolerance
Quasi-static float (ZCR > 0.9)	Deadband 1% + time-based heartbeat	98.7% bytes saved at NRMSE ≈0.0012
Slowly varying float (0.5 < ZCR ≤ 0.9)	Deadband 0.5% + time-based heartbeat	Balanced trade-off
Continuous float (ZCR ≤ 0.5)	Deadband 0.1% + time-based heartbeat	Conservative for noisy signals
Quasi-static float where a wider deadband is acceptable	Spike-aware deadband (P5) with a base deadband of at least half the spike threshold	Wide deadband without losing abrupt steps

Taken together, applied to all channels, the adaptive policy removes 82.8% of the records with an NRMSE of 0.08% on numeric channels and no event miss on state channels, whereas gzip compression of the full stream removes 85.9% of the bytes but none of the records. Savings close to 99% are reached only on the quasi-static float channels, 17% of the float channel instances. Whether a reduced stream is acceptable depends less on the deadband than on the heartbeat because currentness is the criterion that binds first, and the heartbeat must therefore be set in elapsed time for each vessel.

5. Discussion and Limitations

5.1. Discussion

The results support the paper’s premise that repeatedly sampled shipboard sensor data do not necessarily require repeated transmission. Across the five vessels, a large fraction of channels were either exactly stable, state-like, or slowly varying after sentinel cleanup. This separates acquisition frequency from transmission frequency. A shipboard data server may need to acquire and archive values at the original sampling cadence, but a shore-facing operational stream does not always need to carry every recorded sample. The size of the opportunity, however, depends strongly on the channel population. Quasi-static channels can be reduced by about two orders of magnitude, while continuously varying channels, which are the majority of float channels and carry most of the records, can be reduced only by about half if their reconstruction error is to stay at the level of the export resolution. A whole-stream reduction of about four-fifths of the records is therefore a more realistic expectation for a shipboard data server than the figure obtained for its most stable channels.

The acceptance profiles make the efficiency–quality balance explicit, and they show where efficiency starts to cost information. The error criteria are satisfied for almost all channels up to a 1% deadband, and gradual excursions remain visible at the receiver even at 5%. What deteriorates first as the deadband widens is the preservation of small abrupt steps, which falls clearly between 1% and 5% deadband. For a service that must see every abrupt change of a given size, the deadband should be kept below half of that size, or a spike exception should be added. What deteriorates first as the heartbeat lengthens is currentness. On vessels with long sampling intervals a heartbeat counted in grid steps can leave a value several hours old, and this, rather than reconstruction error, is the criterion that rejects otherwise accurate policies.

The results also clarify the relationship between compression and change-aware transmission. Gzip compression is a strong baseline, which confirms that the data contain substantial byte-level redundancy. Compression operates after records have already been generated. It does not reduce record count, queue growth, or ingest load on the receiver. Change-aware policies operate earlier in the cost model by suppressing unnecessary records before transmission. The same-format comparison shows that the two reductions multiply. For a satellite link, where cost scales with bytes, the compressed reduced stream is the relevant quantity. For a broker or a shore-side ingestion service, where cost scales with messages and database writes, the record reduction is the relevant quantity, and compression alone does not help.

The per-value-type results suggest that a single transmission policy is inappropriate for heterogeneous shipboard sensor data. Boolean and enumeration channels behave like state channels. They can be transmitted losslessly with change-only reporting, and a heartbeat can be added to provide a bounded currentness contract. Counter channels require a different interpretation because the value may change monotonically but sparsely, and they can be treated through change, delta, or deadband-like checkpoint policies. Floating-point channels require the most careful handling. Some floats are quasi-static and can tolerate a wider deadband, while others are slowly or continuously varying and require tighter thresholds. The adaptive policy aligns a small set of rules with measured channel behaviour. A shipboard gateway can therefore profile each channel once and then assign a lightweight transmission policy.

The heartbeat should be chosen from the function of the channel and the service that consumes it. For alarm and equipment-status channels, the transition itself is always sent, so the heartbeat only bounds how long the shore side can be unaware that the gateway or the sensor has gone silent. A heartbeat of the order of the alarm-response time expected ashore, for example, 15 min, is appropriate, and an alarm that must be acknowledged should additionally be sent with acknowledged delivery. For machinery-performance assessment, which uses trends over hours, a heartbeat of about one hour is sufficient, and the heartbeat costs little because most records are triggered by the deadband. For aggregate and compliance evidence, staleness matters less than completeness of the aggregate, and a longer heartbeat is acceptable provided the raw archive is retained. In all cases the heartbeat should be specified and evaluated in elapsed time from the timestamps of the samples, not as a number of grid steps. Table 26 shows that the same number of steps can mean minutes on one vessel and hours on another, and that even a step count derived from the median interval does not bound the elapsed time when the interval varies within a trace.

The perturbation results identify the main operational weakness of change-aware transmission. A lost record is not repaired by the next sample, as it would be in a full stream, but only by the next change or heartbeat. A gateway that uses change-aware transmission over an unreliable link should therefore number the records of each channel and send the source timestamp with every record so that the receiver can discard out-of-order records and detect gaps, use acknowledged delivery or a store-and-forward queue at least for state transitions, and resend the current value of every channel after a reconnection, which acts as an immediate heartbeat. These measures restore the guarantees that the analysis assumes, at a cost of a few bytes per record and one burst of records per reconnection.

Operational stream and raw archive must remain distinct. Change-aware transmission does not replace the original sampled record. For audit and regulatory traceability, the raw archive should remain available on board or through a separate archival synchronisation process. The change-aware stream evaluated here is a reduced operational data product intended for shore-side monitoring, dashboarding, alerting, and aggregate evidence generation. Operational users need timely compact updates, while compliance and audit users need full traceability. A shipboard gateway should therefore support both, with raw archival retention for traceability and reduced operational transmission for shore-side use.

The findings also have implications for MSW-related and environmental-compliance data services. MSW, DCS, CII, EU ETS, and FuelEU-related workflows increase the demand for reliable ship-to-shore operational data, but they do not imply that every raw sensor sample must be streamed to shore in real time. Many compliance-related values are ultimately used as aggregates, durations, counters, or evidence derived from multiple channels. For such uses, a reduced stream may be sufficient if its accuracy, completeness, currentness, and consistency are quantified and bounded. The hourly aggregates of fuel-, power-, and flow-related channels reconstructed from the P6 stream differ from those of the archive by 0.0035% of scale at the median channel and by at most 0.06% in the worst hour of the median channel, which is below the recorded resolution of most of these channels. The SQuaRE-inspired evaluation provides one way to make this decision explicit. Rather than treating data reduction as an informal optimisation, the gateway can report which quality dimensions are preserved by a selected policy and which dimensions are traded for efficiency.

The sentinel-cleanup result is also practically important. The raw exports contained no-signal sentinel values that would have distorted the stability profile if treated as real readings. A channel that alternates between a valid value and a sentinel can appear to change frequently even when the physical or operational state is stable. Change-aware transmission therefore depends on correct interpretation of missing values, no-signal codes, and vendor-specific export conventions. Data-quality preparation is a requirement for safe data reduction, not a preprocessing detail. A gateway that applies change detection before sentinel cleanup may transmit false changes or suppress valid behaviour.

The evidence of this study and the recommendations derived from it have different status. The following results are supported directly by the simulations on the recorded traces: the stability profile of the channels, the record and byte reductions of each policy, the reconstruction errors, the step and windowed recall, the measured staleness, the aggregate errors, and the effect of the simulated losses and delays. The following are recommendations that follow from these results but were not tested in a deployment: the acceptance thresholds, the time-based heartbeat values, the receiver-side sequence numbers and acknowledged delivery for state transitions, and the suitability of the decision rule for embedded gateway hardware. The results suggest a practical design guideline: Retain the raw sampled archive. Classify channels by value type and temporal behaviour, and correct the classification with channel metadata where it is available. Transmit state-like channels on change with a heartbeat set in elapsed time. Transmit numeric channels with deadband and heartbeat selected from their stability profile and from the acceptance profile of the receiving service. Protect excursions with spike-aware rules where a wide deadband is used. Compress the reduced stream when wire-byte reduction is needed. The design is not universally optimal but offers a measurable efficiency–quality operating point, in which reduced transmission is acceptable only when the receiving service’s data-quality requirements remain within tolerance.

5.2. Limitations and Future Work

This paper has several limitations. The dataset consists of five LNG carriers of similar class, and the evaluated traces are repeatedly sampled operational streams rather than sub-second control or vibration data. The cross-vessel consistency reduces the risk of a single-vessel artefact, but the conclusions apply to shipboard monitoring, energy management, and aggregate evidence streams, not to high-dynamic control loops or safety-critical channels, which may require fixed-rate transmission or separate raw streaming. Repeating the profiling and policy evaluation on other ship types, acquisition systems, and sensor taxonomies remains future work.

The value-type inference and temporal-behaviour profiling are rule-based and intentionally simple. The validation against path-derived labels in Section 3.3 shows that most disagreements lead to conservative, lossless treatment, while a small group of state channels interpreted as numeric would benefit from a metadata override. The results should therefore be read as properties of the recorded stream after cleanup. Incorporating ISO 19848 metadata, vendor tag dictionaries, and data-channel quality codes would improve classification robustness. The deadband thresholds are tied to the export resolution and the sensitivity curve, and the acceptance thresholds would in practice be set by each receiving service. Reconstruction uses LOCF throughout, and the comparison with LERP in Appendix A supports this choice for the dominant step-like channels, but class-specific reconstruction remains open.

The evaluation relies on message accounting and reconstruction analysis rather than a full communication-stack experiment, and the byte model excludes MQTT topic strings, Hypertext Transfer Protocol (HTTP) or TLS overhead, columnar metadata, and database ingestion cost. These choices shift absolute byte counts without removing the distinction between compressing generated records and suppressing records before generation. The same-format compression comparison covers stratified channel samples of three vessels rather than the full inventories, and the transport perturbations assume independent losses and a bounded uniform delay. A shipboard or local area network (LAN) testbed should compare representative policies with concrete transport formats using end-to-end transfer time, central processing unit (CPU) and memory load, queue growth, and recovery after interruption, and the gateway benchmark should be repeated on embedded gateway hardware.

Finally, the reduced operational stream does not replace the raw archive, which remains necessary for audit and regulatory traceability. Future work should examine two-layer gateways that synchronise the raw archive periodically while streaming the reduced stream continuously and should test whether policy parameters should adapt to the operating phase. The phase split of this study shows that the current rules already send more records when signals are active, without a loss of accuracy in either phase.

6. Conclusions

This study evaluated change-aware transmission for repeatedly sampled shipboard sensor data as a data-quality trade-off rather than a pure compression problem. Operational traces from five LNG carriers were profiled by value type and temporal behaviour, seven transmission policies were applied to the same cleaned traces, the shore-side series was reconstructed with LOCF, and each policy was evaluated through SQuaRE-inspired efficiency, accuracy, completeness, currentness, and consistency metrics, with explicit acceptance profiles for alarm monitoring, condition-monitoring dashboards, and aggregate evidence.

Three conclusions follow. First, the opportunity is real but uneven. Most state channels and many float channels are exactly or quasi-constant, while continuously varying float channels carry most of the records. Applied to all channels, the type-and-behaviour adaptive policy removes 82.8% of the records with an NRMSE of 0.08% on numeric channels and no missed state transition, and it saves 73.9% on float channels as a whole and 98.7% on quasi-static float channels. Second, compression and change-aware transmission address different costs and combine multiplicatively. With the same format and codec, compressing the P6 stream instead of the full stream removes a further 51–78% of the compressed bytes, and only record suppression reduces the number of messages that brokers and ingestion services must handle. Third, currentness is the data-quality characteristic that limits the reduction first. A heartbeat must be specified in elapsed time from the needs of the receiving service, and a deployment needs sequence numbers and acknowledged delivery of state transitions to remain robust to lost and reordered records.

The resulting gateway design retains the raw sampled archive on board, transmits state-like channels on change with a heartbeat, applies a deadband selected from the measured ZCR and, where a wide deadband is used, a spike exception to numeric channels, and optionally compresses the reduced stream. The operator tunes heartbeat and deadband from the reported sensitivity curves and acceptance profiles to match the receiving service’s data-quality requirements. Future work should extend the evaluation to other vessel classes and acquisition systems, validate the decision rule on embedded gateway hardware, and quantify transport, TLS, and broker-queueing costs on a real link. High-rate sampling does not require high-rate transmission, provided the data-quality characteristics that the receiving service depends on remain within tolerance.