Autonomous cargo ship using AI navigation, radar, LiDAR, embedded systems, satellite communications, and maritime cybersecurity technologies to transport cargo at sea.

Autonomous Cargo Ships: How AI, Embedded Systems, and Sensors Could Transform Global Shipping

ByImran Valiani

Autonomous vessels rely on far more than artificial intelligence. They require radar, LiDAR, machine vision, edge computing, satellite communications, cybersecurity, and redundant control systems to safely navigate the world’s busiest shipping lanes.

Autonomous cargo ships are no longer a thought experiment — one is already hauling real freight on a fixed route in Norway, under a mix of AI, human oversight, and hardware most explainers skip over.

In April 2022, a 260-foot container ship was christened in Brevik, Norway. Crown Prince Haakon was there. Five hundred local schoolkids watched. The ship was the Yara Birkeland — widely described by its owner as the world’s first fully electric, autonomous-capable container vessel — and it was about to start hauling fertilizer between two Norwegian ports.

Worth flagging up front: unmanned and remotely operated vessel research goes back further than this ship, in naval and experimental programs. What made the Yara Birkeland different wasn’t being first to attempt autonomy — it was being the first commercial demonstrator to put the whole technology stack to work hauling real cargo, in public, under a name people would recognize.

Here’s the thing though: this autonomous cargo ship didn’t sail empty of people. Not at first, anyway. Yara’s own reporting states the ship currently operates with a crew of three, expected to drop to two as remaining crew move ashore to the Horten Remote Operations Center — the long-term goal is zero crew on board (Source: Yara International, “Yara Birkeland, two years on”). A “launched with five crew” figure appears in some secondary coverage of this vessel, but I checked Yara’s own page directly, and it doesn’t state that number, so I’m not including it as confirmed. Autonomy, it turns out, isn’t a switch you flip. It’s a slow, deliberate handoff.

So what actually gets a cargo ship from “crewed with fancy sensors” to “sails itself”? Not just AI. That’s the part most explainer articles skip.

Autonomous Cargo Ships: The Vessel That Started the Public Conversation

Quick recap, because the specs matter. The Yara Birkeland is roughly 80 meters long, carries up to 120 TEU — Twenty-foot Equivalent Units, the standard measure of container capacity, not a count of individual boxes — of fertilizer (Source: Yara International; Baird Maritime, “Vessel Review: Yara Birkeland”). Yara’s own page states battery capacity directly as 6.8 MWh, powering two 900kW Azipull pods and two 700kW tunnel thrusters for a max speed of 15 knots; that’s the figure I’m treating as authoritative, since it comes straight from the operator rather than secondary reporting.

Leclanché, the battery manufacturer, independently confirms the same 6.8 MWh figure and identifies the system as its Marine Rack System (MRS-2) (Source: Leclanché). A separate secondary source cites 6.7 MWh, and Vard’s own page separately lists “7000 kW” — a power figure, not an energy figure, so it isn’t directly comparable to the MWh numbers regardless. Given Yara and Leclanché agree, I’m not treating this as an open discrepancy anymore. It travels an 11-nautical-mile route between Herøya and Brevik. Built by Vard, with Kongsberg Maritime supplying the sensor and control systems (Source: Vard; Ship Technology).

The autonomy trial has taken longer than planned. In an April 2024 update, Yara said the trial period — originally slated to finish by the end of 2024 — was still ongoing, with expectations it would be close to completion by early 2026 (Source: Yara International, “Yara Birkeland, two years on”). Concretely, by that update the ship had completed its first fully autonomous voyage under human supervision (March 2023), and its Auto-Docking and Auto-Crossing functions were operational, though mooring was still done manually with robotic mooring arms in testing. I don’t have a source newer than that April 2024 update confirming whether the trial has since been completed or a certification issued, so I’m presenting this as Yara’s stated 2024 expectation rather than a current, confirmed status as of this writing.

