117
1 INTRODUCTION
Recent developments in the maritime industry
suggest a trend towards increasing autonomy, just as
in the automotive industry [9]. Autonomy is defined
as a certain degree of self-governance, i.e., a ship that
is autonomous can operate independently of humans
to a certain extent according to the degree of
autonomy it possesses [16]. Increasing autonomy
likely results in numerous benefits. First, increasing
autonomy has the potential to reduce the burden on
humans by relieving them of difficult, attention
demanding, and stressful tasks [18]. Opposed to
humans, a system does not suffer from limited
attention spans or fatigue when performing a task for
an extended period of time. Therefore, increasing
autonomy likely increases overall safety in shipping
by preventing human deficits from causing accidents
[15, 18]. Lastly, increased autonomy can improve
efficiency in the use of limited resources and thus has
a positive impact on the environment [1], while
simultaneously reducing costs [13].
1.1 Constrained Autonomy
Fully autonomous vessel navigation without nautical
officers who potentially intervene requires an
extraordinarily complex system [16]. As a step
towards full autonomy and to reduce system
complexity, nautical officers should still be present on
board to take over the watch and navigational control
in situations, in which the autonomous system
requires human intervention. This so-called
constrained autonomy (see [13]) requires the
definition of an operational design domain (ODD).
The ODD precisely defines system boundaries (e.g.,
specific traffic situations or weather conditions),
within which the autonomous system can operate
safely [4]. Since the autonomous system is able to
Modelling the Processes of Taking Over the Watch
From an Autonomous Navigation System
S. Hochgeschurz, E. Dalinger & F. Motz
Fraunhofer Institute for Communication, Wachtberg, Germany
ABSTRACT: The maritime industry is striving towards increasing levels of autonomy within the field of
navigation. However, fully autonomous vessel navigation requires an extraordinarily complex system. As a step
towards full autonomy and to reduce system complexity, nautical officers should still be available on board to
take over the watch from the autonomous system in situations, in which human intervention is required.
Therefore, a highly advanced human-machine interface (HMI) is essential, which supports nautical officers in
retrieving all necessary information in order to manage the takeover. The implementation of the autonomous
system and introduction of an HMI creates new processes, which need to be defined. In this paper, we portray
our approach to define the processes for watch handovers from the autonomous system to nautical officers by
investigating current watch handover processes. Subsequently, the resulting process models are described and
discussed.
http://www.transnav.eu
the International Journal
on Marine Navigation
and Safety of Sea Transportation
Volume 15
Number 1
March 2021
DOI: 10.12716/1001.15.01.11
118
detect when the ODD is left, the nautical officer can
pursue other tasks and does not necessarily have to
be on the bridge. Thus, it is not the nautical officer’s
task to supervise the autonomous system while it
operates within ODD limits. As a result, negative
effects associated primarily with a supervisory role of
humans, such as automation surprises [17], boredom
or fatigue [18] are less likely to occur. When the ODD
is left, the autonomous system calls the nautical
officer to the bridge in a timely manner to take over
the ship. Constrained autonomy therefore enables a
periodically unmanned bridge meaning that the
bridge is unmanned while the system is operating
within ODD limits [16].
If the ODD is left and the nautical officer is called
to the bridge to assume control, there is no human
officer available to aid the officer of the watch (OOW)
in gaining situational awareness (e.g., [5]) of the
current navigational situation [15]. All necessary
information must be retrieved from the autonomous
system, since the OOW is unfamiliar with the
situation, i.e. out-of-the-loop (e.g., [6]), when arriving
on the bridge. If information provided by the
autonomous system is insufficient, the OOW might
misinterpret the system’s intentions. Therefore, a
highly advanced human-machine interface (HMI) is
essential [18], to allow the OOW to retrieve all
necessary information within the shortest possible
time in order to manage the situation as efficiently as
possible. To develop the HMI, a useful first step is to
define processes that describe how watch handovers
from the autonomous system to a nautical officer will
proceed once the autonomous system is operational.
The implementation of the autonomous system
therefore creates new processes within the shipping
company, which need to be developed.
1.2 Objectives
The aim of this paper is firstly to portray our
approach to modelling the new watch handover
processes by investigating current ones and secondly
to describe and discuss the resulting handover
process models. The handover processes were
modelled as part of the B0 | B ZERO project, funded
by the German Federal Ministry for Economic Affairs
and Energy. The B0 | B ZERO project aims at
developing a constrained autonomous system that
can operate fully autonomously for up to eight hours,
if the ODD is not left in the meantime. After eight
hours have passed or if ODD limits are exceeded, the
watch will be handed back to a human officer. This
constrained autonomous system will be tested and
implemented on a test ship owned by a collaborating
shipping company.
2 METHODS
2.1 Process analysis
The processes of watch handovers from the
autonomous system to human officers were defined
using process analysis. Process analysis provides a
review of an organization’s work processes and
fosters understanding of current processes within the
organization [2]. Further, process analysis helps to
identify potential weaknesses and thus serves as a
basis for process improvements [3]. It can also be
used for process redesign if organizational
developments, such as introducing new technologies,
occur. When new technologies are introduced, new
processes can be developed by first analyzing current
processes and then adjusting these to meet the new
requirements.
A process consists of a sequence of activities
(process steps) in an organization, which are
performed by organizational units in a predefined
order with the goal of accomplishing a task [12]. A
process receives input as information, matter, or
energy, and produces several outputs [10]. To
develop a process model one needs a method for data
collection, a modelling language, which is a graphical
representation used to specify processes in a model,
and a modelling tool for digitizing the process model.
There are several modelling languages available and
a widely used standard is Business Process Modelling
and Notation (BPMN, [12]). There are also diverse
modelling tools available, which differ in
functionalities available from modelling to
simulation.
Figure 1. Analyzing the current state according to [8]
Figure 2. Planning the target state according to [8]
Process analysis can be conducted as follows
according to [8]. Usually, the first step entails
carefully preparing the analysis of current processes
(Figure 1). This step comprises specifying the level of
detail, i.e., defining the relevant processes and sub-
processes to be considered, as well as identifying
subject matter experts or process experts depending
119
on the processes under consideration. Next, the
analysis method is specified by determining for
example to what extent subject matter experts should
be involved. In the second step, data is collected,
which can entail several methods such as document
analysis, observations, workshops or protocols. In the
next step, the gathered process data should be
transferred to a graphical process model. For this
purpose, a suitable modelling language and
modelling tool should be selected. A follow-up
analysis is conducted, in which the process model is
verified and validated to ensure its accuracy. To
redesign current processes and plan the target state,
the process optimization phase is conducted (Figure
2). In this step, weaknesses are identified and
optimization measures are defined using interviews
and workshops. Subsequently, the target processes
are modelled with the modelling language and the
modelling tool. Lastly, in a follow-up analysis, the
target processes are then also verified and validated.
2.2 Procedure for redesigning processes
In the following, we describe the procedure we used
for defining the processes of taking over the watch
from the autonomous system. The procedure was
developed based on the process analysis approach
described in section 2.1 considering the requirements
of the domain in question. This procedure can be
used in similar use cases and adapted if necessary.
Introducing new technologies can lead to significant
changes in current processes. New processes need to
be defined or old processes need to be adapted to
meet the requirements of the emerging domain.
Capturing the current processes and then considering
which changes are necessary has proven to be a
beneficial approach [3].
As a preparation for process capture, relevant
processes in the area of redesign are identified at first.
For this step, it is vital to consider the purpose of the
new technology in order to understand what changes
will arise for which reasons. To capture the processes,
relevant subject matter or process experts should be
selected. They need to meet certain requirements such
as knowing the processes in question and having a
certain experience within the respective domain.
These requirements should be defined and
communicated to the organization, whose processes
are to be considered.
Data collection should be started with the analysis
of documents describing the relevant processes, as
long as such documents are available. After analyzing
the documents, preliminary process models can be
defined and used as samples for data collection
during the interviews with process experts.
Since data should be collected with the modelling
tool if possible, so selecting a modelling language and
a modelling tool should be done in time. The process-
modelling tool can be used to visualize the captured
processes and thus provides the basis for a mutual
understanding between the analyst and the process
expert. Using the modelling tool during the
interviews allow to make adjustments that the
process expert can directly see. In this way,
simultaneous verification and process capture is
possible. If several process experts are interviewed
about the same process, the captured process models
should be analyzed and aggregated. Afterwards, the
resulting process models should be validated to check
whether the processes conform to work
specifications.
The next step is to define the target processes,
namely, the future processes in the organization after
the new technology has been introduced. This is done
by analyzing and adjusting the current processes to
the requirements of the new work domain. In
particular, changes due to technical requirements
should be considered. Hence, both the technical
experts responsible for developing the new
technology as well as process experts should be
involved in developing the future processes. A
workshop with several experts or interviews with just
one expert can be conducted as a suitable data
collection method. The current process models can
then be adjusted during these workshops or
interviews. The use of the modelling tool during the
workshop ensures the mutual understanding among
the experts and verification of the developed
processes. If necessary, additional processes should
be defined. In the final step, validation of the
processes should be carried out with both the process
experts as well as with the technical experts to
guarantee that the processes conform to
organizational regulations as well as to technological
characteristics.
3 DATA COLLECTION
3.1 Identification of relevant processes
Before modelling the future processes, it is necessary
to first identify the processes that need to be
redesigned. With the introduction of a constrained
autonomous system, a vessel can navigate
autonomously as long as ODD limits are not
exceeded [13]. In the various situations outside ODD
boundaries, the system needs to call a human for
help. The human then has to quickly take over the
watch from the autonomous system in these various
situations, representing processes that do not exist in
traditional navigation and therefore need to be
defined.
Leaving the ODD can happen either expectedly or
unexpectedly (see [18]). For example, a constrained
autonomous ship could be designed to handle deep-
sea passages on its own (e.g., [15]), while it needs
help from the human operator when entering shallow
waters. In this case, the OOW knows in advance (i.e.,
when planning the voyage) when the vessel will
require human assistance – namely before entering
shallow waters. If the ODD exit happens
unexpectedly, the OOW cannot predict when exactly
this is going to happen. For example, it is not possible
to anticipate exactly when a complicated traffic
situation will occur. Detecting such a situation thus
leads to an unexpected call for human intervention.
Since the OOW knows when the expected ODD
exit is going to happen, he can prepare for it and
come to the bridge in a timely manner to take over
from the autonomous system. This seems to be quite
similar to traditional watch-handovers between the
120
OOW to be relieved and the relieving OOW, where
the relieving OOW also has no prior knowledge of
the situations’ specifics when arriving on the bridge.
Standard watch takeover procedures as found in [11]
and in checklists of shipping companies were
therefore used to guide modelling the future process
of a watch takeover after an expected ODD exit.
The unexpected ODD exit, on the other hand, is
very similar to a situation during a traditional watch,
in which the OOW calls the master for help. For
example, the OOW has to call the master, when he or
she expects danger to the ship because of the traffic
situation [11]. The master then comes to the bridge,
largely unaware of the situation asides from the
information he or she received via the call. To take
further action, the master first has to become
acquainted with the situation at hand. The current
process of calling the master (e.g., [11]) was therefore
used to support defining the process of a watch
takeover from the autonomous system after an
unexpected ODD exit.
In both traditionally encountered situations,
humans are initially out-of-the-loop and are then
briefed about the situation by the current OOW
similar to when the autonomous system detects that
the ODD has been left and calls for a nautical officer.
In the latter case, the current OOW is replaced by the
autonomous systems itself. Therefore, these two
current processes provide a good starting point to
model the future processes of expected and
unexpected watch takeovers.
3.2 Modelling of processes
The process models of expected and unexpected
watch handovers in case of ODD exits were defined
following the procedure described in section 2.2.
Firstly, relevant current processes were defined and
preliminary process models were created based on
relevant documents. These were then further refined
and validated in interviews with nautical officers and
masters. Subsequently, in three workshops with
nautical experts and developers of the autonomous
system, the current process models were converted
into process models for future operations with the
autonomous system. The widely used BPMN [12] was
used as modelling language and iGrafx as modelling
software.
For the process of an expected watch takeover
from the autonomous system, the standard watch
handover between two nautical officers was selected
as the relevant current process. The “watch
handover” checklist of the shipping company
providing the test ship was used as the relevant
document. For the process of an unexpected watch
takeover from the autonomous system, a situation, in
which the OOW calls the master for help, was used as
the relevant current process. Here, the procedure for
calling the master (e.g., [11]) served as the relevant
document. Since both current processes occur
regularly and involve first officers and masters, the
first officers and masters of the shipping company in
question were selected as process experts.
A total of four process experts took part in semi-
structured interviews conducted online due to the
coronavirus pandemic. Our goal in the interviews
was to refine, verify and validate the current process
models created on the basis of the relevant
documents. For this purpose, the process experts
were asked to imagine themselves in the role of the
OOW to be relieved and tell us more about each step
of the current processes. Follow-up questions were
asked to obtain the following information, if the
process experts did not already mention them
themselves in their report:
− the order of actions during the process
− what information is used to perform the action
− the reasons for performing the action
− the person who performs the action
During the interviews the process experts could
see the designed process models and applied
changes. The process modelling procedure offered
process experts an opportunity to give direct
feedback and to verify applied changes to the process
model. The process experts have all been employed as
nautical officers for at least 12 years and two of the
four experts additionally had experience as masters.
To illustrate the current process of calling the master,
several scenarios featuring different situations were
defined. The participants were surveyed to frequently
occurring situations when the master had to be called.
Critical collision situations with a give-way target
were mentioned as the most frequently encountered
situations and were thus taken as an example to
model the process of calling the master.
After the interviews, the resulting takeover
process models were summarized and consolidated.
They were then converted into process models for
future operations with the autonomous system in a
total of three workshops with technical experts, i.e.,
developers of the autonomous system and of an
intelligent logbook. The resulting process models
were finally coordinated with the shipping company
in a further workshop to check whether they are
fundamentally compliant with the company’s
specifications.
4 RESULTS
A total of three processes for future ship operations
using the constrained autonomous system were
defined. In the following, the constrained
autonomous system will be referred to as the
AutoOOW – an abbreviation for an autonomous
officer of the watch. Whereas in the current processes
the relieving OOW or the master and the OOW to be
relieved are the process participants, in the processes
defined, there are the following four process
participants:
− the AutoOOW,
− the AutoOOW’s HMI (AutoOOW-HMI),
providing information from the AutoOOW to the
crew,
− the intelligent logbook (referred to as
AutoLogbook) – a mobile device intended not
only for logbook keeping, but also for alerting and
providing relevant information to the crew, and
− the OOW who is not necessarily on the bridge, but
on standby in case the ODD is left unexpectedly
(this could be the master in an emergency)
121
The AutoOOW-HMI and to some extent also the
AutoLogbook largely adopt the former tasks of the
OOW to be relieved specified in the current process
models. With the help of the AutoLogbook, the OOW
shall be informed, when he or she needs to come to
the bridge to assume control. The AutoOOW and the
AutoLogbook were included in the defined process
models to point out the data exchange between the
systems (see Figure 3). Taken together, the following
three process models were defined:
− a process model for maintaining constrained
autonomy, which contains the watch takeover
processes as sub-processes,
− a process model for performing an expected watch
takeover from the AutoOOW, and
− a process model for performing an unexpected
watch takeover from the AutoOOW.
Figure 3. Data exchange when the OOW is not on the
bridge (left) and when the OOW is on the bridge (right)
4.1 Process for maintaining constrained autonomy
The process for maintaining constrained autonomy
describes the general procedure of the information
flow between the process participants during
autonomous operation and during the changes
between autonomous and non-autonomous
operation. Thus, this process contains the two watch
transfer process models as sub-processes and is
therefore of higher order with respect to them. One
important aspect of this process is to provide status
information, which should be accomplished by both
the AutoLogbook and the AutoOOW-HMI, ensuring
that officers can retrieve the information regardless of
whether they currently are on the bridge or not (see
Figure 3). Status information includes information
about the current state of the ODD (is the system
inside or outside the ODD?), the AutoOOW (is the
system currently operating autonomously or non-
autonomously?), and the OOW (is the OOW currently
on the bridge?). Both devices shall also provide
summarized information about the current situation
such as information about the weather or the own
ship’s voyage progress. Additionally, the AutoOOW-
HMI shall provide sensor fusion results, i.e., results
that contribute to a quick understanding and
classification of the navigational and traffic situation.
The AutoLogbook shall further display current
messages from the AutoOOW, informing the master
or the OOW, when and for what reason a watch
takeover is necessary and to summon him or her to
the bridge. In addition, it shall be possible for the
OOW or master to retrieve information from the
AutoOOW via the AutoLogbook when the bridge is
unmanned. Thus, the AutoLogbook serves as a means
to maintain communication between the AutoOOW
and the OOW or master when the bridge is currently
unmanned. Communication becomes especially
important when ODD limits are exceeded. In case this
happens, one of the watch transfer processes shall be
initiated, which are described in the following
sections. If the AutoOOW returns to ODD limits after
the watch transfer, the AutoOOW can assume the
watch again.
4.2 Process for performing an expected watch takeover
Tasks of the AutoOOW-HMI and their consecutive
order during the expected watch takeover from the
AutoOOW can be derived from Table 1. Similar to the
process for maintaining constrained autonomy, the
process of the expected watch transfer from the
AutoOOW to the OOW starts with providing a
general overview of the state of the ODD, the
AutoOOW, and the OOW. Then, the OOW shall
check whether the AutoOOW is currently performing
a maneuver. If so, the watch transfer is to be
postponed. The check is followed by the OOW
confirming his identity by logging into the
AutoOOW-HMI. Additionally, the capability of the
OOW to take over the watch shall be ensured. It must
be still clarified, how this will be accomplished, since
in the current process of a standard watch takeover
this is done by a personal assessment of the OOW to
be relieved. Formalities such as signing changes in
master’s (night) orders, completing checklists, and
finalizing logbook entries were also included in the
resulting process model. Checklists shall be
completed automatically whenever possible.
An important task of the OOW to be relieved in
the current process of a standard watch takeover is to
inform the relieving OOW about the current
navigational and traffic situation. During an expected
watch takeover, the AutoOOW shall accomplish this
by enriching a chart-based representation of the
navigational and traffic situation with improved
sensor fusion results. For example, references to
relevant COLREGs (conventions on the international
regulations for preventing collision at sea) currently
in force shall be provided. Finally, the OOW shall
complete the takeover process with the actual
takeover by switching to non-autonomous operation.
4.3 Process for performing an unexpected watch takeover
The process for performing unexpected watch
takeovers from the AutoOOW refers to cases where
the ODD was unexpectedly left due to some critical
situation. The situation in which the own ship needs
to act quickly to avoid a collision with one or more
give-way targets was used to model the current
process of a master calling procedure (as described in
section 3.2). Therefore, it was also employed as a use
case during the definition of the process for
performing an unexpected takeover.
122
Table 1. Tasks of the AutoOOW-HMI during watch takeover processes
__________________________________________________________________________________________________
Expected watch takeover Unexpected watch takeover
__________________________________________________________________________________________________
Provide an overview of status information including Provide an overview of status information including
– the ODD status – the ODD status
– the AutoOOW status – the AutoOOW status
– the OOW status – OOW-Status
– crew instructions – the current situation
– the current situation
Ask for confirmation of Ask for confirmation of
– identity – identity
– capability to take over
Display changes in Master’s (night) orders and obtain Watch takeover by the OOW or master
the OOW’s signature
Provide ship status information including Provide ship status information including
– the status of connected bridge equipment – the status of connected bridge equipment
– the engine status – the engine status
– work in progress on board and ongoing hazardous work – Items with impact on the ship’s maneuverability
– items with impact on the ship’s maneuverability
Provide navigation-related information including Provide navigation-related information including
– the navigational situation – the navigational situation
– the traffic situation with COLREG-related hints – the traffic situation with COLREG-related hints
– the critical target
– nearby navigational hazards
– room available for maneuvers
– weather, tide and currents
Offer the possibility to search for additional information Recommend a maneuver to solve the situation
Ask for completion of relevant checklists and logbook Offer possibility to modify maneuver or perform a maneuver
entries manually
Watch takeover by the OOW or master Provide a review of the selected or performed maneuver
__________________________________________________________________________________________________
While the actual watch takeover shall take place at
the very end of the expected watch takeover process,
it is supposed to happen relatively early in the process
of an unexpected watch takeover (see Table 1, which
also provides a comparison of the two watch takeover
processes). As in the respective current process model,
the actual watch takeover shall occur comparatively
early to allow the OOW to react quickly to the
situation due to the anticipated time pressure. For this
reason, several steps from the expected watch
takeover process are omitted in the unexpected watch
takeover process. Most of the omitted steps consist of
formal procedures, which can be addressed after the
critical situation has been resolved.
On the other hand, in unexpected watch takeovers,
some additional steps are included that do not need to
be performed during expected watch takeovers. One
additional step is the AutoOOW-HMI providing
detailed information about critical targets due to the
impending collision situation. Such information
comprises for example the targets’ CPA and TCPA
values, their distances to the own ship, and their AIS
information, as well as their position. Likewise, the
AutoOOW-HMI shall provide information about the
sea area available for avoiding the collision. Finally,
the AutoOOW shall suggest one or more maneuvers
to the OOW, taking into account the available sea
area. The OOW shall then be able to select or modify
one of the proposed maneuvers and subsequently
either perform the proposed or modified maneuver or
reject it to perform a maneuver manually. After the
maneuver, the AutoOOW shall further provide the
possibility to evaluate the performed manoeuver.
Once the critical situation is resolved and the system
has returned to its ODD limits, it shall be possible to
hand the watch back to the AutoOOW.
5 DISCUSSION
In recent years, a trend towards increased autonomy
could be observed in the maritime industry [9].
However, since fully autonomous vessels are rather
unrealistic in the near future [1], some form of remote
control [20] or constrained autonomy as in the B0 | B
ZERO project is initially pursued. A constrained
autonomous vessel can handle most situations
autonomously without any crew on the bridge, but
requires human assistance in certain situations [13]. In
these situations, the autonomous system must hand
over the watch to the OOW. Watch handovers
therefore no longer take place only from human
officers to human officers, but also from autonomous
systems to human officers – a new watch handover
situation that does not yet exist and for which
processes must be defined. The definition of the
processes ultimately serves to produce a unique HMI
that optimally supports the handover processes.
Within the B0 | B ZERO project, three process
models for future operations with the autonomous
system were defined: A process for expected watch
takeovers, derived from the current process of a
standard watch takeover between two nautical
123
officers; a process for unexpected watch takeovers,
based on the current process of a critical situation, in
which the OOW calls the master for assistance; and a
process for maintaining constrained autonomy, which
is superior to the other two processes and describes
general procedures during autonomous operation and
watch changes. This last process lacks an equivalent in
the current processes and thus illustrates that
processes can change fundamentally as a result of
introducing new technologies. In general, it is
anticipated that the process models created will be
adapted as needed during the course of the project in
the sense of an iterative procedure. The procedure
used explicitly includes such iterations by
incorporating many evaluation and validation steps in
accordance with the human-centered design approach
for interactive systems [7].
In the discussion of constrained autonomy and
taking over the watch from an autonomous system,
especially in unexpected situations, it is necessary to
raise awareness of potential risks such an approach
entails. One of these risks is skill degradation – a
phenomenon that has been frequently observed in the
context of increasing system automation (e.g., [19]).
The fact that the autonomous system will perform
routine tasks almost exclusively can lead to skill
degradation among operators, since not frequently
used skills are likely to decline over time [14].
Therefore, it is immensely important that operators
train their skills regularly [19] in order to be able to
handle critical situations appropriately when called to
the bridge. The expected watch takeovers from the
autonomous system, for example when entering
shallow waters, could be a way to reduce skill
degradation by training the operators’ skills.
Furthermore, the risk of skill degradation reinforces
the need for an efficient HMI that optimally supports
the watch handover processes.
5.1 Approach
The goal of this paper was not only to describe the
newly defined watch handover processes, but also to
present our approach to defining these processes. Our
approach included the conduction of online
interviews in which process experts were able to see
the current processes during process modelling. This
approach had several advantages. First, process
experts were given the opportunity to object if
something was misunderstood, so that changes
applied to the current version of the process model
could be validated on the spot. This enabled the
processes to be captured and verified at the same
time. In addition, results from previous interviews
could be used as a starting point for subsequent
interviews, saving time and providing an additional
validation and verification opportunity. The
interviews further facilitated asking in-depth
questions, allowing us to obtain a lot of information
including the reasons why certain actions are taken
and what specific information is necessary at certain
steps in the process. Because interviews were
conducted online, they were independent of the
location of the interviews’ participants. This was a big
advantage, as most officers and masters from the
shipping company providing the test ship for the B0 |
B ZERO project, were not in the same country as the
interviewers at the time of the interview. For process
analysis, it is important that the interviewees are
process experts with respect to the processes within
the shipping company that will implement the new
technology and processes in the future.
The modelling language used proved to be easy to
explain and easy to understand by someone without
any prior process analysis experience. In our
experience, it was particularly helpful to start the
interviews with preliminary process models that were
developed based on document research. In this way it
was possible to explain the method and the
components of the modelling language clearly with
the help of a domain, with which the process experts
are by definition very familiar.
The results show that the approach for modelling
processes as described above can be applied in an
emerging domain like autonomous shipping. The
processes provide a thorough description of the
emerging procedures on board and can be used for
further investigations in the area.
5.2 Limitations
The original plan was to model the current processes
by observing watch takeovers both in the simulator
and on board the test ship. However, due to the
coronavirus pandemic, neither simulator nor on board
observations were possible, which is why the
interviews and workshops were conducted online.
Observations in this context have the advantage that
they are to a certain extent objective [8], since they rely
on observable behavior. Two observers who receive
the task to write down all actions an operator
performs to achieve a certain goal are very likely to
take note of similar aspects. Therefore, such
observations are independent of the observer.
However, the procedure we used is rather subjective,
since it is based on participants’ introspections. People
are not always good at reporting exactly how they
perform a frequently executed activity, as they may
not consciously recall all the steps the activity
comprises [8]. This must be kept in mind when
interpreting the results. It is further important to note
the small sample size used to model the current
processes. Additionally, it remains to be determined
to what extent the processes may be generalizable to
other shipping companies with different specifications
and processes.
6 CONCLUSIONS
The foreseeable deployment of constrained
autonomous vessels necessitates adapting existing
watch handover processes to the new situation. With
constrained autonomy, in contrast to traditional
navigation, a machine instead of a human will hand
over the watch to another human in most situations.
The purpose of our paper was to describe our
approach for defining processes of such emerging
watch takeover situations and the resulting processes.
Three processes were defined and provide insight into
different aspects of the new situations. Our approach
to defining the processes demonstrates that it is
124
feasible to define processes on the basis of online
interviews when simultaneously presenting process
models to process and technical experts. The defined
processes can now be used as a basis for the design of
the HMI of the autonomous system, enabling the HMI
to be closely in line with the user’s needs in the sense
of a human-centered design process. Whether the
HMI will then be as good as the nautical officer in
handing over the watch is an interesting question for
further research and remains to be investigated.
ACKNOWLEDGEMENTS
The process models were developed as part of the B0 | B
ZERO project funded by the German Federal Ministry for
Economic Affairs and Energy. In particular, the authors
would like to thank the shipping company Bernhard
Schulte for their kind support.
REFERENCES
1. Abilio Ramos, M., Utne, I.B., Mosleh, A.: Collision
avoidance on maritime autonomous surface ships:
Operators’ tasks and human failure events. Safety
Science. 116, 33–44 (2019).
https://doi.org/10.1016/j.ssci.2019.02.038.
2. Allweyer, T.: Business process management: strategy,
design, implementation, controlling. W3l GmbH, Witten,
Germany (2007).
3. Best, E., Weth, M.: Optimising business processes: the
practical guide for successful reorganisation. Gabler |
GWV Fachverlage GmbH, Wiesbaden, Germany (2007).
4. Colwell, I., Phan, B., Saleem, S., Salay, R., Czarnecki, K.:
An Automated Vehicle Safety Concept Based on
Runtime Restriction of the Operational Design Domain.
In: 2018 IEEE Intelligent Vehicles Symposium (IV). pp.
1910–1917 (2018).
https://doi.org/10.1109/IVS.2018.8500530.
5. Endsley, M.R.: Situation awareness global assessment
technique (SAGAT). In: Proceedings of the IEEE 1988
National Aerospace and Electronics Conference. pp.
789–795 , Dayton, OH, USA (1988).
https://doi.org/10.1109/NAECON.1988.195097.
6. Endsley, M.R., Kiris, E.O.: The Out-of-the-Loop
Performance Problem and Level of Control in
Automation. Hum Factors. 37, 2, 381–394 (1995).
https://doi.org/10.1518/001872095779064555.
7. Ergonomics of human-system interaction - Part 210:
Human centred design for interactive systems. ISO,
Geneva, Switzerland (2019).
8. Feiser, D.: Development and investigation of a concept
to capture work processes. Shaker-Verlag, Aachen,
Germany (2015).
9. Kim, M., Joung, T.-H., Jeong, B., Park, H.-S.:
Autonomous shipping and its impact on regulations,
technologies, and industries. null. 4, 2, 17–25 (2020).
https://doi.org/10.1080/25725084.2020.1779427.
10. Leittechnik; Regelungstechnik und Steuerungstechnik;
Allgemeine Grundbegriffe: DIN 19226-1 - 1994-02 -
Beuth.de. Deutsches Institut für Normung e.V., Berlin,
Germany (1994).
11. Meurn, R.J.: Watchstanding Guide for the Merchant
Officer. Schiffer Publishing.
12. Object Management Group (OMG): Business Process
Model and Notation (BPMN). (2013).
13. Ørnulf, J.R.: Defining Ship Autonomy by Characteristic
Factors. In: Proceedings of the 1st International
Conference on Maritime Autonomous Surface Ships. pp.
19–26 , Busan, Korea (2018).
14. Parasuraman, R., Sheridan, T.B., Wickens, C.D.: A model
for types and levels of human interaction with
automation. IEEE Transactions on Systems, Man, and
Cybernetics - Part A: Systems and Humans. 30, 3, 286–
297 (2000). https://doi.org/10.1109/3468.844354.
15. Porathe, T., Hoem, Å., Rødseth, Ø., Fjørtoft, K., Johnsen,
S.O.: At least as safe as manned shipping? Autonomous
shipping, safety and “human error.” In: Haugen, S.,
Barros, A., van Gulijk, C., Kongsvik, T., and Vinnem, J.E.
(eds.) Proceedings of ESREL 2018,. pp. 417–425 CRC
Press, Trondheim, Norway (2018).
https://doi.org/10.1201/9781351174664-52.
16. Rødseth, Ø.J., Nordahl, H.: Definitions for autonomous
merchant ships, https://nfas.autonomous-ship.org/wp-
content/uploads/2020/09/autonom-defs.pdf, last
accessed 2021/03/27.
17. Sarter, N.B., Woods, D.D., Billings, C.E.: Automation
Surprices. In: Salvendy, G. (ed.) Handbook of Human
Factors & Ergonomics. Wiley (1997).
18. Seppelt, B.D., Victor, T.W.: Potential Solutions to Human
Factors Challenges in Road Vehicle Automation. In:
Meyer, G. and Beiker, S. (eds.) Road Vehicle Automation
3. pp. 131–148 Springer International Publishing, Cham
(2016). https://doi.org/10.1007/978-3-319-40503-2_11.
19. Volz, K., Yang, E., Dudley, R., Lynch, E., Dropps, M.,
Dorneich, M.C.: An Evaluation of Cognitive Skill
Degradation in Information Automation. Proceedings of
the Human Factors and Ergonomics Society Annual
Meeting. 60, 1, 191–195 (2016).
https://doi.org/10.1177/1541931213601043.
20. Wróbel, K., Gil, M., Chae, C.-J.: On the Influence of
Human Factors on Safety of Remotely-Controlled
Merchant Vessels. Applied Sciences. 11, 3, (2021).
https://doi.org/10.3390/app11031145.
