Automation and autonomy are sometimes used as concepts that mean the same thing, and sometimes defined differently. Automation is, basically, when a series of actions are performed after being started by someone/something. Autonomy is, for the sake of this course, more self-governing, and supposedly less reliant on human input.

Automation

the following text is taken from a book chapter (Earthy & Lützhöft, 2018)

Automation is often seen as something that can replace humans (Boorman, 2015) with the claim that it will reduce errors and make for better efficiency and lower costs. The 'error reduction fallacy' is widely believed and seems to be persistent (Sherwood Jones & Earthy, 2016). However, while sometimes positive (expected) effect occurs, or at least to some extent, unexpected or unwanted things will also happen. Compare this to the development of for example driverless trains, “automated” retail checkouts and shore-based or remote pilotage. We see how, ironically, the ticket machine for the train requires a person to help you buy your ticket, and how people “forget” to scan (and thus pay for) food because they have to do the work at the checkout (“It’s only fair”). In the marine context, remote pilotage has been proposed, in the name of safety and efficiency. This summary does not claim to be representing the whole discussion. It is believed that it would be safer for pilots to stay on land and not have to perform a risky embarkation, and it would be more efficient to be able to “pilot” (from shore) in all or most weather situations. Some counterarguments include that pilots must be on board to safely manoeuvre and will bring local expertise to where it is needed – on board the ship. Marine pilots are so far resisting the development, but who knows for how long as new developments are happening at a fast pace. At the time of writing, the first remote control of a ship (tug) was safely performed in a port (with a crew on board for safety). It remains to be seen what side effects and unexpected effects will occur.

Human error is a symptom of trouble deeper inside the system (Sherwood Jones & Earthy, 2016). We know that strong and silent automation leads to lack of an overview which in turn leads to mode 'errors', automation 'surprises' and disruption of teamwork. Automation adds difficult monitoring tasks, increases the need to understand the automation as well as the process under control, and adds additional high-skill planning, customisation, and set-up tasks. It is, essentially, clumsy automation that takes care of routine situations (leading to boredom), but which cuts out and disrupts the operators during unusual situations (Bainbridge, 1983; Lützhöft & Dekker, 2002; Sarter, Woods, & Billings, 1997; Woods, Johannesen, Cook, & Sarter, 1994; Woods & Sarter, 2000). The number of references for this phenomenon are included to show that it is common and well known, but largely unrecognised in the maritime context.

There are four 'jokers' in the human aspects of automation. A joker is an issue that does not seem resolvable by traditional design, and even a management solution appears difficult to find (Sherwood Jones & Earthy, 2016). These issues have neither been discussed, nor investigated for marine automation or navigation. The jokers are:

Risk compensation, where the performance gains intended for increased safety are used to corporate commercial advantage. Compensation by individuals is well known in, for example, road traffic research.
Automation bias, where people believe the automation when they should not, and frequent errors of omission in manual operations are replaced by major errors of commission in automated operations.
Moral buffering, where remoteness and/or algorithms lead people to act in an inhumane manner.
Affect dilemma, where people attribute personality to automation – probably inappropriately, but unavoidably. We see it in how people try to reason with automation and try to relate to it at work from a safety perspective. We already make an effort to avoid upsetting Siri and Alexa.

Autonomy

Autonomy, automation and remote control are said to be promising in terms of cutting costs and enhancing the safety of operations. Remote control and autonomy technologies will play a key role in next-generation vessel management, and will lead to more operational decisions being taken outside the vessel. Developed satellite communications has made this possible and it is envisioned that autonomy, adaptability, equipment failure prediction and artificial intelligence will be part of the next generation of decision support systems. Whether the industry adopts autonomous (i.e. self-determined) systems, controlling whole ships in the near future is uncertain. However, parts of platforms are already under offship supervision or completely automated. We already have some decision-making that is completely out of the crew’s hands. Technical progression is likely to be straightforward, but, when we consider human performance, we may not be looking at a linear progression, but are likely to have to consider scenarios with different issues of control, supervision, trust, competence etc. We are finding that most machine learning applications augment, rather than replace, human efforts. In doing so, they demand changes in what people are doing. And in the case of artificial intelligence those changes eliminate many non specialized tasks and create skilled tasks that require good judgment and domain expertise (Ross, 2017).

Conclusion

The safety of a staffed operational system requires a defined, engineered and maintained balance of system usability and operator competence. To achieve this, the needs of humans must be considered throughout the lifecycle, i.e. the design optimises the effectiveness, efficiency, safety, environmental impact and satisfaction of staff. Standards define and operationalise usability ISO 9241 Part 11, accessibility ISO 9241 Part 171, and quality in use ISO/IEC 25010. Quality in use is: “The degree to which a product or system can be used by specific users to meet their needs to achieve specific goals with effectiveness, efficiency, freedom from risk and satisfaction in specific contexts of use”. The approach to testing is defined in ISO/IEC 25066.

References

Bainbridge, L. (1983). Ironies of automation. Automatica, 19(6), 775-779.

Boorman, C. (2015). The Need for Human Centric Automation. Retrieved from http://devopssummit.sys-con.com/node/3293926

Lützhöft, M. H., & Dekker, S. W. A. (2002). On your watch: Automation on the bridge. Journal of Navigation, 55(1), 83-96.

Earthy, J., & Lützhöft, M. (2018). Autonomous ships, ICT and safety management. In H. A. Oltedal & M. Lützhöft (Eds.), Managing Maritime Safety. New York: Routledge.

Ross, J, (2017). The Fundamental Flaw in AI Implementation. http://sloanreview.mit.edu/article/the-fatal-flaw-of-ai-implementation/

Sarter, N. B., Woods, D. D., & Billings, C. E. (1997). Automation Surprises. In G. Salvendy (Ed.), Handbook of human factors/ergonomics (2nd ed.). New York: Wiley.

Sherwood Jones, B., & Earthy, J. (2016). Using Human-Centred Design to mitigate the risk of human error in software intensive systems Bulletin of the Safety Critical Systems Club (pp. 11-16).

Woods, D. D., Johannesen, L. J., Cook, R. I., & Sarter, N. B. (1994). Behind Human Error: Cognitive Systems, Computers, and Hindsight. CSERIAC SOAR 94-01. Ohio, USA: Wright-Patterson Air Force Base.

Woods, D. D., & Sarter, N. B. (2000). Learning From Automation Surprises and "Going Sour" Accidents. In N. B. Sarter & R. Amalberti (Eds.), Cognitive Engineering in the Aviation Domain. Mahwah, NJ: Lawrence Erlbaum Associates