Separately, battery supplier Leclanché marked the ship’s third anniversary in May 2025 with a press release describing “supervised Auto-Docking and Auto-Crossing” as achieved milestones (Source: Leclanché) — real progress, but a vendor’s anniversary press release isn’t the same claim as a completed autonomy trial or issued safety certificate. Regulations didn’t exist yet for a ship like this when the project started. That delay tells you almost everything about why this technology is hard — not because the AI can’t drive the boat, but because proving it’s safe enough is its own multi-year project.

What Actually Lets a Ship “See”?

Ask most people how a self-driving ship works, and they’ll say “AI.” Fair enough. But AI is the decision layer. It’s useless without the hardware feeding it a picture of the world.

Autonomous vessels build that picture through sensor fusion — combining several sensor types so the weaknesses of one get covered by the strengths of another. According to Ship Technology’s project documentation on the Yara Birkeland, the navigation suite includes:

  • Radar — generally more resilient than optical cameras in darkness and moderate poor visibility, though heavy precipitation and sea clutter can still reduce its performance
  • LiDAR (light detection and ranging) — sharp spatial accuracy, but degrades in heavy weather
  • AIS (Automatic Identification System) — other vessels broadcasting their own position and identity
  • Machine vision cameras — for close-range object recognition
  • Infrared cameras — for low-visibility and night conditions

(Source: Ship Technology, “YARA Birkeland Autonomous Container Vessel”)

Worth being direct about AIS specifically, since it’s easy to describe too generously: it’s self-reported data. A vessel can misreport its position, fail to broadcast at all, or in rarer cases have its signal spoofed or falsified. Small craft and floating debris often carry no AIS transponder whatsoever. A navigation system that trusted AIS at face value would be trusting a source that can simply be wrong — which is a real design problem, not a hypothetical one. That’s exactly why it’s one input among several rather than a stand-in for ground truth.

Combining these sensor types can improve overall observability and catch failure modes that any single sensor would miss on its own. But it’s worth resisting the tidy version of that story — “none of these alone is trustworthy, together they are” sounds satisfying, but it overstates what fusion buys you. Several of these sensors can degrade together under the same conditions: heavy rain affects both radar returns and camera clarity, sea spray fouls both LiDAR and camera lenses, and a GNSS problem can quietly corrupt the position data every other system relies on for context. Real safety cases have to account for these shared, correlated failure modes — not just assume that stacking sensor types automatically cancels out their individual weaknesses. The same fusion problem, and the same correlated-failure risk, shows up in the air as well as at sea — delivery drones run the identical radar/LiDAR/vision stack through the same rain and fog that degrade a ship’s sensors.

Autonomous cargo ships sensor fusion diagram showing radar, LiDAR, AIS, machine vision, and infrared feeding an AI situational awareness system with remote human oversight
How sensor fusion feeds the AI situational awareness system on an autonomous cargo ship like the Yara Birkeland — illustrative, based on publicly documented systems, not a confirmed equipment manifest.

The Brains Onboard

Here’s where embedded systems come in. All that sensor data has to get processed somewhere, and on a ship, “somewhere” usually means onboard, in real time, with no room for a laggy cloud round-trip. This is edge computing in its most literal sense — dedicated compute, physically installed on the vessel.

I don’t have a documented source naming the exact processors, operating system, or compute architecture used aboard the Yara Birkeland specifically, so I won’t invent one — that would be exactly the kind of confident-sounding but unverifiable detail this article has been correcting elsewhere. What is generally true of this class of problem, and worth naming rather than gesturing at: real-time sensor fusion and navigation decision-making on a moving vessel typically calls for a mix of general compute for the AI/perception workload and separately partitioned, deterministic control systems for anything safety-critical.

Steering and propulsion commands shouldn’t share a failure domain with a perception model that’s still being validated. That partitioning between “best-effort AI workload” and “deterministic, safety-rated control” is a standard embedded-systems pattern, not something unique to ships, but it’s a real constraint that a beginner-level explainer shouldn’t skip past.

