Smart Shipping and Autonomy: The Three Layers

A modern ship already runs on more software than steel in the places that matter. The engine room holds its own watch through an alarm panel, not an engineer on a stool; the bridge fixes the ship by satellite, not by sextant; and a shore office in Singapore can read every parameter on a vessel mid-Indian-Ocean within seconds of it changing. Smart shipping is the name for that drift of control from the deck plates to the data layer, and it runs across three distinct technologies that get bundled together but are governed by separate rules and built by separate vendors: the automation that lets an engine room run unattended, the autonomy that lets a ship run with a thin crew or none, and the satellite link that ties the ship to the shore. This is the subject hub for that cluster of marine technology, and it routes down to the three cluster hubs that carry the detail: engine room automation and monitoring, autonomous ships and the MASS Code, and satellite communication and vessel tracking.

The three layers stack in a definite order, and the order is the argument of this hub. Engine-room automation came first and is mature: ships have run periodically-unattended machinery spaces since the 1970s, and the class notation that certifies it is routine. Satellite communication came next and is now the nervous system: it carries the data that lets a shore office see the ship at all. Autonomy is the newest layer and the least settled, and it depends on the other two: a remotely controlled ship is an automated machinery space plus a high-bandwidth shore link plus a control center ashore. Read the hub from the bottom up and the autonomous ship stops being science fiction and becomes the obvious next assembly of parts that already exist. The questions that recur at every layer are the same three: what does the rule require, who certifies it, and where does the human sit relative to the machine.

The three layers and how they relate

It helps to fix the three technologies side by side before working each one, because the press coverage blurs them into a single “autonomous ship” story that hides how differently they are governed and how far apart they sit in maturity. The table sets out the layer, its core regulation, who certifies it, and how settled the field is.

The dependency runs upward. Autonomy needs both lower layers: a degree-three ship with no crew aboard is an unattended machinery space that has lost even its on-call engineer, controlled through a satellite link that has to carry far more than the legacy GMDSS terminal ever did. That is why a project to build an autonomous coastal ferry spends most of its engineering effort not on the autonomy decision logic but on the boring lower layers: making the machinery genuinely unattended-safe, and making the shore link reliable enough to bet a ship on. The hub takes the layers in maturity order: automation, then satcom, then autonomy.

The word “smart” gets attached to a lot of marine products, so it helps to say what this hub does not cover. It is not about the ship’s commercial and cargo software, the planning, stowage, and documentation systems that run a voyage as a business; those sit in the chartering and logistics clusters. It is about the technologies that change where control of the ship itself sits: the machinery that runs without a watch, the link that carries control ashore, and the autonomy that decides what the ship does. Those three are one coherent subject because they share a direction, control moving off the deck plates, and a common dependency, the data layer, even though three different parts of the IMO and three different sets of vendors own them.

Engine-room automation and condition-based maintenance

The unattended engine room is the oldest piece of smart shipping, and it is worth starting here because it shows the pattern the newer layers follow: a regulation sets a goal, a class society writes a notation, and a sensor-and-alarm chain does the work that a watchkeeper used to do by standing there. SOLAS Chapter II-1 Part E governs the periodically unattended machinery space, the engine room that is certified to run without an engineer continuously present. The rule does not remove the engineer; it lets the engineer be on call rather than on station, with the alarm system standing the watch and calling a human only when a parameter strays.

The certification is a class notation, and the notations differ by society, which trips up anyone reading a fleet list across owners. DNV writes E0, Lloyd’s Register writes UMS, ABS writes ACCU, and Bureau Veritas writes AUT-UMS, but they certify the same thing: that the machinery space meets the Part E standard for unattended operation. The notation requires a defined set of systems. An alarm and monitoring system that reaches the duty engineer’s cabin and the public rooms, so a fault wakes the right person. Automatic control of the main and auxiliary machinery, so the plant holds steady without a hand on the controls. Fire detection sized for an unmanned space, where a fire has longer to grow before anyone smells it. Bilge-level monitoring, because a flooding engine room with nobody in it is the classic unattended-space casualty. And bridge control of the propulsion, so the officer of the watch can change the engine order without an engineer at the controls below. The full treatment of those systems, the notations, and the IACS rules behind them sits in the engine room automation and monitoring cluster hub, and the existing machinery-side article is engine room automation: UMS and E0 systems.

