Modern bridge systems share sensors, networks, software and control interfaces. This guide explains how those technologies fit together, where INS and IBS sit, and how technical crew can trace faults without disturbing safe control of the vessel.
- How information and control move through a modern bridge system.
- The difference between INS, IBS, bridge automation and remote operation.
- Why several failed displays may have one common cause.
- What technical records and failure tests should be maintained onboard.
During a passage, the radar overlay becomes unstable, the conning display loses heading and the track-control system disengages. The gyro’s own display still shows a valid heading.
That does not suggest three unrelated equipment failures. It suggests that the heading is being produced correctly but is being lost, delayed or rejected somewhere between the gyro and the systems using it.
The track-control disengagement may also be the correct safety response to invalid data. Restarting every affected workstation would remove useful evidence without touching the likely cause.
This is the main difference between fault-finding on a standalone bridge and an integrated one. The technician has to follow the function through the system, not simply attend to the screen where the symptom appeared.
The clearest way to understand bridge architecture is to separate the information path from the control path.
The information path carries sensor data:
Sensor → interface or gateway → network → application → display, alert or recorder
The control path carries commands:
Operator or automated function → control authority → controller → actuator → feedback
Heading, position and speed normally travel along the information path. A heading command from an autopilot, rudder demand from a steering controller or thrust allocation from a DP system travels along the control path.
Those paths may share networks, computers, power supplies and software services, but they serve different purposes. A conning display may show rudder angle without having any authority over the steering system. A VDR receives and records data but does not control the equipment producing it.
The Main Technology Blocks
| Technology block | What it does | Typical equipment |
|---|---|---|
| Sensors and data sources | Measure or produce navigation information. | Gyro, GNSS, speed log, echo sounder, wind sensor, radar and AIS. |
| Interfaces and gateways | Convert, collect or distribute data between equipment. | Serial distributors, data collectors, protocol converters and LAN gateways. |
| Networks and shared services | Move data and maintain common services across the bridge. | Ethernet switches, redundant LANs, time services, sensor-selection services and central servers. |
| Navigation applications | Use the data for defined bridge tasks. | Radar, ECDIS, conning, route monitoring and alert management. |
| Operator workstations | Present one or more applications to the bridge team. | Dedicated displays and multifunction workstations. |
| Control systems | Turn an operator or automated demand into physical action. | Autopilot, steering control, propulsion remote control, joystick control, thruster control and DP. |
Older systems commonly use point-to-point serial connections. Newer platforms increasingly use Ethernet-based data exchange. IEC 61162-450:2024 covers Ethernet communication between marine navigation and radiocommunication equipment. IEC 61162-460:2024 adds requirements where greater network integrity, safety and security are needed.
Neither standard makes an installation resilient by itself. The actual result depends on network design, separation, redundancy and testing.
A standalone electronic bridge gave each radar, ECDIS, autopilot and instrument its own processor and display. A few serial connections passed heading, position or speed between them. Most failures remained local, although shared distributors and power supplies could still create common faults.
The next step was the coordinated or “glass” bridge. Equipment began sharing sensors, console space and proprietary data networks. Multifunction displays allowed radar, ECDIS or conning applications to be operated from different stations.
Integrated systems took this further. Sensor selection, route data, target information, alerts and system health could be managed centrally. Wider platforms also connected steering, propulsion, thrusters, DP or vessel automation.
Many yachts contain all three generations. A current multifunction display may still depend on an old serial distributor, an undocumented protocol converter or a single power supply fitted during an earlier refit. The console can look modern while the data path behind it remains a mixture of old and new technology.
These terms describe different aspects of the installation.
Integrated Navigation System
An Integrated Navigation System is based on defined navigational tasks. Under IMO Resolution MSC.252(83), those tasks include:
- route planning;
- route monitoring;
- collision avoidance;
- navigation-control data;
- status and data display; and
- alert management.
IEC 61924-2:2021 provides the associated requirements and test methods for modular INS installations.
An INS is therefore more than several applications running on matching screens. Its approved configuration defines the integrated tasks, data sources, redundancy, alert handling and fallback arrangements.
Integrated Bridge System
IBS has an equally important, but broader, history. IMO originally defined an IBS as interconnected systems providing central access to sensor information or command and control from bridge workstations.
The original performance recommendation in MSC.64(67) was later superseded by SN.1/Circ.288, which addresses bridge equipment, workstation arrangement, interfaces, fault tolerance, power and integration.
Manufacturers still use “IBS” for products of very different scope. One may be mainly a navigation package. Another may include machinery information and propulsion controls. The product name is not enough; the approved drawings and certificates must show what has actually been integrated.
Bridge Automation and Control
Automation describes what the system does, rather than how the console is branded.
- A conning display gathers information for situational awareness.
- Bridge Alert Management coordinates and prioritises alerts under MSC.302(87).
- An autopilot or heading-control system maintains a selected heading.
- A track-control system uses position, heading, speed and route information to follow an approved track. Its performance requirements are covered by IEC 62065:2025.
- Propulsion remote control sends speed, RPM or pitch demands to the propulsion-control system.
- Joystick and DP systems coordinate propulsion and thrusters to control movement or position.
Showing propulsion or steering information on a workstation does not give that workstation control authority. The control-authority matrix should identify who can command each function, how authority is transferred and what happens when communication or feedback is lost.
Navigation-focused platforms such as Anschütz SYNAPSIS NX, Sperry Marine VisionMaster and Furuno VOYAGER commonly bring radar, ECDIS, conning, sensor data and alerts into a coordinated working environment.
Kongsberg K-Master, NACOS, mtu NautIQ and ABB bridge platforms may extend further into manoeuvring, DP, propulsion, power or vessel automation, depending on the contracted configuration.
These examples show how manufacturers package the technology; they do not define the fitted architecture. For any platform, establish:
- which functions are type-approved;
- where sensor data is selected and validated;
- which servers, switches and power supplies are shared;
- which stations can display, acknowledge or command each function;
- what remains available after a common-component failure; and
- whether third-party equipment has been connected through approved interfaces.
A remote-support connection allows a technician or manufacturer to inspect logs, diagnose faults or perform authorised work. Shore monitoring normally receives vessel data without taking control.
Remote operation is different because commands originate away from the vessel. It adds a new control station, a communications link and an authority-transfer process. Loss of that link requires a predetermined response.
An autonomous function carries out part of the operation using software and sensor inputs under defined modes and limitations. Automatic track control or DP alone does not make the vessel a Maritime Autonomous Surface Ship.
The IMO’s non-mandatory MASS Code took effect on 1 July 2026. It presently applies to defined cargo-ship cases rather than yachts generally, but its treatment of operating modes, human oversight, remote-control centres, connectivity and fallback provides useful engineering principles.
Where a yacht introduces shore-based control, it should be handled as a separate approval and safety project. It is not simply another remote-access feature.
Return to the original example. The gyro display is healthy, but several networked consumers have lost heading.
A useful sequence would be:
- Confirm with the bridge team which operating mode and fallback are in use.
- Record the active heading source, data age, alerts, timestamps and affected systems.
- Check the gyro’s configured output, not only its local indication.
- Check the data collector, serial interface or gateway receiving that output.
- Compare heading at another genuinely independent consumer.
- Check the selected source and validation status within the integrated system.
- Investigate shared network, server, power and time services before working on individual displays.
- Confirm why track control disengaged and whether the response matched its design.
- After repair, test indication, alerts, recording, control engagement and fallback.
This method preserves evidence and narrows the fault boundary. A reboot may eventually be justified, but it should follow the diagnosis rather than replace it.
An integrated bridge needs more than equipment manuals. The onboard technical pack should include:
- an as-built system architecture drawing;
- a register of sensors, interfaces, gateways and data destinations;
- workstation roles, licences and permitted applications;
- a control-authority and transfer matrix;
- an alert cause-and-effect list;
- software and firmware baselines;
- restorable configuration backups;
- remote-access methods and approval records; and
- documented degraded modes and failure-test results.
Planned testing should demonstrate alternate sensor selection, workstation takeover, network and power redundancy, alert transfer, local control fallback and recovery after failure. A successful restart only proves that the equipment restarted.
Carriage, approval, redundancy and survey requirements depend on flag, class, tonnage, vessel use, operating area and the functions fitted. MCA MGN 610 Amendment 1 provides UK guidance on SOLAS Chapter V, but the yacht’s own flag, class records and approved documentation remain the installation-specific references.
Bridge Data Interface and Gateway Register A working register for bridge data sources, protocols, gateways, destinations, direction of communication, technical ownership and test evidence.