From the magazine – This February, the bulk carrier MS Viikki worked its way through ice toward the port of Raahe. Several hundred kilometres south, colleagues in Turku watched it on a wall of screens. They could have been piloting the vessel from shore. They weren’t, not yet. What separates could from will is no longer a hardware problem. A designer’s notes from a Finnish research project on shore-based pilotage.
This article was part of our nautical developments special in SWZ|Maritime’s June 2026 issue. It was written by Iiro Törmä, UX/UI designer and researcher at the Faculty of Technology and Seafaring, Novia University of Applied Sciences, Finland.
Remote pilotage, guiding a vessel through hazardous waters from a chair ashore rather than the bridge, has been discussed for decades and trialled in fragments for almost as long. The Netherlands has run shore-based pilotage for years. In May 2025, Denmark’s DanPilot began what it calls the world’s first commercial trial, an eighteen-month programme in the Kattegat and western Baltic. Finland’s regulatory framework already permits it, and Finnpilot, the state-owned national pilotage company, is preparing to move towards service.
What has changed in the last few years is the quality of the evidence that remote pilotage can be made to work in demanding fairways with available technology. The 2022 Sea4Value project showed that the necessary ship-to-shore data integration was achievable with off-the-shelf components. Our Remote Pilotage Minimum Viable Product (MVP) project, funded by Business Finland and concluded at the end of 2025, reached the same conclusion, with conditions. Those conditions are where the interesting problems live.
Also read: Denmark first to launch remote pilotage
Safe and affordable
The project was held together by two commitments: the system had to be at least as safe as conventional pilotage, with the full safety expectation the industry places on a pilot on the bridge, and it had to be affordable: buildable now, with available technology, at a price pilot organisations and shipping companies could realistically meet.
Novia University of Applied Sciences led the research, with Finnpilot and Fintraffic as operational partners, ESL Shipping providing the test vessel, and Furuno, Groke Technologies and Brighthouse Intelligence the technological components. The aim was not a product, but a supplier-independent reference model that others could implement within a ten-year horizon.
I came to the work as a human-centred designer. I am close enough to the maritime conversation to follow it and far enough to keep asking why things are done as they are. That is a useful perspective on a system in which operational, technical, regulatory, and human components are tightly intertwined.
Towards verified preparation
Consider the master-pilot exchange (MPX), the structured exchange in which a pilot boarding a vessel confirms passage plan, contingencies, communication language, and berthing arrangements with the master. In conventional pilotage, how thoroughly the exchange is conducted is largely at the pilot’s discretion; the standard is met when the pilot is satisfied that it has been.
Remote pilotage cannot rely on that latitude. With no shared bridge to fall back on, the preparation has to be verifiably done. Vessel and crew must be confirmed as fit and certified. The pilotage plan must be a shared, formally accepted baseline before the operation begins. The steering-mode strategy, whether to use autopilot or hand-steering, must be agreed for each fairway segment. Voice allocation to the Vessel Traffic Service must be settled, and suspension criteria put in place.
And it should happen the same way every time. That single shift, from discretionary preparation to verified preparation, is one of the things that most clearly separates remote pilotage from the practice it is described as continuous with.
Loss of implicit channels
Our primary research site was the Aboa Mare simulator centre in Turku. Between autumn 2024 and spring 2025, we ran seventeen exercises: Eight conventional pilotage baseline runs, six remote pilotage runs from a project-built Remote Operations Centre, and three on collaboration with the Finnish VTS. Three licensed pilots took turns piloting. The exercises were planned for their respective “home fairways”. Bridge teams (master + co-pilot) in the remote runs were deliberately less experienced than the pilot. The pilots and the crews were unfamiliar to each other. We collected eyetracking data, ceiling video, wireless audio, NASA-TLX workload ratings, and debriefs.
The remote runs were designed harder than the baseline so the cost of cognitive load would be visible: instructors injected GPS drift, gyro faults, AIS failures, sudden fog, and an intentional steering error to be caught from shore. Half the remote runs ran without a visual feed for the pilot. These were described by participants asamong the most demanding piloting they had ever done. Rudder-angledata were unavailable to the remote pilot throughout, an unintended preview of remote pilotage when an essential feed is missing.
The principal cost of remote pilotage falls on cognitive workload. The remote pilot loses the implicit channels of co-presence such as a glance at the master’s posture to confirm an order has landed or the felt response of the vessel to wind and current, through which conventional pilotage continually checks itself. That information has to be reconstructed via instrumentation or verbal exchange, and verbal exchange has finite capacity. It competes with VHF, internal bridge talk, and the master’s own thinking. Pilots tolerate cognitive demands by professional habit and are disinclined to report overload, which makes the limit hard to see from the outside and easy to cross.
Also read: MARIN: Remote-controlled ships still require crew
THE MVP PROJECT RECOMMENDATIONS AT A GLANCE
- Training and certification. Establish a distinct competence standard and certification track for remote pilots. Certify vessels for remote pilotage based on technical readiness and required onboard equipment. Apply eligibility requirements to masters and crews based on seafaring experience and familiarity with remote pilotage.
- Technology. Build redundant connectivity. Give the remote pilot visibility into bandwidth use and the ability to disable subsystems under strain. Equip the Remote Operations Centre with vessel forward camera display, radar, conning and chart displays with data status/latency indication. Provide an accessible information logging system for the pilot.
- Preliminary arrangements. Restrict service to fairways of manageable complexity. Confirm vessel, crew, and system eligibility before each operation.
- Preparation. Complete the master-pilot exchange before operation and treat it as a formally accepted shared baseline. Agree steering-mode strategy per fairway segment, voice allocation, and suspend/abort triggers before start. Conduct a pre-start technical check confirming that ROC indications match ship behaviour within expected latency.
- Coordination with VTS. Remote pilotage does not change the responsibilities of VTS. Apply a one-voice-to-VTS principle for each leg. Make any handover of that voice explicit and timed.
- Navigation and communication. Use closed-loop readback for safety-critical exchanges. Maintain channel discipline against overlapping audio streams. Set minimum manning to avoid crew cognitive overloading.
Communication is key
One run has stayed with me, not for a flattering reason. I was an observer on the Teams call between simulator bridge and pilot while taking a phone call with a colleague, and had left the laptop microphone open. For several minutes, I doubled the audio load on a team already managing two streams while the master worked through stacked technical problems. Shared situational awareness collapsed. Thinking and orders were repeatedly interrupted by my unintended disturbance. No one taking part in the actual scenario acted incorrectly. The breakdown emerged from a small failure of microphone discipline by an observer who should have known better. Designed scenarios are useful, but the real failure modes will be unscripted.
That run convinced me that the most important finding of the project is not technical. Our final report names it directly: communication plays an outsized role in remote pilotage safety. Many of our recommendations such as closed-loop readback, channel discipline, a one-voice-to-VTS principle, an adapted master-pilot exchange, prestart acceptance of the route plan, and minimum manning to keep the master from being saturated, are attempts to reinforce communication against the conditions that can make it fail.
With colleagues at Novia, I led one constructive response: a briefing tool that lets remote pilot, bridge team and VTS walk through a route in 2D and 3D before the transit, externalising the local knowledge a pilot normally holds internally and serves piecemeal. It does not solve the communication problem, but it shifts some of its load away from the moment it can least be afforded.
Also read: SWZ|Maritime’s June 2026 issue: Who’s steering?
Building trust
The other adjustment the system asks is in trust. In conventional pilotage, trust forms incrementally: a handshake, the MPX, the way the officer of the watch responds to a heading order. Most signals are small and non-verbal: A posture, a hesitation, the speed of a readback. The pilot reads the team and the team reads the pilot, and the relationship does much of the quiet work of keeping the operation safe.
Remote pilotage cannot rely on this. Even when video is provided, the workflow tends to push faces off the screen. Participants frequently used the Teams link only for the shared map. They had watched each other’s face quite enough, as one put it.
Jukka Häkkinen, our human-factors researcher, observes that under load, the bridge tends to resolve matters among themselves and inform the pilot afterwards. We saw a domestic version: master and co-pilot dropping their voices to talk among themselves, switching from English to Finnish, then switching back to address the pilot. Each move is reasonable in isolation; together, across an hour of dense traffic, the remote pilot was transformed from co-participant to just a voice in a speaker.
The simulator runs gave hints of trust formation under deliberately difficult conditions. They could not study how a working confidence develops between a remote pilot and a regularly visiting bridge team, or what role standardised procedures and demonstrated certification play in establishing it. Those are among the questions the next phase of work will need to take up.
The simulator is powerful, but bounded. Real connectivity, real cameras, and the actual behaviour of a ship needed live work. Four tests were run on MS Viikki on the Raahe fairway between June 2025 and February 2026, two as formal validations – not remote pilotage in the operational sense, but checks that the infrastructure could carry one. The situational-awareness camera with RGB and thermal image blending was the most convincing single component we tested. In difficult light, the view from shore was possibly even better than the one from the bridge. Voice over Teams was stable.
But the tests exposed a gap that the simulator could not. Between an infrastructure that can carry remote pilotage and one a remote pilot can trust to do so. A pilot needs to know without hesitation whether their instruments are working, and that places demands on the whole information architecture beyond simply making components function.
What kind of working life?
The technical path is visible. The harder work is sociotechnical; training, for remote pilots and equally for the masters and officers who will work with them; communication discipline, which under pressure is a craft, not a checklist; the definition of when to suspend or abort, and the pre-agreed safe states that make those decisions clean. And a question the project has not yet answered, maybe my personal favourite of the open ones: What kind of working life does remote pilotage actually offer? What does a remote pilot’s week, year, and career look like? How is occupational stress managed across decades of a screen-based job that still carries the full moral weight of pilotage? These are design questions as much as regulatory ones.
Remote pilotage as a system is not the same as a pilot on the bridge as a system. The MVP treats remote pilotage as a family of modes – full remote pilotage, remote support as a second pilot, and hybrid arrangements with mid-transit handover between a pilot on the bridge and one ashore. The two systems will operate side by side, in an integrated service. The interesting work now is making that service ordinary: safe, dependable, and survivable for the people who will do it.
Picture (top): Live operation image of the project’s remote operation centre. The middle big screens show the Groke Technologies situation awareness camera view that blends RGB and thermal camera signals. Here, MS Viikki is outbound from the port of Raahe (photo Iiro Törmä).
Also read: Pilotage risk management: To a precautionary approach
