1st IFAC Workshop on Dependable Control of Discrete Systems (DCDS'07)

ENS Cachan, France - June 13-15, 2007

OPERATION MODES HANDLING IN DISTRIBUTED AUTOMATION SYSTEMS

Seno Panjaitan and Georg Frey

University of Kaiserslautern, FB EIT, JPA²

Erwin-Schroedinger-Str. 12, D-67653 Kaiserslautern, Germany
{panjaitan|frey}@eit.uni-kl.de

Abstract: Operation mode handling is one of the important tasks in automation systems.
Guidelines for the definition and handling of operation modes are currently provided by
academicians and related organizations focusing on centralized systems. In distributed
automation systems, such guidelines are seldom dealt with. Therefore, operation mode
guidance compatible with the distributed application idea is proposed in this paper.
Some modes such as automatic (including setup/starting-up, normal production, hold,
stop, tolerance error handling and abort), semi-automatic, manual, emergency stop and
idle are considered for managing the operation. The modeling using UML state machine
is presented to describe the behavior of modes and their internal states. An
implementation based on a task scheduling approach is presented as an example for the
application of the developed strategies. Copyright © 2007 IFAC

Keywords: operation mode handling, distributed automation system, UML.

1. INTRODUCTION and do not offer the high degree of flexibility needed

In automation systems, there are always several
modes of operation which have to be handled to get a
controlled system. Inefficiencies of both cost and
time will arise if moving from one mode to another is
not managed properly. The relationship of states
inside a mode should also be described clearly. In
addition, to give a clear semantics and reduce
misunderstanding among people involved in design
and use of a system a common notation is very
important. It is clear to see that some form of
operation mode (OM) guideline is required to
improve comprehensibility and re-usability of a
control strategy.
In automation there are different possible system
architectures. In a centralized automation system a
large number of sensors and actuators are handled
using a single control and supervision system.
Therefore, flexibility and re-usability of the
developed system is very limited. Distributed control
systems (DCS) using modular controllers with a
central supervision system are a first step to solve
this problem. Such systems however tend to be
developed using large monolithic software packages
which are generally difficult to integrate for a new
application. Concisely, centralized and traditional
distributed systems are hard to modify and extend
in advanced automation system. Today, embedded
controllers as well as fast and reliable communication
networks are available. These technologies enabled
the development of distributed automation systems
(DAS), providing a higher flexibility and re-
configurability. A DAS can be defined as a set of
systems that are geographically distributed and
operated in a cooperative way in order to work as a
whole. Such a system allows autonomous control and
supervision in each of its constituents.
Strategies to handle OMs locally (one controller) and
globally (overall system) in a DAS tend to be more
complex than for centralized system. Since OM
methods for centralized systems can not directly be
applied to DAS, a new guidance for OMs compliant
with distributed applications is proposed in this
paper. As modeling tool, UML state machine is
employed.
The rest of this paper is organized as follows. The
next section gives an overview of current approaches
related to OMs. Section 3 presents the proposed OMs
for distributed systems. Resetting and restarting in
OMs is discussed in Section 4. Section 5 discusses
the transition between modes. Section 6 illustrates
how to implement the OMs. The last section
concludes the paper and gives an outlook.
 2. OMs IN AUTOMATION SYSTEMS
In automation systems, operation modes determine
how the system (or sub-systems thereof) will operate
in response to the commands that are issued to it. For
a given system, the possible OMs as well as the
corresponding behavior have to be specified. In
distributed systems, this specification needs to
consider the OMs of each sub-system where different
sub-systems may possess different OMs. Moreover,
it can be necessary to define some OMs for the
complete system either by defining additional modes
for it or by synchronizing OMs of the sub-systems
via the communication network. As an example for
an OM that is not restricted to a sub-system an
emergency stop scenario may be considered where
the stop of one sub-system due to a critical situation
may lead to the stop of the overall system. Current
guidelines related to OMs are listed in Table 1.
Table 1. Overview of OM Guidelines.
Guideline Reference
GEMMA Moreno and Peulot (1997)
S88 Pharshall and Lamb (1999)
PackML OMAC (2006)
GEMMA (Guide d’Etude des Modes de Marches et
d’Arrêts) is a guideline for planning the operation-
modes and stand-still modes using a design form. It
was proposed by ADEPA (France) in 1984. It
includes four state groups: normal operation,
standstill state, fault states and shut down (no power
supply of the control). The production process will
run among the particular subsets inside the first three
state groups. The proposed design process using this
approach is based on three steps as follows. First
Step: the regarded operation modes are selected in
design form based on the requirements of the process
to be controlled. Second Step: the transitions and
switching conditions between states (modes) are
defined. Third Step: the resulting design form along
with additional specifications of the modes is
transformed into a model such as Grafcet or Petri net.
Based on this model, the implementation is started
into low level languages. GEMMA is quite general,
i.e., not specific to any special kind of controlled
process. However, GEMMA is a manual process, i.e.
there are no tools supporting it directly. Hence, it is
not easy to integrate GEMMA into a modern
development process.
Another guideline for OMs in manufacturing control
is the S88 standard from ISA. It used specifically to
guide the development of batch control processes.
S88 uses three modes for procedural elements (i.e.,
automatic, semi-automatic and manual) and two
modes for basic control (i.e., automatic and manual).
A mode in S88 determines how equipment units and
procedural elements respond to commands and how
they operate. There are two important elements in a
mode, i.e., procedural states and commands. In
procedural states, four kinds of states are employed:
initial, final, transient and quiescent. The initial state
is a position where the process is started or launched.
The final state is a status where the process is
completed, e.g. state complete. The transition state is
a related activity to accomplish particular tasks and
its state name always ends with “ing”, e.g. holding,
restarting, running, pausing, stopping, and aborting.
The quiescent state confirms the status when an
activity has been done and contains no process
activity. For instance, some states named held,
paused, stopped, and aborted are categorized as
quiescent. Additionally, the proposed commands
used to enable a state of activity include start, stop,
hold, restart, abort, reset, pause and resume. The
OMs allow modular batch automation implementing
a series of control steps (traditional DCS).
The third guideline is named PackML which is
proposed by Open Modular Architecture Controls
(OMAC) users group. The guideline is specialized
for packaging machinery automation. Three proposed
modes include automatic, maintenance, and manual,
while three categories of state are acting state, wait
state, and dual state. Some valid states are Stopping,
Stopped, Aborting, Aborted, Resetting, Idle, Starting,
Execute, Suspending, Suspended, Unsuspending,
Holding, Held, Unholding, Clearing, Completing and
Complete. The transitions between states are the
result of manual intervention, changes of the process
status, or completion of a mode state. Furthermore,
two different modes are defined: unit control and
procedural mode. A mode manager has also been
included to manage unit mode change.
For the three presented approaches to be compatible
with DAS implementations extensions should be
provided so that the OMs in each sub-system and
their corporation could be detailed unequivocally.
3. THE PROPOSED OMs GUIDELINE
For the latest technology in automation i.e., DASs,
OMs guidelines are rarely dealt with. Some standards
in this area such as IEC 61804 (IEC, 2000) and IEC
61499-1 (IEC, 2005) have mentioned such terms. Yet
those standards provide inadequate specific details.
In IEC 61804, OM is defined as managerial function
and some OMs are mentioned without sufficient
details. In IEC 61499-1 the explanation of operation
mode is too short and focused on the operation of
software components (mode of a function block)
Therefore, the guideline specified in this work is
based on the ideas from GEMMA, S88 and PackML.
The modes in DAS may cover two areas: system and
sub-system (cf. Fig. 1). The system is the integration
of all sub-systems via system bus. The sub-system is
a set of elements, which is a system itself, and a part
of the whole system communicating via system
and/or local bus, e.g., cell system, work-stations,
machines. The proposed OMs guideline considers
both areas. Normal operation mode is general and
may be implemented in different levels.
Fig. 1. Areas of a DAS as a concern of OMs
For uncritical systems it is often sufficient to put only
one OM feature to a system level. However, OM
features can also be put in each sub-system which
seems to be a better solution for the DASs. A central
command for all those OMs can still be built at
system level, e.g., Estop command could be linked to
Abort command in all the sub-systems.
In the following, UML state machine is used to
model OMs. UML provides reusability of models
and can be directly employed for implementation
based on the object-oriented idea. The UML state
machine consists of states (atomic or process) and
transitions. An atomic state holds a status until its
post transition is enabled whereas a process state
contains a sequence of operations to be executed
when the state is active.
3.1. General model of OMs
Fig. 2 shows the five modes which are proposed here
for a general model of OMs using UML state
diagram. Each mode can be defined as follows.
Automatic pertains to the process or operation which
runs automatically based on the control algorithm
from one state to another when the respective
conditions are met without intervention by an
operator. However, the operation can be held or
aborted via an emergency condition. Manual
represents the processes operated by mechanical
force, applied by personal intervention where the
order is specified by an operator. Semi automatic is
a combination of manual and automatic features. A
manual command is required to enable the automatic
feature to execute a function or a part of a process.
Test is a mode dedicated to validate the system, off-
line or on-line to check the control logic. Emergency
stop (Estop) can be defined in two different ways
depending on the controlled system. Firstly, when the
push button corresponding to Estop is pushed, the
process is stopped and can not be restarted to
continue the previous operation. It should not be
creating a hazardous condition. The system must be
reset to the initial condition so the process starts from
the beginning. This method is very common and is
used as Estop definition in the general model of OMs
and as Abort command in the sub-systems. Secondly,
pushing the Estop button immediately stops all
operations. In this case, the previous process and the
remaining tasks are possible to be restarted. This kind
of Estop is named Hold on sub-system level.
Fig. 2.State machine of general OMs for a system
3.2. Automatic Mode (Sub-system level)
Fig. 3 shows the state machine for automatic mode.
The atomic states are ready, stopped, aborted, held,
error handled, and stand-by. Process states are
Starting-up, Normal Production, Holding, Error-
handling, Stopping and Aborting. When the
Automatic mode is selected, the initial state in this
mode is Stopped. The next state is either Setup or
Production_Process. In Setup software parameters as
well as positions of mechatronic devices are
initialized. When those activities are finished, the
process is started by moving to Stand-by state. Run
condition starts to Normal_Production automatically.
Fig. 3. State machine of automatic mode
The process can be stopped or aborted from all states.
Stopping executes the logic which brings the machine
to a controlled and safe stop. It is normally caused by
the fulfillment of provided conditions (e.g. elapsed
waiting time. Abort (Aborting → Aborted) state can
be entered at any time in response to the emergency
stop command in the sub-system. Since its domain is
only in the sub-system, it can not force other sub-
systems in the system level to stop. An emergency
stop of the entire system level can be done by Estop
command (Fig. 2). After aborting the process has to
be reset to the initial state via Stopped.
3.3. Semi-automatic Mode (Sub-system level)
A UML state machine for semi-automatic mode is
shown in Fig. 4. The activity outside the production
process reveals the similarity with the automatic
mode model. However, the state model inside the
production process is quite different. After the stand-
by state has been reached the process will be started
partly and manually. A process part (batch) could be
compounded as a sequence of tasks which run
automatically. When the processes have been done,
the operation will move to stand-by state and wait for
another manual start before continuing the process.
Each process part can still be held by human
intervention. After it is restarted, it will be waiting
for a Run command in the stand-by state.
Fig. 4.State machine of semi-automatic mode
3.4. Manual Mode (Sub-system level)
In manual mode, the model becomes simpler (see
Fig. 5). The starting-up is done manually as well as
the process sequences. This means that each task is
done one by one responding to the manual start from
an operator. For an interruptible task, its progress can
be held and later be continued. The process can be
stopped or aborted easily. This mode is usually used
when there are problems in the automatic process.
Fig. 5.State machine of manual mode
3.5. Emergency Stop Mode (System level)
Once the Estop button is pushed the process will be
stopped and some data is recovered for diagnosis (cf.
Fig. 6). This mode has the highest priority. It can be
activated even when processes is still running.
Fig. 6.State machine of Estop mode
3.6. Test Mode
The specification of the test mode highly depends on
the requirements of system, user and developer.
Therefore, the test mode is hard to be generalized.
This mode allows, for example, off-line simulation to
test the control logic using a particular testing tool or
on-line testing to check the reliability of the
employed mechatronic components. Some on-line
testing considering the steps of operation can also be
done using the manual mode in normal operation.
4. RESETTING AND RESTARTING PROCESSES
Resetting and restarting are necessary if work was in
progress and an abort or hold command had
occurred. In resetting, it is clear that all the
production processes should be started from the
beginning (initial condition). Hence, the parameters
should be reset to initial values. The initial position
of each mechatronic device later will be set by a
starting-up activity in each operation mode.
Restarting is an attempt to continue the previous
process after it was held by human intervention. This
activity should be handled carefully since there are
several possible ways to do it. Depending on the
controlled process, the interrupted task may be
restarted from the beginning or from the point where
it was stopped. Alternatively the last task is ignored
and the process goes on with the next task.
There are several approaches to give a better way to
restart a machine after a hold or pause and continue
the previous process. In (Tittus, et al., 2000), a restart
points approach is applied to production states from
which a cell can continue its work after the
occurrence of an error. A similar approach is
proposed in (Loborg and Törne, 1996). However, the
number of restart paths, which are employed in each
state, can become very large. In (Klein, et al., 1996),
an approach for re-planning an assembly line after an
error is presented. A quite powerful processor is
required to deal with this approach. (Brandin, 1996)
includes error recovery in the system specification by
assuming that errors can be foreseen and later on
automatic recovery can be done off-line as in
(Adamides, et al., 1996). Nevertheless, in many
applications it is hard to foresee the errors that may
occur especially after human intervention. A method
to resynchronize and restart a manufacturing system
after the occurrence and subsequent repair of a fault
is proposed in (Andersson, et al., 2006).
In DASs production tasks are distributed over several
components. Therefore, the restart of a production
means restarting the component executions. The
proposed way of handling re-starting depends on the
existence of a synchronizer component capable of
supervising the currently executed tasks. Section 6
will present the corresponding software architecture
and provide an example.
 5. TRANSITIONS BETWEEN MODES
For the transitions between modes two cases are
distinguished: (1) transitions between modes inside
normal operation and (2) transitions between normal
operation modes and the other states shown in Fig. 2.
5.1. Transition in Normal Operation
Normal operation has three modes: automatic, semi-
automatic and manual. The models of these modes
(see Fig. 3-5) show a similar structure with some
differences inside the production process state. The
main difference lies in the handling of the normal
production. In automatic it is done automatically, in
semi-automatic it is done part by part manually but
inside the part the processes run automatically, while
in manual, the process order is done manually step by
step. The key of the transition between the modes is
to memorize the currently executed step. For
example, in the normal production state in automatic
process there is a task sequence which should be
done. Let say that the normal production is
employing the third step, so in order to move to semi-
automatic mode then the process should be held.
Semi-automatic should be selected and then the
process can be restarted by going directly to the third
step. Concisely, the transition between modes in
normal operation always contains the following
steps: (1) hold the normal production, (2) memorize
what step is stopped (manually or automatically), (3)
change the mode, and (4) restart the process and
continue the memorized step after the run condition
is enabled.
5.2. Other Transitions
Other transitions manage the relationships of
operation modes in the normal operation to the
emergency stop and test mode as well as to the
atomic states OFF and IDLE. At the beginning the
system of course is off (without power). When it is
turned-on, the process will be in idle position waiting
for a command. From here there are four options, to
test mode, to a mode in normal production,
emergency stop or turning off. The transition of them
should be considered case by case. For instance, the
process in a particular mode in normal operation will
be stopped dramatically by issuing an Estop signal.
After Estop the system will be moved to a safe state.
From this, the normal operation is not allowed to be
restarted. Hence, resetting to the IDLE state has to be
done first. Another option is to turn off the system
from the Estop mode. Therefore, the Estop mode
here should be issued only in emergency cases that
can not be handled by holding the system or stopping
a sub-system. In case that the solution can be done by
holding the process the hold command as a soft kind
of stop can be given as a manual intervention. In
other cases, a sub-system can be stopped
dramatically using abort command which has a
similar function as emergency stop but it is
implemented in the sub-system, not for the whole
system. For example, a system has four sub-systems
and each of them has their own Estop named abort.
Furthermore, some transitions may depend on other
sub-systems. In this case the relevant information has
to be managed globally or distributed via the
network. For example, step 3 in sub-system II which
has a task to assemble a work piece should be
waiting the finalization of step 2 in sub-system I
which has the task to supply a work piece. Therefore,
sub-system II should go to stand-by until sub-system
I reports the successful execution of step 2.
6. IMPLEMENTING OMs IN DAS
The approach for implementing OMs here is based
on Functionality Based Control (FBC) and the
Scheduler-Selector-Synchronizer Architecture (S³).
FBC is an approach to build software controllers
based on common functionalities of mechatronic
devices. The goal is to improve reusability by using
provided functional objects to control different
mechatronic components. However, the interactions
among components in many cases are very complex.
Consequently changing the scenarios of component
execution becomes hard. As a solution, S³ is
proposed. Scheduler is employed to receive schedule
scenarios, manage them, and issue tasks. Based on
the issued tasks, Selector will execute the controlled
objects. Synchronizer will confirm the execution to
Scheduler. Based on the confirmation, Scheduler will
take a decision for the next action. In Scheduler,
schedule scenarios are representations of OMs. For
example, a process employs four components, i.e.,
conveyor (C1), rotary table (C2), driller (C3), and
tester (C4). The components provide one or more
functionalities indicated by the dot-notation below
(e.g. C4.pull and C4.test). The sequence of operation
(SOP) for each state in the automatic mode can be
represented as follows:
Automatic Mode (M1):
S1: Starting-up = <C3.pull || C4.pull, C2.move>
S2: Normal Prod. = <C1.move, C2.move, C3.drill,
C2.move, C4.test, C2.move >
S3: Holding S2.3
S4: Error_handling S2.4
S5: Aborting S2.4
S6: Stopping S2.2
In this example S1 and S2 are process states
containing several steps. In sequence S1, components
C3 and C4 are run concurrently in the first step
(S1.1). Thereafter C2 is executed (S1.2) finally S1
will move to ready state after all tasks are completed.
Start then establishes normal production, i.e.,
sequence S2. In holding an operation step, there are
three possible cases: (1) task finished, (2) undone and
uninterruptible task, or (3) undone and interruptible
task. For instance, the third step in sequence S2
(S2.3), i.e., C3.drill process, is held. The possible
cases for this process are (1) and (3). If the drill
process is restarted, it will start the forth sequence on
case (1) or continue the previous task on case (3). For
Error_handling S2.4, error on C4.test component will
be repaired. Later the normal production will be
restarted from the forth sequence. Additionally, the
interrupted sequence is recorded for diagnosis, e.g.
state S5 is enabled as the aborting of S2.4 operation.
SOPs of process states in semi-automatic mode (M2),
manual mode (M3) and Emergency-stop mode (M4)
can be represented in similar way. Changing the
modes from M1 to M2 is also possible. For example,
automatic mode process held on M1.S2.3 can be
restarted in manual mode M2.S2.4.
The architecture combining FBC and S³ in sub-
system level is shown in Fig. 7, including OMs.
Command of Operation (COP), such as Start, Restart,
Hold, etc., is issued to Scheduler via the network
using the signals sent from a console device. The
sub-system will respond to the command and process
the Sequence of Operations (SOP) related to the
selected OM. Therefore, SOPs for all OMs have to be
pre-defined and either stored internally in the devices
or submitted from the console via the network. Data
of Operation Restrictions (DOR) can be added to
describe restrictions on the schedules. Moreover,
some critical commands such as Estop/abort or hold
will be sent not only to the scheduler but also to all
components as controlled objects. Based on the
information of component execution in Synchronizer,
Scheduler will restart a held process.
COP: Command of Operations
OMs: Operation modes
SOP: Schedules of Operations
DOR: Data of Operation Restriction
Fig. 7. Example of OMs implementation in DAS
7. CONCLUSION AND OUTLOOK
In this paper, an approach to handle operation modes
(OMs) of a system and its sub-systems especially for
distributed applications has been elucidated. Design
models using UML state machine have been depicted
to describe its behavior. The OMs model is not meant
to be implemented as a controller, but as scenarios to
enhance the controllability of the system. Therefore,
modes here are part of the controller employed by
scheduler, selector and synchronizer to manage the
execution of components as controlled objects. By
providing this guidance, it is expected that the
developer starts to consider the OMs at an early stage
of system development. Future work is directed at
fully integrating the OMs into the UML-based
development process for distributed automation
systems presented in (Panjaitan and Frey, 2006).
REFERENCES
Adamides, E., E. Yamalidou and D. Bouvin (1996) A
systematic framework for the recovery of
flexible production system, Int. Journal of
Production Research, Vol. 34, no. 7, pp. 1875-
1893.
Andersson, K., Lennartson, B. and Fabian, M. (2006)
Restarting flexible manufacturing systems;
Synthesis of restart states, Proc. of the 8th
International Workshop on Discrete Event
Systems, pp. 201- 206.
Brandin B. (1996). Error-recovering supervisory
control of automated manufacturing systems,
Integrated Computer-Aided Engineering, Vol. 3,
no. 4, pp. 255-267.
Panjaitan, S. and G. Frey (2006), Designing
generic/reusable functionality based controllers
for distributed control using UML, Proc. of the
22nd IEEE Int. Conf. on Robotics and
Automation, Florida (USA), pp. 321-326.
IEC (2001). IEC 61804: function blocks (FB) for
process control - part 1 overview of system
aspects, Committee Draft for Vote (CDV), 2001.
IEC (2005). IEC 61499-1: function block – part 1:
architecture, IEC International Standard Press.
Klein I., P. Jonsson and C. Backstrom (1999).
Efficient planning for miniature assembly line,
Vol. 34, No. 7, pp. 1875-1893.
Loborg, P. (1994). Error recovery in automation – an
overview, AAAI Spring Symposium on Detecting
and Resolving Errors in Manufacturing system,
Stanford, USA, 1994.
Loborg, P. and A, Törne (1996). Towards error
recovery in sequential control applications, Proc.
of the 6th International Symposium on Robotics
and Manufacturing, Montpellier (France), pp.
377-383.
Moreno, S. and E. Peulot (1997). Le GEMMA –
Guide d’Etude des Modes de Marches et
d’Arrêts, Educalivre, Paris (France).
OMAC (2006). Packaging Machine Language V3.0
Mode & States Definition Document, OMAC
Motion for Packaging Workgroup.
Parshall, J. and L. Lamb (1999). Applying S88: Batch
Control from a User’s Perspective, ISA Press.
Tittus, M., S.–A. Andréasson and A.P. Adlemo
(2000). Fast restart of manufacturing cells using
restart points, Proc. of the 4th World Automation
Congress, Wailea (Maui).