The integrated automation system and the alarm chain

What ties the unattended engine room together is the integrated automation system (IAS), the supervisory software and the network of programmable controllers that read every sensor and drive every actuator in the machinery space. The IAS replaces the wall of discrete gauges and switches an older engine room carried with a set of operator workstations, on the bridge, in the engine control room, and in the duty engineer’s cabin, that show the same plant picture and raise the same alarms. The alarm and monitoring system (AMS) is the part that matters most for the unattended watch: it groups the thousands of monitored points, suppresses the cascade of consequential alarms that one root fault sets off, and escalates an unacknowledged alarm from the control room to the duty engineer’s cabin to the public rooms until a human answers. A badly designed alarm system that floods the operator with hundreds of simultaneous alarms in an upset is itself a hazard, which is why alarm management is a discipline of its own.

The same network that runs the plant is now a cyber-attack surface, because the controllers and the workstations are computers on a network. An unattended machinery space that can be reached from the ship’s business network, or from a contractor’s laptop plugged in for a software update, is exposed in a way the old hard-wired panel was not. That risk is the subject of the IACS Unified Requirements E26 and E27 on cyber resilience and of the wider maritime cyber security treatment, which sits beside this hub in the same security-and-technology portal.

Condition-based and predictive maintenance

The second half of engine-room automation is what the data does once it is collected, and the shift here is from maintaining on a calendar to maintaining on a condition. Traditional planned maintenance overhauls a component at a fixed interval set in running hours or months: the fuel injectors at so many thousand hours, the main-engine bearings at so many, whether or not the part shows any sign of wear. The interval is set conservatively, so the practice replaces a lot of serviceable parts early and still misses the occasional early failure that the clock did not predict.

Condition-based maintenance (CBM) instead reads the actual state of the machine and acts on it. Vibration analysis on a rotating machine reveals a developing bearing or alignment fault before it fails, and the ISO 10816 vibration severity zone calculator sorts a measured velocity into the A-to-D bands that trigger the alarm; lube-oil analysis counts the wear particles and contaminants that show what is wearing inside a closed crankcase, which the oil wear-metal alert levels calculator flags against ppm thresholds; exhaust-gas and cylinder-pressure monitoring shows a fuel-injection or combustion fault per cylinder; bearing and winding temperatures track a developing electrical fault. Predictive maintenance extends CBM with trend analysis that projects the remaining useful life of a component from the slope of its degradation, so the part is changed just before it would fail rather than on a fixed date. The commercial pull is direct: an owner that can defer the open-up survey of a machine on the strength of monitored condition data saves the cost and off-hire of the overhaul, which is why the IACS and class condition-monitoring schemes that allow survey credit for monitored machinery matter as much as the engineering. The full method, the notations, and the reliability arithmetic sit in the engine room automation and monitoring hub.

The watchkeeping picture this creates is the real change. A century ago an engine room held a continuous watch of several ratings and an engineer because the plant could only be monitored by a human standing among it. The unattended machinery space cut that to an on-call engineer plus the alarm system. The next step, the one the autonomy layer pushes toward, is removing the on-call engineer too, monitoring the plant from a shore center that watches many ships at once, which is exactly where the satcom and autonomy layers take over.

The shore monitoring center

The piece that joins engine-room automation to the autonomy layer is the shore monitoring center, and it is already in service on conventionally crewed fleets well ahead of any autonomous ship. An engine maker or a fleet operator runs a center ashore that receives the same plant data the ship’s own alarm system sees, streamed continuously over the satellite link, and watches it across dozens or hundreds of ships at once. The center does not control the machinery; it advises. When the trend on a main-engine bearing temperature or a turbocharger vibration crosses a threshold the center’s analysts catch it, often before the ship’s duty engineer would, and they call the ship with a recommendation. The major two-stroke engine designers and the large turbocharger makers offer this as a service, because the designer holds the fleet-wide failure data that lets it tell a developing fault from normal scatter, which a single ship’s crew cannot.