The physical electronics carrying all this also have to survive the marine environment specifically. Salt air, constant vibration, temperature swings, and moisture aren’t just an engineering vibe — there’s a real standard behind it. Navigation and radiocommunication equipment on ships is evaluated against IEC 60945, the international standard covering environmental and EMC testing (temperature cycling, humidity, salt mist, vibration, and ingress protection) for that category of equipment specifically (Source: International Electrotechnical Commission; TÜV SÜD testing documentation). It’s worth being precise about scope here: IEC 60945 applies to navigation and radiocommunication equipment as defined by its own scope — not automatically every controller, power converter, or general-purpose compute box anywhere on the ship.

Other onboard electronics may be governed by different classification-society rules, IMO performance standards, or manufacturer-specific environmental categories depending on function and installation location. And passing IEC 60945 testing is one input into class-society type approval, not an automatic guarantee of it — full approval typically also depends on the applicable class rules, documentation, and installation-specific requirements. At the board level, marine electronics manufacturers may use IPC standards — such as IPC-A-610 for assembly acceptability and IPC-CC-830 for conformal-coating qualification — alongside applicable IEC, classification-society, and customer-specific requirements to manage the corrosion and vibration risks of a salt-air environment, though I don’t have a source confirming which specific IPC class or coating spec any particular Yara Birkeland subsystem was built to, or how universally marine suppliers reach for these particular documents versus other paths to the same environmental requirements.

The AI situational awareness system on the Yara Birkeland is described by Yara as the layer that takes fused sensor data and supports navigation decisions — the company’s own language covers detection, tracking, and situational awareness (Source: Yara International). I don’t have a source spelling out exactly how much of the final steering and propulsion command authority sits with that AI system versus a human operator versus separate deterministic control logic, so I’m not going to state a precise division of authority I can’t back up. What’s documented is that it works alongside remote human oversight, not in isolation.

Staying Connected, From Shore

Even a highly autonomous ship needs a lifeline back to land. The Yara Birkeland is monitored from the Horten Remote Operations Center, which Yara’s own reporting confirms opened to house crew who’ve moved ashore as onboard headcount shrinks (Source: Yara International). I don’t have a source clearly documenting the center’s certified takeover authority — exactly what command capability it holds and under what conditions — so I’ll describe its confirmed role rather than overstate it: it’s set up for monitoring and operational oversight of the vessel, functioning something like an air traffic control tower for one very patient ship. Whether and how it can take direct remote control, and under what authorization, isn’t something these sources spell out in detail.

Early design documents describe the communications stack as a mix of maritime broadband radio and a VPN connection routed through Inmarsat, the satellite communications provider (Source: Ship Technology). It’s worth correcting a shortcut I almost made here: satellite isn’t the only offshore communications option in general — ships also use coastal 4G/5G near shore, VHF/UHF data links, and other radio systems depending on range and location. Satellite systems generally form a major long-range connectivity layer for ocean-going autonomous ships specifically; the Yara Birkeland itself runs an 11-nautical-mile coastal route, where terrestrial and maritime radio coverage may also be available, so this isn’t necessarily describing what this particular short-route vessel requires at every moment. Connection quality for the longer-range case still varies with weather, satellite constellation geometry, and terminal type.

Locking the Doors: Why Cybersecurity Isn’t Optional

Here’s an uncomfortable thought experiment. If a ship can be controlled remotely, it can — in theory — be hijacked remotely. That’s not paranoia; it’s an engineering requirement.

Global shipping regulators have taken this seriously for a while now, and the guidance has kept moving — recently, as it turns out. IMO Resolution MSC.428(98) required cyber risk to be addressed within ship owners’ and operators’ existing safety management systems, specifically by the first annual verification of a company’s Document of Compliance after January 1, 2021 (Source: International Maritime Organization). That resolution is still in force, but the detailed guidance built on top of it has been revised twice more since then.

IMO’s Guidelines on Maritime Cyber Risk Management were substantially revised as MSC-FAL.1/Circ.3/Rev.3 on April 4, 2025 — and then revised again as MSC-FAL.1/Circ.3/Rev.4, approved by IMO’s Facilitation Committee (50th session, March 2026) and Maritime Safety Committee (111th session, May 2026), and issued May 28, 2026 (Source: IMO, verified by fetching the circular directly). Rev.4 is the version that actually adds a sixth functional element, Govern, ahead of the original five (Identify, Protect, Detect, Respond, Recover) — which matches the six-function structure of NIST Cybersecurity Framework 2.0. I’d previously written that Rev.3 made this change and that I couldn’t confirm Rev.4 existed; both of those were wrong. My search tool didn’t surface the Rev.4 document on the first two passes, and I stated that absence with more confidence than it deserved. Fetching the actual circular directly settled it.

