BRIDGE · VESSEL ADAPTERS AND EQUIPMENT INTEGRATION
Connect your chosen equipment to NAUTILUS
Your vessel may use a particular ECU, propulsion system or steering arrangement. BRIDGE is the NAUTILUS adapter module that defines how those interfaces connect to the core software, which commands they support and what feedback they must return.
IN DEVELOPMENT · PILOT CONVERSATIONS OPEN
NAUTILUS / FILM
Watch BRIDGE.
ON THIS PAGE→
Page sections appear in preview
01 / BRIDGE
Work with the machinery you select
A vessel may use rudders, jet drives, multiple engines or manufacturer-specific control systems. BRIDGE’s role is to translate a permitted vessel-level demand into that equipment’s documented semantics, within the capabilities and bounds that the commissioned adapter declares.
The common platform can express supported intents such as target heading, target speed and a request for the vessel-defined safe state. The adapter defines what those intents mean for the named vessel and which ones are available.
Builders can implement a common software interface while retaining the machinery-specific behaviour their vessel requires.
02 / BRIDGE
Declare capability before exposing control
Each adapter manifest records the component identity, protocol and firmware versions, supported demands, units, ranges, timing, watchdog behaviour, feedback and failure response. Package identity, compatibility, vessel scope and licence are checked before activation.
The connected component must be discovered and healthy before its capability becomes available. A connector on the computer is only the physical starting point; supported behaviour comes from the adapter and its conformance evidence.
03 / BRIDGE
Bound the demand again at the hardware interface
BRIDGE accepts a WATCH-authorised intent with valid timing and policy context. It checks that intent against the active adapter, supported range and relevant state before translating it.
The equipment process holds the minimum device permissions needed for its declared capability. Other modules work through the platform contract rather than acquiring independent machinery access.
04 / BRIDGE
Measure what the vessel actually does
An equipment acknowledgement and a measured response answer different questions. The BRIDGE feedback contract keeps those records separate.
The commissioned control path compares demanded and observed heading, speed or actuator state, with vessel-specific response bounds and fault handling. Missing, stale or contradictory feedback must change the available mode or trigger the commissioned response.
The integration can therefore be judged against what the equipment actually did, as well as the messages it received.
05 / BRIDGE
A practical interface strategy for builders
Candidate connections include Ethernet/IP, isolated CAN or CAN FD, serial interfaces, USB and approved isolated I/O modules. Protocol work may use documented vendor APIs and marine data standards where licensing, device support and conformance permit.
Sensors, machinery health and separately scoped mission devices can enter through typed partner ports. Any action-capable device requires explicit permissions, capability and authority scope. The first integration must establish the supported equipment rather than imply universal protocol compatibility.
06 / BRIDGE
Retain control of the adapters you develop
The licensing model gives authorised builders documented interfaces to implement while AIC retains the core software IP. The agreement covers customer-authored adapter ownership, maintenance rights and support, so those responsibilities are clear before the work starts.
The planned kit includes capability schemas, simulation support, a read-only sensor example, conformance checks and fault fixtures. Access and supported versions will be established as the integration programme develops.
BRIDGE is in development. Live actuation requires the named adapter, vessel profile, hardware-in-loop evidence and approved vessel trials.