The center is the bridge from condition-based maintenance to remote operation in a literal sense: it is the same satellite-fed data feed, the same trend analytics, and the same shore-based watch that a remotely controlled ship needs, applied first to advice rather than control. The step from advising a crewed ship’s engineer to controlling an uncrewed ship’s machinery is large in law and liability but small in the data architecture, which is why the firms building autonomous-ship control centers are often the same ones that built the monitoring centers. The difference is the control authority and the latency budget: an advisory center can tolerate a feed that lags by seconds, while a center that closes the loop and acts on the plant cannot, and that latency requirement runs straight into the connectivity layer.

Satellite communication and vessel tracking

Nothing in the upper layers works without the link to shore, and the link is satellite. A ship a thousand miles from land is out of VHF and well out of any terrestrial network, so its only continuous connection is through a satellite overhead. Maritime satcom started as a safety system and grew into the operational backbone, and the regulation splits along that history: the safety side is the Global Maritime Distress and Safety System under SOLAS Chapter IV, and the operational and tracking side runs through the Automatic Identification System and Long-Range Identification and Tracking under SOLAS Chapter V. The full treatment sits in the satellite communication and vessel tracking cluster hub, with the equipment covered in AIS and ECDIS and the GMDSS overview.

GMDSS: the safety layer

The Global Maritime Distress and Safety System is the international framework that makes sure a ship in distress can raise the alarm and that a ship near a casualty hears it, automatically, wherever it is. It replaced the old manual radio watch on a single distress frequency with an automated system built around the ship’s position relative to shore coverage. GMDSS divides the world into four sea areas, and the carriage requirement, what radio equipment a ship must hold, follows the area it trades in. Sea area A1 is within VHF range of a coast station with continuous alerting, roughly 20 to 30 nautical miles. Sea area A2 extends to the range of a medium-frequency coast station, roughly out to 150 nautical miles. Sea area A3 covers the band of ocean inside the footprint of the geostationary satellite service used for GMDSS, broadly the latitudes between about 70 degrees north and 70 degrees south. Sea area A4 is the polar remainder beyond that footprint, where high-frequency radio carries the distress function.

The satellite element of GMDSS was historically the Inmarsat geostationary service, and a second provider, the Iridium low-earth-orbit network, was recognized for GMDSS service, which extended the satellite distress coverage into the polar A4 region that the geostationary footprint could not reach. The point worth holding is that GMDSS is the regulated, type-approved, safety-of-life layer of maritime satcom, distinct from the commercial broadband that carries the ship’s operational data, and a ship must carry the GMDSS equipment for its sea area regardless of whatever VSAT or LEO terminal it also runs for operations.

AIS, LRIT, and the tracking layer

The tracking side answers a different question: where is the ship, and who can see it. The Automatic Identification System (AIS) is a VHF transponder, required by SOLAS Chapter V on ships above defined thresholds, that broadcasts the ship’s identity, position, course, and speed to any receiver in range, other ships and shore stations, several times a minute. AIS was built for collision avoidance and traffic management, a ship sees the AIS targets around it on the ECDIS, but its signals are also picked up by satellites, which is how the commercial ship-tracking services map global traffic. The detail of AIS sits in the AIS and ECDIS article.

Long-Range Identification and Tracking (LRIT) is the other tracking system, and it works the opposite way to AIS. Where AIS broadcasts openly to everyone in range, LRIT reports a ship’s identity and position confidentially, by satellite, to its own flag administration and to the governments entitled to receive it under the SOLAS V regulation. LRIT is a security and search-and-rescue tool, not a navigation aid: a coastal state can see ships approaching its waters, and a flag state can track its fleet, without the open broadcast that AIS gives. The two systems together, the open VHF broadcast of AIS and the closed satellite report of LRIT, are how a ship is tracked, and they feed the vessel-monitoring picture that the satellite communication and vessel tracking hub assembles.

The LEO bandwidth step

The change running through satcom in the 2020s is bandwidth, and it is the change that makes the autonomy layer possible. The legacy maritime satellite services, Inmarsat and Iridium in L-band and the geostationary VSAT services in Ku and Ka-band, carry voice, email, weather routing, chart updates, and a moderate stream of operational data, which is enough to run a conventionally crewed ship. They are not enough to run a ship from shore. A remote operator controlling a degree-two or degree-three vessel needs continuous low-latency video from the ship’s cameras and a real-time feed of every navigation and machinery parameter, with a control channel reliable enough to bet a ship on, and a geostationary satellite sitting 35,786 kilometers above the equator imposes a round-trip latency that makes close-quarters remote control awkward.