But policy guidance isn’t the same as an engineering spec, and neither is really a threat model. Framing the risk purely as “a remotely controlled ship could in theory be hijacked” undersells what a realistic attacker would actually target. A more useful list, admittedly non-exhaustive: GNSS jamming or spoofing that corrupts the position data every other system relies on — a threat DHS has documented as already affecting maritime and aviation sectors alike, with automotive now catching up to the same problem; falsified or manipulated AIS messages, since AIS is self-reported and not authenticated; compromised or malicious software updates reaching safety-critical systems; credential compromise on remote-access links into the ship’s network; and supply-chain risk, where a vulnerability gets introduced through a supplier’s equipment or a maintenance laptop rather than through the ship’s own perimeter.

None of that is exotic — it’s the standard threat-modeling exercise for any networked, remotely-operable system, maritime or not, and a hardware-security-hardening approach for this category of vessel typically leans on things like signed and verifiable software updates, a hardware root of trust for secure boot, and physical segmentation between navigation/control networks and less-critical IT systems. I don’t have a source confirming which of these specific measures the Yara Birkeland program has implemented, so I’m describing this as the general shape of the problem, not this vessel’s specific defenses.

The concrete requirement that actually governs hardware and system design for new vessels is IACS UR E26 and E27 — UR E26 (“Cyber Resilience of Ships”) and UR E27 (“Cyber Resilience of On-Board Systems and Equipment”), effective for new ships contracted for construction on or after July 1, 2024 (Source: IACS). To state the scope precisely: UR E26 applies at the ship level — asset inventory, vulnerability management, incident response, structured around five functional elements (Identify, Protect, Detect, Respond, Recover) — while UR E27 places product-level hardening requirements on individual onboard systems and equipment supplied to those ships, not literally “every computer-based system” without qualification; applicability is determined by the URs’ own scope and system categorization. UR E27 pushes the requirement down to suppliers, meaning the vendor building a navigation sensor or propulsion controller has to harden it before it ships.

Autonomous ships raise the stakes further, since the attack surface now includes the navigation AI, the sensor network, and the shore-to-ship communication link — not just a crew laptop. Zero Trust — continuous verification of every device and connection rather than trusting anything by default once it’s “inside” the network — fits naturally with UR E26’s asset-inventory and detection requirements, though I don’t have a source stating IACS mandates Zero Trust by name, so treat that connection as my own read of the requirements rather than a direct citation.

Redundancy: Planning for Things to Break

No single point of failure. That’s the mantra — and it isn’t just internal engineering philosophy; it’s enforced from outside, at least for the systems the rules actually name. Classification societies (DNV, Lloyd’s Register, ABS, and others) assess vessels and equipment against class rules and may carry out statutory work when authorized by a flag administration — actual legal authority to operate ultimately rests with flag states, not the classification society alone. Redundancy, segregation, and availability requirements apply to designated safety-critical systems under those rules; it isn’t a blanket guarantee that eliminates every single point of failure across every system and mode.

What redundancy looks like on a vessel like this, based on what’s publicly documented:

  • Two Azipull propulsion pods plus two tunnel thrusters (Source: Baird Maritime) — a standard multi-thruster layout; the specific “so one failure can’t strand the ship” rationale is a reasonable engineering read rather than something stated outright in these sources, and true redundancy would also depend on whether the pods share a battery bus, cooling loop, or control computer — details these sources don’t cover
  • Multiple sensor types covering the same detection task, with the correlated-failure caveat noted above
  • A Remote Operation Center in Horten confirmed by Yara’s own reporting (Source: Yara International) — worth phrasing carefully rather than as an unconditional guarantee: a shore-based operator can only intervene when the communications link, ship systems, and operating authorization all permit it, and these sources don’t spell out the center’s exact certified takeover authority. The remote link itself is a potential point of failure, not a backup that exists independently of the systems it’s backing up.
  • A multi-year, crewed trial period specifically because handing off control gradually — with people aboard to catch what the automation gets wrong — is how the operator and regulators are building the evidence base needed for eventual certification (Source: Yara International)

