Event-Driven Electronic Vessel Logbook with Pluggable Blockchain Storage

Defensive Prior Art Disclosure

Event-Driven Electronic Vessel Logbook with Pluggable Blockchain Storage

Statement of Intent

This document is published as a defensive prior art disclosure. The author intentionally makes the described electronic-logbook architecture publicly available to prevent later parties from claiming the broad disclosed combinations as previously unknown inventions.

No exclusive patent rights are asserted by the author over the concepts expressly disclosed below.

Technical Field

The disclosed subject matter relates to:

• electronic vessel logbooks;
• automatic event creation from marine sensors;
• manual captain and crew entries;
• event sourcing;
• intermittent network synchronization;
• public blockchain storage;
• fleet grouping and audit history.

Background and Technical Problem

Traditional paper logbooks depend on manual entry and are often incomplete. Conventional digital logbooks may also require users to manually copy position, time, engine state and weather data even though those values are already available on the vessel network.

Cloud-only systems may stop functioning when the vessel loses connectivity. A logbook tightly coupled to one database or blockchain also makes migration and offline operation difficult.

Summary of the Disclosed Solution

The disclosed system treats a vessel logbook as an abstract ordered stream of events. Events may originate automatically from onboard data or manually from the captain and crew.

The core logbook is independent of its final persistence mechanism. One implementation stores or announces logbook events using custom operations on the public Hive blockchain. Other implementations may use a conventional server, local database, private distributed ledger or multiple storage targets.

Functional Components

An exemplary system comprises:

1. data-source adapters;
2. a normalized vessel-state service;
3. an event-detection engine;
4. a manual-entry interface;
5. an event-envelope generator;
6. a local persistent queue;
7. one or more storage adapters;
8. a reader and verification application;
9. an optional fleet-management layer.

Data-Source Adapters

Adapters may receive information from:

• NMEA 2000 or NMEA 0183;
• GNSS;
• an inertial measurement unit;
• engine instrumentation;
• fuel and battery sensors;
• bilge and water-level sensors;
• discrete lighting, ignition or windlass inputs;
• local weather instruments;
• Internet weather or hydrological services;
• manual user input.

The adapters translate device-specific inputs into common semantic values.

Automatic Event Generation

The event engine evaluates changes in vessel state and creates log entries according to rules. Examples include:

• voyage started;
• engine started or stopped;
• departure from a marina or defined area;
• arrival at a destination;
• anchor deployed or anchor-watch mode armed;
• navigation lights switched on or off;
• fuel level crossed a threshold;
• unusual heel or pitch detected;
• possible capsize detected;
• bilge-water alarm activated;
• communications lost or restored;
• weather warning received;
• lock, bridge or waypoint passed.

Rules may include hysteresis and minimum-duration conditions so that rapid signal changes do not generate excessive events.

Manual Entries

A captain or crew member may add an event using text, predefined categories, voice converted to text, photographs or attachments.

The manual entry may automatically inherit the current:

• vessel identifier;
• time;
• position;
• voyage identifier;
• author identity;
• weather summary;
• engine and navigation state.

The user may confirm or edit automatically suggested metadata before committing the entry.

Event Envelope

Each event may be represented as a structured record containing:

• schema version;
• unique event identifier;
• vessel identifier;
• voyage or session identifier;
• event category;
• event time and recording time;
• geographic position and position quality;
• author or generating component;
• human-readable description;
• structured event payload;
• references to related events or attachments;
• optional signature or checksum.

Events are append-oriented. A correction is represented by a new event referring to the corrected event rather than by silently overwriting historical data.

Local Persistent Queue and Offline Operation

New events are first written to durable local storage. A synchronization component attempts to deliver them to one or more configured storage targets.

If the network is unavailable, event creation continues. Each queued event has a delivery state such as:

• local only;
• pending transmission;
• transmitted;
• confirmed by destination;
• rejected or requiring operator action.

Events retain their original occurrence time even if they are transmitted later.

Pluggable Storage Interface

The logbook core invokes a storage interface rather than a specific database implementation. An adapter may support operations such as:

• append event;
• query by vessel and time range;
• confirm destination acceptance;
• retrieve an event by identifier;
• obtain a cursor or checkpoint for synchronization.

Different adapters may be enabled simultaneously. For example, the complete payload may be stored on an owner's server while a summary or reference is published on a public ledger.

Hive Blockchain Implementation

In one concrete implementation, a Hive account associated with the vessel owner, captain, device or fleet publishes a custom_json operation containing a logbook event or a batch of events.

The custom operation includes an application identifier and a versioned JSON payload. The payload may contain the complete event, a compressed event, a summary or a reference to externally stored content.

The transaction identifier and block information are recorded by the local or server-side synchronizer as destination confirmation.

Because Hive is public, sensitive information may be omitted, reduced, encrypted for authorized recipients or stored externally with only a non-sensitive reference included in the public operation.

Fleet and Community Layer

Multiple vessels may be grouped into a fleet. Fleet membership may be represented in an application database or by signed public operations.

The web application may provide:

• a chronological logbook for one vessel;
• voyage summaries;
• filters by event type;
• maintenance history;
• automatic statistics;
• public entries shared with a community of owners;
• private or encrypted operational entries;
• fleet-level alerts and reports.

The logbook abstraction allows the same event stream to support recreational vessels, rental fleets and commercial operators.

Corrections and Conflicting Information

If a human entry conflicts with an automatically generated entry, both may remain visible. A later annotation event may mark one event as confirmed, rejected, superseded or explained.

This preserves audit history and avoids rewriting earlier records.

Example Sequence

1. Ignition voltage becomes active and GNSS speed begins increasing.
2. The rule engine creates a voyage_started event.
3. The event envelope includes vessel, time, position and engine state.
4. The event is committed to the local queue.
5. No Internet connection is available, so the event remains pending.
6. The captain manually adds a note about crew and destination.
7. Later, connectivity returns.
8. The storage adapter submits both events to the configured server and publishes corresponding Hive custom operations.
9. Confirmation identifiers are stored without changing the original event times.

Technical Effects and Advantages

The system provides:

• automatic capture of events already observable through vessel electronics;
• continued logging without network access;
• independence from a particular database or blockchain;
• preservation of corrections and audit history;
• combined manual and machine-generated records;
• reuse of the same events for safety, maintenance and fleet reporting.

Technical Concepts Disclosed for Prior Art Purposes

This publication expressly discloses:

1. an abstract event-stream model for a vessel logbook;
2. automatic event generation from NMEA, GNSS, IMU and discrete electrical inputs;
3. enrichment of manual entries with current vessel data;
4. durable offline queuing followed by delayed synchronization;
5. a pluggable persistence adapter allowing conventional databases and public blockchains to be interchanged or used together;
6. use of Hive custom_json operations to record vessel-log events;
7. correction through append-only annotation events rather than hidden modification;
8. grouping of vessel event streams into owner or rental fleets.

Public Availability Declaration

The expressly described concepts are made available for public use, implementation and extension. This disclosure is intended to establish that these broad architectures and combinations are publicly known.