Low-earth-orbit (LEO) constellations sit a few hundred to roughly two thousand kilometers up, far closer than the geostationary belt, which cuts the latency and, with hundreds or thousands of satellites in the constellation, lifts the available bandwidth by orders of magnitude. That step is what turns shore-based remote support from a demonstration into an operational tool: a shore center can now hold a live, high-resolution picture of a ship and act on it in near real time. The connectivity layer, in other words, had to mature before the autonomy layer could be built on it, and the LEO step is the enabler that the autonomous-ship projects of the mid-2020s were waiting on.

The regulated safety terminal and the commercial broadband terminal do different jobs, and the distinction is worth holding because the broadband link does not replace the safety one. A LEO broadband terminal carries the crew internet, the operational data, the condition-monitoring feed, and the remote-control stream, but as of 2026 it is not a recognized mobile satellite service for GMDSS, so it does not satisfy the SOLAS Chapter IV distress carriage requirement. The standard merchant fit therefore keeps a recognized GMDSS terminal, Inmarsat or Iridium, for distress and safety alongside the LEO link for everything else. A smart or autonomous ship runs both: the safety terminal because the convention requires it, and the broadband terminal because the autonomy and monitoring layers need the bandwidth.

E-navigation: the shore picture

The IMO’s e-navigation strategy is the regulatory frame this connectivity feeds into, and it predates the autonomy push. E-navigation is the harmonized collection, integration, exchange, presentation, and analysis of marine information on board and ashore, so that the ship and the shore see a consistent navigational picture rather than a scatter of separate displays and reports. The strategy’s point was to cut the clutter of overlapping bridge systems and to standardize how navigation data moves between ship and shore, which is exactly the data plumbing a remotely controlled or autonomous ship depends on. The autonomy layer did not create the shore-side navigation picture; it inherited it from the e-navigation work, then raised the bandwidth and control stakes on top of it. That inheritance is why the connectivity and navigation standards matter to the autonomy story as much as the decision logic does.

Autonomous ships and the MASS Code

The newest and least settled layer is autonomy, and the IMO’s term for the subject is the Maritime Autonomous Surface Ship (MASS). The word “autonomous” hides a spectrum, and the IMO’s first move was to define that spectrum so the regulation could talk about it precisely. The framework rests on two questions: are seafarers on board, and where does operational control sit. Those two questions generate the four degrees of autonomy, and a ship can move between degrees within a single voyage, manned and manual in confined waters, remotely supervised on passage. The full treatment, with the convention gaps and the trials regime, sits in the autonomous ships and the MASS Code cluster hub.

The four degrees of autonomy

The IMO defines four degrees, and the table sets each one against the two governing questions. The wording is the IMO’s own.

The structure repays a careful read, because the degrees are not a simple ladder of more-to-less automation. Degree one is most of the existing fleet: a modern ship with ECDIS, autopilot, track control, and collision-avoidance decision support is already a degree-one MASS under this definition, with a full crew aboard. Degrees two and three are the same thing, a ship run from a shore control center, distinguished only by whether a crew is aboard as a fallback. Degree four is the genuine leap, a ship that decides and acts on its own, and it is the degree furthest from any operational reality in 2026. The practical near-term targets are degrees two and three, the remotely controlled ship, which is why the remote operation center and its satellite link are the engineering heart of the autonomy problem rather than the artificial-intelligence decision logic that the word “autonomous” suggests.

The remote operation center

The remote operation center is where a degree-two or degree-three ship is actually run, and it inverts the old picture of the ship as a self-contained world. Instead of a bridge team aboard, a remote operator sits at a console ashore with a reconstructed bridge view: the radar and ECDIS picture, the AIS traffic, a ring of camera feeds standing in for the lookout’s eyes, and the machinery and navigation parameters streamed up from the ship. The operator’s job is to supervise the ship’s own automation and to take control when the automation hands off, the close-quarters situation it cannot resolve, the equipment fault, the order from a coastal authority. One operator may supervise several ships at once when all of them are on open-water passage, then drop to one ship in a busy approach, which is the staffing economics that makes the model attractive and the certification question that makes it hard.

Two failure modes define the center’s design. The first is the link drop: if the satellite connection fails, a degree-three ship with nobody aboard has to fall back on its own automation to hold a safe state, slow down, hold position, or stop, until the link returns, because there is no one aboard to take the helm. The second is the handover lag: when the automation passes a developing situation to a human operator who has not been actively steering, the operator needs time and situational context to take it in, and a center that hands off too late leaves no margin to act. Both push the engineering back onto the connectivity layer and onto the ship’s own fallback autonomy, which is why a remote operation center is only as good as the satellite link behind it and the on-board logic that covers the seconds the link cannot.

The MASS Code and its timeline

The IMO’s instrument for the field is the MASS Code, and the timeline matters because it sets what a project actually has to comply with today. The IMO adopted the MASS Code in non-mandatory form in May 2026, with effect from 1 July 2026, so the first edition is a goal-based but voluntary Code: it sets out the safety objectives and functional requirements for a MASS but does not yet bind. The plan from there is an experience-building phase, gathering the operational lessons from MASS operations under the non-mandatory Code, then development of a mandatory MASS Code from 2028, with adoption targeted by 1 July 2030 at the latest and entry into force on 1 January 2032.

The gap between voluntary now and mandatory later is the live commercial fact. An autonomous-ship project in 2026 does not run against a single binding autonomy rulebook; it runs against the non-mandatory MASS Code plus the full existing body of mandatory convention law, SOLAS for safety, the COLREGs for collision avoidance, STCW for crewing and watchkeeping, and the rest, none of which was written with an uncrewed ship in mind. National administrations and class societies bridge the gap with their own MASS rules and with the flag-state approval that any specific project still needs. The history of the work runs through the regulatory scoping exercise the IMO completed and recorded in MSC.1/Circ.1638, which went through the existing conventions instrument by instrument to find the provisions that assume a crew on board, and through the interim guidelines for MASS trials in MSC.1/Circ.1604 of 14 June 2019, which set the terms under which a flag state can authorize a trial of an autonomous ship in real waters.

The convention gaps: COLREGs and crewing

The regulatory scoping exercise found that the hardest problems are not in the high-tech autonomy systems but in the old conventions that take a crew for granted. The clearest case is the COLREGs, the International Regulations for Preventing Collisions at Sea of 1972, which apply to every vessel and are built around a human watch. Rule 5 requires every vessel to keep a proper lookout by sight and hearing as well as by all available means; Rule 7 requires the watch to determine whether risk of collision exists; Rule 8 requires action to avoid collision to be positive, made in ample time, and readily apparent to another ship watching. Each of those duties was written for an officer of the watch on a bridge, and each has to be reinterpreted for a system that has no eyes, no ears, and no bridge. Deciding how an automated system satisfies the duty to keep a proper lookout is one of the central open questions of the MASS work, not a settled matter.

The crewing conventions raise the parallel problem. STCW sets the certification and watchkeeping standards for seafarers, and the safe-manning rules assume a defined crew aboard; a degree-three ship with nobody on board does not fit a framework built around the qualifications and rest hours of the people standing the watch. The shore-based operator in a remote control center is a new category that the conventions did not anticipate: what certification that person needs, how many ships one operator may supervise, and how the responsibility splits between the shore operator and the ship’s own systems are questions the MASS Code has to answer. These are the reasons autonomy is the least settled of the three layers and depends on regulatory development as much as on engineering, and they are worked in full in the autonomous ships and the MASS Code hub. The bridge-side equipment that the autonomy systems extend, the radar, ECDIS, AIS, and watch-alarm chain, sits in AIS and ECDIS and BNWAS.

Where smart shipping meets decarbonization and security

Two adjacent fields press hard on this cluster, and naming the overlap keeps the boundaries honest. The first is decarbonization. The same sensor-and-analytics chain that drives condition-based maintenance also drives fuel and emissions optimization: a ship that monitors its hull, propeller, and engine condition closely can trim the fuel it burns and the carbon it emits, and the voyage-optimization and just-in-time-arrival tools that cut emissions run on the connectivity layer this hub describes. The technology side of that effort sits in decarbonization technologies, which works the energy-efficiency and alternative-fuel hardware that the data layer helps run.

