Will software developers dominate the shipping industry? Part 2

Simon Beechinor from maritime consultants Strathmay Maritime concludes his frank outlook on the future of maritime operations.

In the near-term, remotely controlled vessels will still share sea-room with traditionally crewed and operated vessels. Those competing modes of operation will conflict with one another and the skills of the two groups of ‘mariners’ will, to a degree, be incompatible. How then will we train to ensure competence is maintained as we transition from a traditional operating environment to a ‘remote control world’?

If there is to be ‘transition’, is the future engineer or ship operator of tomorrow adequately trained even for today’s mode of operation? Who will train them and how will they demonstrate competence for tomorrow’s technology?

It’s perfectly possible that the ‘master’ of an autonomous vessel could find the vessel at risk of being stranded, or in difficulty of some other kind, that could only be relieved if previously ‘hidden’ capacity was released. How would be the master even be made aware that such capacity was available? What risks might escalate, or scenario deteriorate, while a vessel’s owner attempted to identify, communicate and negotiate with some software developer over the cost of unlocking software. Increasingly, we’ll begin to face situations where routine operations may become catastrophic, because they weren’t resolved in a timely way because of subscription issues.

Situations that would normally be considered routine could become complex or deteriorate unnecessarily just because equipment options that are needed and available aren’t in fact made available simply because of an operator’s chosen subscriptions.

Such delays would get even more complex as a ship ages or as software suppliers are bought by other firms or simply go out of business altogether. Who is to say that the new buyer of a software business will have the same outlook or benign business interests as the original supplier?

We are facing a reality where our vessels may hold more operating potential than we have access to because of financial rather than any technical constraints. Risks and situations could quickly get out of hand in the elevated risk, life or death, and even routine scenarios, we commonly experience at sea.

To what extent should software manufacturers be permitted to have, potentially, complete control over when it gets to remotely intervene in situations with virtually no accountability to a vessel’s owners. In the Tesla scenario that Westbrook described, Tesla only acted after a Florida resident inquired about unlocking the extra capability which Tesla then agreed to do to, for the common good in this case.

Who will be empowered to make these decisions and lift the limits on equipment? What implications does this have for our ability to control our vessels?

What will be the insurance implications of having, potentially, catastrophe-saving technology and capacity sitting idle behind a simple paywall? Will it drive premiums up…or down?

If software developers build in firewalls and subscriptions exist to vary capacity of shipboard machinery, how might classification societies lay out the required levels of functionality or critical paths in ship design and construction?

How will those who need to make those decisions even be made aware and kept up to date with the capacity that exists behind the paywall or how to use it?

It will be interesting to see how the courts, insurers and other stakeholders view these decisions. If a software developer doesn’t act when it could, will they see it as reasonable that life was lost or the environment was contaminated simply because a shipowner lacked the foresight, cash or ability to pay for the full functionality. Whose fault will it be if a vessel was lost or an environment contaminated yet a salvor could have benefited from the capacity that remained hidden or unused behind the paywall?

‘Wait and see’ hardly sounds like a sensible response to these issues but I’m not sure what alternatives there are. What’s apparent is that vessels could have the critical functionality made available only when the software developer determines it’s necessary—if it’s even determined to be necessary by the owner, insurer or other stakeholders. Could a SOSREP, for example, force a software developer to release capacity?

Soon we’ll find that the necessary shipboard decisions will be made by the managers of a business that’s far removed from the business of shipping and with little understanding of the realities ‘on-deck’. Decisions could fall to managers with an entirely different and perhaps unacceptable focus on profits, publicity and business outlook. In such cases what are the chances that right decisions will be made?

Will we let software developers charge a premium for services involving the safety and security of our assets and then just hope things turn out OK? How will we ensure that software developers remain accountable to vessel owners for their services and products?

We shouldn’t simply rely on software developers, as we now rely on classification societies, banks and insurers, to be there when we need them. We’ve come to rely on class, our banks and insurers because of centuries of experience. How well are we likely to really know and trust a software company?

I’ve no idea!


  1. A very thought provoking pair of articles.

    Most ships today will have on board an ECDIS system for which additional B.A. charts are held in the system but only made available for use once paid for, so one case of your scenario is already with us.

    I must confess that my thoughts on the autonomous ship have yet to get beyond “how do you berth her?” and “how do you carry out the multitude of small maintenance tasks that occupy the crew’s working day?”, but the idea that a ship’s safety may depend on people ashore with no knowledge of ships and the sea is a bit of a worry.

    There is an aviation parallel – the words, “Why is it doing that?” which so often comprise the last words on the voice recorder of a crashed airliner…

  2. The potential for automated berthing has been with us since 1960 and the development of dynamic positioning. It was considered as a hypothesis as long ago as 1980 during the development of the BP SWOPS project. Modern technology and accurate positioning devices, global and local, make it not only conceivable but inevitable> the technology is there, it is simply the fact that no one has, at least officially, implemented it.
    Daily maintenance ? Redundant systems, on-line monitoring and the application of reliability based maintenance tools are paving the way for line replaceable units and repair during port visits.
    Besides the concerns over data link security which have been raised recently, subscription threats are one of the greatest Trojan threats, particularly in third party packages (I know of at least one unregistered package in a system whose license expiry shut down a company intranet).
    Even without fully automated ship we rely upon software which has long developed into the inner sanctum where the unworthy may not tread; those at sea are already imperiled by proprietary rights. In effect, seafarers are already being endangered by ‘those ashore with no knowledge of ships at sea’.

Back to top button