SafePilot, from the ground up: conversation with Jakob Poulsen
Date: 26.06.26
Jakob Poulsen is a Technical Engineer within Trelleborg Marine and Infrastructure’s Navigation & Piloting team. Since joining the company in 2008 as a software developer, he has been closely involved with the SafePilot platform from its earliest stages. Over the years, he has contributed to the development, delivery, and ongoing support of Portable Pilot Unit (PPU) systems.
You joined the Navigation & Piloting team in 2008. What did software for pilotage look like then, and what drew you to it?
The field was much less mature than it is now. Portable pilot units existed, but a lot of what we take for granted today; the data quality, the integration between sensors and software, the user experience was still being worked out. What drew me in was that it sits right at the intersection of physics and software. You're modelling how a large vessel actually behaves in confined water, in real time, and presenting that to someone who has to make decisions in minutes. That combination of hard real-world constraints and software problem-solving is what kept me here.
SafePilot has been part of your work from the very beginning. How has the platform evolved over that time?
In the early years, most of the effort went into getting the fundamentals right like reliable positioning, accurate heading and rate-of-turn, a display a pilot could read at a glance on the bridge. Over nearly two decades that base has been refined continually rather than replaced. The platform today carries a lot of accumulated field knowledge: edge cases we've encountered in ports around the world, refinements that came directly from pilots, performance improvements that only matter once you're operating at scale. The honest way to describe it is steady accumulation, not a series of reinventions.
As someone who has shaped the architecture, what does reliability mean when software is used in live pilotage?
It has a very specific meaning in our context. A pilot is using the software during an active maneuver, often with little margin for error. The software has to behave predictably every time, degrade gracefully if a data source drops, and never demand attention at the wrong moment. A lot of the architectural decisions come back to that: keeping the core robust, isolating the parts that change frequently from the parts that have to stay stable, and making sure the data reaching the display can be trusted. Part of my role is protecting those principles as the platform grows.
The platform is updated regularly. Why does that continuous development matter?
Pilotage doesn't stand still. Vessels get larger, ports change, operational requirements evolve, and the underlying technology moves as well. The platform has to move with it. I oversee contribute to that ongoing lifecycle: deciding what to prioritize, balancing new capability against stability, and making sure each update earns its place by improving performance, reliability or the day-to-day experience for the user. Regular, well-tested updates are how the platform stays current without ever putting operational reliability at risk.
SafePilot is a Portable Pilot Unit (PPU) with software and hardware working together. How have the two had to evolve in step?
A PPU system is only as good as the combination of the two. Good sensors with poor software, or good software fed unreliable data, both fail the pilot. Over the years we've had to develop hardware and software together, making sure the software gets the most out of the hardware, and that the hardware is specified around what the software actually needs in the field. As the demands on accuracy and data have grown, that integration has had to get tighter, not looser.
How does direct experience from the field feed back into what you build?
The most useful input comes from the people actually using the system, i.e. pilots, and the field teams who support them. They see things we can't anticipate from a development environment: how a workflow feels under pressure, what's genuinely useful versus what just looks good in a demo. Many of the refinements that have made the biggest difference started as a comment from someone in the field. Keeping that channel open and treating it as a long-term partnership rather than one-off feedback, is central to how we work.
The development team has grown over the past year. What does that mean for the platform?
More capacity means we can develop in more areas in parallel and respond faster. It also puts more weight on the things that let a team scale well: clear architecture, good practices, and a shared understanding of why the platform is built the way it is. Part of my role now is making sure that, as the team grows, the continuity and the standards that got us here grow with it.
Without getting ahead of what's released, where is Navigation & Piloting software heading?
The clear direction is around connectivity and data, making it easier to share information securely, and building on the platform so it's ready for the next generation of operational needs. The underlying principle stays what it's always been: any new capability has to make the pilot's job safer or easier, and it has to be reliable enough to trust during a live maneuver. That's the test everything gets measured against.
The field was much less mature than it is now. Portable pilot units existed, but a lot of what we take for granted today; the data quality, the integration between sensors and software, the user experience was still being worked out. What drew me in was that it sits right at the intersection of physics and software. You're modelling how a large vessel actually behaves in confined water, in real time, and presenting that to someone who has to make decisions in minutes. That combination of hard real-world constraints and software problem-solving is what kept me here.
SafePilot has been part of your work from the very beginning. How has the platform evolved over that time?
In the early years, most of the effort went into getting the fundamentals right like reliable positioning, accurate heading and rate-of-turn, a display a pilot could read at a glance on the bridge. Over nearly two decades that base has been refined continually rather than replaced. The platform today carries a lot of accumulated field knowledge: edge cases we've encountered in ports around the world, refinements that came directly from pilots, performance improvements that only matter once you're operating at scale. The honest way to describe it is steady accumulation, not a series of reinventions.
As someone who has shaped the architecture, what does reliability mean when software is used in live pilotage?
It has a very specific meaning in our context. A pilot is using the software during an active maneuver, often with little margin for error. The software has to behave predictably every time, degrade gracefully if a data source drops, and never demand attention at the wrong moment. A lot of the architectural decisions come back to that: keeping the core robust, isolating the parts that change frequently from the parts that have to stay stable, and making sure the data reaching the display can be trusted. Part of my role is protecting those principles as the platform grows.
The platform is updated regularly. Why does that continuous development matter?
Pilotage doesn't stand still. Vessels get larger, ports change, operational requirements evolve, and the underlying technology moves as well. The platform has to move with it. I oversee contribute to that ongoing lifecycle: deciding what to prioritize, balancing new capability against stability, and making sure each update earns its place by improving performance, reliability or the day-to-day experience for the user. Regular, well-tested updates are how the platform stays current without ever putting operational reliability at risk.
SafePilot is a Portable Pilot Unit (PPU) with software and hardware working together. How have the two had to evolve in step?
A PPU system is only as good as the combination of the two. Good sensors with poor software, or good software fed unreliable data, both fail the pilot. Over the years we've had to develop hardware and software together, making sure the software gets the most out of the hardware, and that the hardware is specified around what the software actually needs in the field. As the demands on accuracy and data have grown, that integration has had to get tighter, not looser.
How does direct experience from the field feed back into what you build?
The most useful input comes from the people actually using the system, i.e. pilots, and the field teams who support them. They see things we can't anticipate from a development environment: how a workflow feels under pressure, what's genuinely useful versus what just looks good in a demo. Many of the refinements that have made the biggest difference started as a comment from someone in the field. Keeping that channel open and treating it as a long-term partnership rather than one-off feedback, is central to how we work.
The development team has grown over the past year. What does that mean for the platform?
More capacity means we can develop in more areas in parallel and respond faster. It also puts more weight on the things that let a team scale well: clear architecture, good practices, and a shared understanding of why the platform is built the way it is. Part of my role now is making sure that, as the team grows, the continuity and the standards that got us here grow with it.
Without getting ahead of what's released, where is Navigation & Piloting software heading?
The clear direction is around connectivity and data, making it easier to share information securely, and building on the platform so it's ready for the next generation of operational needs. The underlying principle stays what it's always been: any new capability has to make the pilot's job safer or easier, and it has to be reliable enough to trust during a live maneuver. That's the test everything gets measured against.