The second is security, and the overlap there is the sharper one. Every layer of smart shipping adds an attack surface. The integrated automation system is a network of computers in the engine room; the satcom link is a path from shore onto the ship; the autonomy control channel is a remote operator’s command stream that an attacker would dearly love to reach. The more control moves from the deck plates to the data layer, the more a cyber compromise can do, which is why maritime cyber security sits in the same portal as this hub rather than off in a corner. The IACS Unified Requirements E26 and E27 on cyber resilience apply to the computer-based systems this hub describes, and an autonomous or heavily automated ship cannot be certified safe without treating its cyber resilience as part of its basic safety case.

How the three cluster hubs fit together

This hub is the map; the detail lives one level down in three cluster hubs, and they read in the maturity order the layers were built in. Start with engine room automation and monitoring, the mature base: the SOLAS Part E unattended-machinery-space rules, the UMS and E0 notations, the integrated automation and alarm systems, and the condition-based and predictive maintenance that the sensor data feeds. It is the layer that proves the pattern smart shipping follows, a regulation setting a goal and a sensor chain doing the human’s old job.

Then satellite communication and vessel tracking, the nervous system: GMDSS and its sea areas, the Inmarsat, Iridium, and VSAT services, the AIS and LRIT tracking that show where every ship is, and the LEO bandwidth step that lifts the shore link from moderate data to real-time video. It is the layer that connects the ship to the shore at all, and the enabler that the autonomy layer waited on.

Last autonomous ships and the MASS Code, the frontier: the four degrees of autonomy, the non-mandatory MASS Code of 2026 and the mandatory Code targeted for 2030 to 2032, the remote operation center, and the COLREGs and crewing-convention gaps the regulatory scoping exercise exposed. It is the layer that depends on the other two and is least settled in law, and it is where the human finally steps off the ship.

Across the wider portal the links run on. The connectivity and automation layers feed the emissions-cutting hardware in decarbonization technologies; the attack surface every layer adds is the subject of maritime cyber security; and the bridge equipment the autonomy systems extend sits in AIS and ECDIS, the GMDSS overview, and BNWAS.

Limitations

This article maps the smart-shipping field and the rules that govern each layer; it is not a substitute for the SOLAS text, the class society’s automation and autonomy rules, the IMO MASS Code as adopted, or the flag administration’s approval for a specific project. The class notations named here, E0, UMS, ACCU, and AUT-UMS, certify the unattended-machinery-space standard, but each society’s rule has its own detailed requirements, and the controlling document for any ship is that society’s rule and the ship’s class record, not a general description.

The MASS Code position stated here reflects the non-mandatory Code adopted in May 2026 with effect from 1 July 2026 and the IMO’s stated plan for a mandatory Code developed from 2028, targeted for adoption by 1 July 2030 and entry into force on 1 January 2032. Regulatory timelines at the IMO move with the committee schedule and can shift, and the binding law for any autonomous-ship project today remains the existing SOLAS, COLREGs, and STCW conventions read with the non-mandatory Code, plus whatever national and class rules and flag-state approval the specific project requires. The four degrees of autonomy are the IMO’s definitions and are a framework for talking about MASS, not a certification scheme in themselves.

The satcom description gives the general shape of GMDSS, AIS, and LRIT and the LEO bandwidth shift; the carriage requirement for any ship is set by its sea area and the SOLAS regulation, and the specific equipment that satisfies it is the type-approved hardware its flag accepts. None of the linked calculators replaces the class rule, the convention text, or the flag-state approval for a real ship.

See also

• Engine room automation and monitoring: the unattended machinery space, UMS and E0 notations, and condition-based maintenance.
• Autonomous ships and the MASS Code: the four degrees of autonomy, the MASS Code timeline, and the convention gaps.
• Satellite communication and vessel tracking: GMDSS, the satcom networks, AIS and LRIT, and the LEO bandwidth step.
• Engine room automation: UMS and E0 systems: the machinery-side treatment of the unattended engine room.
• AIS and ECDIS: the bridge navigation and identification equipment.
• GMDSS overview: the Global Maritime Distress and Safety System and its sea areas.
• BNWAS: the bridge navigational watch alarm that backs the watchkeeping duty.
• Maritime cyber security: the attack surface every smart-shipping layer adds.
• Decarbonization technologies: the energy-efficiency and alternative-fuel hardware the data layer helps run.
• PMS completion rate calculator: the planned-maintenance completion ratio behind survey-credit schemes.
• MTBF & MTTR calculator: the reliability metrics that drive the predictive-maintenance decision.