Worth being precise about that last point: the trial isn’t redundancy in the engineering sense of a backup system. It’s closer to a regulatory and evidentiary process — building the demonstrated, monitored track record that autonomous operation typically requires before certification. Hardware redundancy and certification process are related but distinct concepts, and it’s easy to blur them in casual explanation.

Where the Regulations Stand Right Now

This part moves fast, so it’s worth pausing on. In May 2026, the IMO adopted a new International Code of Safety for Maritime Autonomous Surface Ships — the MASS Code — under resolution MSC.595(111), available for voluntary application starting July 1, 2026 (Source: IMO). Precision matters here: it’s non-mandatory, so “took effect” can sound more binding than it is — a more accurate phrase is that it became available for voluntary use by flag states and operators. It’s a goal-based framework, meaning it sets safety outcomes for autonomous cargo ships rather than prescribing exact hardware, and in its current form it applies specifically to cargo ships under SOLAS (Source: IMO). Application to passenger vessels has been deferred for now.

The mandatory version has a specific target, not just a vague “later in the decade”: IMO is aiming to adopt a mandatory MASS Code by July 1, 2030, with entry into force planned for January 1, 2032, via SOLAS amendments (Source: IMO; SAFETY4SEA reporting on MSC 111). Between now and then sits what IMO calls an Experience-Building Phase, meant to generate the real-world operating data the mandatory code will be built on.

That timeline matters if you’re trying to understand why most autonomous cargo shipping today still looks like “reduced crew with heavy automation” rather than “empty ship, full autonomy.” What’s documented: the non-mandatory MASS Code took years longer to finalize than the original 2025 target. Whether that pace reflects deliberate caution or the ordinary friction of international rulemaking is a matter of interpretation, not something stated outright in the source material.

Autonomous Cargo Ships: What This Means If You’re Just Getting Into the Topic

A few starting points worth holding onto:

  • Autonomous cargo shipping today is really remote-assisted shipping, phasing toward full autonomy over years, not overnight
  • The AI navigation system is only as good as the sensor fusion feeding it — and fusion reduces risk; it doesn’t eliminate it, since some failure modes hit multiple sensors at once
  • Marine-grade electronics face a distinct combination of salt, vibration, and long service life that general commercial hardware isn’t built for — but “marine-grade” isn’t one single certification; it’s a stack of overlapping standards depending on what the equipment does and where it sits on the ship.
  • Satellite links are the backbone of long-range shore connectivity for a ship like this, alongside other radio and coastal options closer to port.
  • Cybersecurity today means more than a policy resolution — GNSS spoofing, AIS falsification, and software supply-chain integrity are the concrete engineering problems underneath the compliance language.
  • Regulation, specifically the IMO’s MASS Code, has a real mandatory timeline now: voluntary from July 2026, mandatory adoption targeted for 2030, entry into force planned for 2032

The Yara Birkeland isn’t a finished product. It’s closer to a very expensive, very public proof of concept — one small ship on one short Norwegian route, carrying the weight of an entire industry’s next chapter. Whether that chapter reads “fully autonomous global shipping” or “heavily automated, still crewed shipping” depends less on the AI model and more on the unglamorous stuff: sensors that don’t fail, links that don’t drop, and a code of safety that doesn’t get written until people are confident it’s actually safe.

About the Author

Imran Valiani | Sales Director, PCB Electronics Manufacturing — 20+ years working with major Bay Area and global tech clients. Founder of Silicon to Software, where I write about the hardware layer — PCB fab, AI gear, autonomous systems, and cyber — the stuff most tech writers have never touched. Literally. Follow: X @SiToSoftware | LinkedIn

This post was written with AI assistance. See my full AI disclosure.

Sources

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *