A Service-Oriented Domain Specific Language

Programming Approach for Batch Processes

Martin Melik Merkumians, Matthias Baierling, Georg Schitter
Automation and Control Institute, Technische Universität Wien
Gußhausstraße 27-29/E376, Austria, Vienna
Email: {melik-merkumians, baierling, schitter}@acin.tuwien.ac.at

Abstract—The demand for flexible automation architectures in systems and novel approaches to this problem were proposed
industry is raising, due to the trend to individualized products and analyzed by academia.
and the shortening of product life-cycles in general. Current The application of Service-Oriented Architecture (SOA)
approaches in automation systems are either only suited for a
small range of processes or are only reprogrammable by software concepts to the automation domain [2] has been first proposed,
and automation experts. The presented domain specific language as automation systems nowadays are mainly networked and
based approach decouples production-domain concerns from the distributed systems, and with the rise of Ethernet-based field-
automation program, by separating the process description into buses the application of standard web technologies, namely
a specialized domain language. This domain language can be web-services, was natural. The EU projects SIRENA [8]
used by plant owners and domain experts to define and execute
vastly different processes, as long as the needed process steps and SOCRADES [9] pioneered in using web-services for
are supported by the actual automation system. This contribu- automation systems but were primarily concerned with the
tion demonstrates the development of a domain-centric SOA- technical implementation of services and less with the overall
based batch process automation system, by creating a directly design approach suited for automation systems.
executable DSL based on domain terms found in ISA-88. Although web-services presents a possible technical solu-
I. I NTRODUCTION tion, it is not a well established standard technology in the
automation domain, like classic OPC or OPC Unified Archi-
Until recently it was sufficient to optimize a manufacturing tecture (OPC UA). The suitability of OPC UA for SOA-based
system for just one or a small range of processes. The cur- automation systems is analyzed and an application example
rent trend towards individualized products and the associated in the domain of process industry is used to demonstrate
demand for mass customization, as well as the shortening of the IEC 61499 – Function blocks [10] standard and OPC
product life-cycles, leads to a reduction in lot size and an UA can be combined in order to create an SOA system and
increasing number of product variations. Rigid automation expose the provided services in the address space of OPC
systems cannot cope with the actual market situation, and UA [11]. The applicability of OPC UA as a middleware for
industry is in search for more flexible solutions and starts the process industry, using the ISA-88 – Batch Control (ISA-
to abandon inflexible production lines [1], [2], [3]. Apart 88) reference model [12] has been demonstrated [13]. An
from the novelty of the requirements and the associated trend orchestration engine based approach has been proposed, which
to modularization and flexibility, one reason for inflexible allows simplifying Programmable Logic Controller (PLC)
automation systems is that manufacturing plants are usually programming, by splitting the desired action sequence of a
treated as one-of-a-kind products themselves [4]. In other plant component into higher level abstractions [14]. In the
words, you never build the same plant twice, and therefore, any presented application case of a pick-and-place crane these
investment in modularization and reusability was perceived as abstractions are lift, lower, and turn left and by sequencing
uneconomical. Currently, 55% of production system creation them into a workflow development effort can be reduced.
costs are spent on planning, engineering, programming, and Agent-based approaches were also considered as an alter-
system ramp-up phase of a manufacturing plant [5]. Industry is native to traditional automation systems [15], presenting a
demanding a novel approach to system design and integration three-tiered architecture separating an automation system into
which is expressed by several industry-driven initiatives like an agent-based control system for the High-Level Control
Industry 4.0 in Germany or Industrial Ethernet in the USA [6], (HLC), a real-time capable control layer for the Low-Level
[7]. Flexible solutions, however, are introducing a lot of added Control (LLC), and the physical system layer. Although the
complexity to automation systems, with the cause lying in the general idea is quite intriguing, this work does not clearly
need to support a large range of processes, process variations, explain how the physical layer is separated from the LLC.
retooling, changes to process intra-logistics, and the associated Also, it is not well explained on how the HLC can be reused
plant reconfigurations, just to name a few. easily. Another agent-based control system for the process
Traditional development approaches are not well suited to domain focuses on path finding and path recovering in the
support the development of such highly complex and flexible case of a fault [16]. An agent-based approach for controlling
978-1-5090-1314-2/16/$31.00 © 2016 IEEE the patching process of wood panels [17] decomposes the

Authorized licensed use limited to: Universidad Del Norte Biblioteca. Downloaded on October 19,2024 at 09:03:35 UTC from IEEE Xplore. Restrictions apply.
plant into components, where each component is controlled IEC 61131 compliant code from the models, which enables
by a dedicated agent, the so-called automation agent. Each the use of current technology. Results show a significant
agent exposes functions which can be used by other agents increase in software quality due to an extensive modeling of
in the system too [18]. Tasks like process scheduling, which the problem domain but is not concerned to increase flexibility
cannot be directly associated with a mechatronic component and reusability of plant components.
are represented by a special type of agent, the functional agent. Similar ideas are also pursued in the MEDEIA approach,
Although academia has seen agent-based control systems which defines several Domain Specific Languages (DSLs)
as a promising technology, such systems were never in wide- for the different engineering aspects and by integrating these
spread use in industry, due to the lack of real industrial domain-specific views together in the MEDEIA model, auto-
applications, missing trust in the idea of delegating tasks to matic automation system code generation shall be enabled [4],
autonomous agents [19], and concerns regarding the stability, [5], [25], [26].
scalability, and survivability especially in unpredictable envi-
All the presented approaches have in common, that a soft-
ronments of attacks and system failures [20].
ware/automation expert is needed to implement the changes
An alternative approach coping with the complexity of mod-
required for implementing a new process or for variations of
ern automation system are model-based development methods.
the plant. This is due to the resulting PLC code is usually
Model Driven Architecture (MDA) approaches are capable of
being tightly interconnected with the desired process as well as
separating the logical application of an automation system, the
the hardware-specific implementation (see [15], [18]), and the
Platform Independent Model (PIM), from its implementation
design process itself is designed to be handled by a software
details of the targeted goal-platform, the Platform Description
or automation engineer and not by the domain expert [21],
Model (PDM). Both models are then combined to generate an
[24], [25].
executable automation program (the Implementation Specific
Model (ISM)) [21]. Such and MDA approach is applied to This contribution proposes a novel DSL based approach
automation systems, but with focus on the reusability of decoupling the desired production process from the automation
IEC 61499 programs and Function Blocks (FBs), whereas code itself. Instead of augmenting traditional software engi-
the PIM is defined by a Function Block Network (FBN). neering processes, it focuses on the view of the plant operators,
This FBN includes concrete implementation of the automation by making the process description (or process recipe) the
program, which can be expressed without any hardware- central element of the automation system design. Through a
specific implementation details [22]. Hardware interfaces (e.g., careful separation of domain concerns and implementation-
a sensor, or a pick and place unit) are communicated with dependent aspects, the process recipe becomes a first-class
and to via messages, which abstract the concrete hardware entity in the automation system, either being interpreted on
access, but gives the needed implementation detail in order to the fly or being used to generate automation code. The domain
execute a program step (e.g., the next desired pose of a pick concerns are then exposed via services in a SOA [27] approach
and place unit). These messages are received by the abstract via the responsible automation components to the system.
FB and forwarded via an Adapter Function Block (AFB) to This separation enables the enhancement of reusability of
a concrete implementation Service-Interface Function Block production processes and leads to an improved modularization
(SIFB) for execution. of automation components, as single tasks and responsibilities
Object-Oriented (OO) design approaches are suited and are expressed via the process recipe. This will allow the plant
used to hide the implementation-specific details from the user operator to define and program his desired processes without
of the system via abstract classes or interfaces. An application the help of an automation engineer, as long as the plant and the
of this approach on automation systems combines intelligent DSL can cope with the new process. As the proposed approach
sub-plant components, so-called mechatronic objects, which is highly dependent on a particular application domain, the
represent a combined hard- and software component, in an proposed approach is validated by an example in the process
OO manner in order to create automation solutions [18]. Each domain. The demonstrator for this approach is the Festo
component contains a scheduler, a selector, and a synchronizer. Didactic process tank model [28], as shown in Fig. 1.
These mechatronic objects are only controlled via a set of The remainder of this contribution is structured as follows.
functions which the component provides. The programmer In Section II the Process Recipe DSL is introduced, giving
also provides the schedule of operations to the scheduler insight into the design process of such a DSL. Section III
for execution. Although an interesting approach, mainly the introduces a helper DSL, which is needed to describe the plant
theoretical foundation and almost no implementation details in order to perform recipe expansions for creating executable
are presented. recipes. Section IV gives an implementation example on how
Another MDA-based approach, which adapts the System to implement domain services in IEC 61499 and describes
Modeling Language (SysML) notation providing a special- details on the used system configuration. Section V demon-
ized language profile SysML-AT, is capable to completely strates the successful implementation via experiments, giving
replace traditional IEC 61131 – Programmable controllers [23] time charts of a recipe phase execution to demonstrate the
languages [24]. These custom models describe the key facts functionality of the system. Section VI concludes the work
of the desired automation solution and is used to generate presented in this paper.

Authorized licensed use limited to: Universidad Del Norte Biblioteca. Downloaded on October 19,2024 at 09:03:35 UTC from IEEE Xplore. Restrictions apply.
 its execution shall only occur in parallel to a dominant phase.
T102
The analysis of ISA-88, [30], and [32] has shown, that

T310

T320

T330

T340
T350
process domain recipes consist of sequential processes, and
T101 parallel processes (AND branching) and conditional processes
OR branching. Conditional processes are usually used to
implement error handling routines or enable the execution
of equivalent processes, based on certain plant states (e.g.,
available raw materials).
Based on these findings and the requirement that the DSL
shall be executable (see Section I), the first step is to define the
execution model for the PRD. As ISA-88 the PRD has a Petri-
net like execution semantic similar to SFC, enabling sequen-
Fig. 1. Festo Didactic process industry demonstrator plant (left) and custom tial and parallel processes, with the exclusion of conditional
built storage tank system (right), showing the tank labels as used in Fig. 2
processes. The reason behind this restriction is to keep the
focus on the desired process. Alternative equivalent processes
II. P ROCESS R ECIPE DSL are expressed as separate processes, but this imposes not a
real restriction to the overall system, as the concrete process
The standard ISA-88 [12] is taken as a role model for the to be executed can be selected, based on the current plant
creation of the Process Recipe DSL (PRD). ISA-88 reflects the state, before the execution of the desired process starts. Also,
acknowledged state of practice in the batch process domain, the PRD includes the concept of dominant and non-dominant
as it is defined by an expert group of this domain, which phases in order to provide simple means to describe dependent
makes it highly suitable as a basis for the PRD. Also, it parallel processes.
defines and explains the batch process domain terms and With the execution mechanics now defined, the next step is
concepts thoroughly, which makes it a very useful source of to define the available steps for execution. Here the ISA-88
information for non-domain experts. As the ISA-88 defines process actions directly translate to the available steps in the
terms and concepts from the Enterprise Resource Planning PRD.
(ERP) layer to the machine layer, the remainder of this section • Start – As in SFC this is the starting point of a recipe.
will focus on the domain concepts and process sequence • Stop – As in SFC the end point of a recipe.
execution semantics needed for the definition of the PRD. • Add – The added substance is measured in <l>.
The first needed term is the process reactor, which is men- • Heat – The desired temperature given in < C>.
◦
tioned but not specifically defined in ISA-88. In principle, it is • Agitate – No parameters, as it is designed to be a
a single physical unit in a batch process plant providing mate- dependent phase.
rial transformation capabilities, like heating, cooling, or similar
Following the concepts of ISA-88 that process actions are
capabilities, and is one of the basic building blocks of most
executed on process reactors, all PRD steps have the unique
batch process plants. ISA-88 names three concepts that are
identifier of a process reactor as a mandatory parameter.
directly concerned with the production process, process stages,
Additional parameters are based on the needed parameters
process operations, and process actions. Process stages which
associated with the represented activity itself. Listing 1 gives a
represent complex processing sequences (e.g., polymerize) and
shortened version of the Extended Backus–Naur Form (EBNF)
process operations which represent major processing activities
of the PRD developed in Eclipse Xtext [33], a framework
(e.g., Prepare reactor) are high-level process abstractions.
for developing DSLs. Xtext specific import and generate
process actions low-abstraction, describing singular process
declarations in this and all other EBNF definitions are omitted
steps together with its associated domain-relevant parameters
for conciseness.
(e.g., Heat the reactor to 55–60 ◦C), without giving details
on implementation and execution details. ISA-88 names a Listing 1
EBNF OF THE P ROCESS R ECIPE DSL
handful of examples for process actions, e.g., Add, Heat, and
Hold, with [29] and [30] expanding the set with Agitate. Also, Model:
ISA-88 indicates that process actions are executed on process {Model}
’Tanks’
reactors [12, p. 20] The ISA-88 process execution semantics tanks+=Tank*
is similar to Petri nets or Petri net like approaches, such as ’Recipe’
Sequential Function Chart (SFC). steps += Step*;
SFC has been enhanced in order to integrate a batch Tank:
name=ID;
execution engine into PLC code, by mapping the SFC to a
Step:
tabular notation [31]. This enhancement introduces the concept Add | Heat | Agitate | Stop | Start;
of dominant and non-dominant phases, with dominant phases Start:
indicate that termination of the phase leads to recipe transition, ’start’ name=ID (’after’ formerStep+=[Step]* )?;
whereas a non-dominant (or dependent) phase indicates that Stop:

Authorized licensed use limited to: Universidad Del Norte Biblioteca. Downloaded on October 19,2024 at 09:03:35 UTC from IEEE Xplore. Restrictions apply.
 ’stop’ name=ID ’after’ formerStep+=[Step]*; to the lower level tank. A similar concept of flow directions
Add: is used for tanks, which is necessary as some tank flanges on
’add’ name=ID ’amount’ ((amount_l=INT ’l’) | ( our demonstrator plant are positioned in such a way that a
amount_ml=INT ’ml’)) ’from’ source=[Tank] ’to
’ target=[Tank] ’after’ formerStep+=[Step]* ( bidirectional flow is not possible (e.g. a flange mounted on
dominant=’nondominant’)?; the top of a tank), which further limits possible paths in the
Heat: plant. Please note that the same direction concept for tanks and
’heat’ name=ID ’tank’ tank=[Tank] ’up to’ temp= valves could have been used, but in contrast to valves tanks
DOUBLE ’°C’ ’after’ formerStep+=[Step]* (
dominant=’nondominant’)?; have clear in an out directions both concepts have been added
Agitate: to the DSL. Pipe lengths are also considered in the model, in
’agitate’ name=ID ’tank’ tank=[Tank] ’after’ order to select a path for the Add service via Dijkstra’s shortest
formerStep+=[Step]* (dominant=’nondominant’) path algorithm [35].
?;
Listing 2 gives the shortened form of the developed Xtext
This simple DSL enables to concisely express the desired EBNF notation, which was used to describe the demonstrator
process of a process plant, without the need of information on plant.
how a process action needs to be implemented by the control
Listing 2
soft- and hardware but captures the necessary process detail EBNF USED TO DEFINE THE PROCESS DOMAIN PLANT SYSTEM DSL
needed to execute the process. The execution engine itself is
also implemented via the Xtext framework. Xtext grammars Model: entities += Entity*
points += Point*;
are compiled into traversable meta-models, which can be used
Entity: Tank | Pipe | Valve | Pump ;
to implement a language interpreter [34].
Tank: ’tank’ name = ID ’{’
III. P ROCESS D OMAIN S YSTEM M ODELING L ANGUAGE ’tankLevel’ tankLevel = INT
(’heater’ ’actuator’ heaterActuator=ID ’sensor
The PRD given in Listing 1 is enough to describe and ’ heaterSensor=ID)?
execute the desired process if everything would be in one (’mixer’ mixer=ID)?
(’levelSwitchTopAlarm’ levelSwitchTopAlarm=ID)
process reactor. Even simple plant configurations in the pro- ?
cess domain usually consist of more than one process reactor (’levelSwitchTopWarning’ levelSwitchTopWarning
and includes storage tanks, pumps and so forth, which is =ID)?
(’levelSwitchBottomWarning’
why an additional DSL is needed to model the process plant levelSwitchBottomWarning=ID)?
itself. Analyzing the demonstrator plant, shown in Fig. 1, (’levelSwitchBottomAlarm’
the following domain-relevant elements: tanks, level sensors, levelSwitchBottomAlarm=ID)?
directedConnectionPoint +=
pipes, valves, heaters, mixers, and pumps are identified. In DirectedConnectionPoint+
order to connect the above-mentioned domain elements, the ’}’;
concepts of connection points (junctions to tanks and pumps), DirectedConnectionPoint: ’directedConnectionPoint’
and nodes (junctions between pipes) are needed. All elements ’(’ connectionPoint = [ConnectionPoint] ’,’
direction=Direction ’)’;
are identified via unique IDs. Heaters and Mixers which can
ConnectionPoint: ’connectionPoint’ name=ID;
be added to Tanks, provide Tanks the capability to execute the
Pump: ’pump’ name=ID ’{’
Heat and Agitate services. ’input’ input = [ConnectionPoint]
Piping and Instrumentation Diagrams (P&IDs) do not take ’output’ output = [ConnectionPoint]
physics and the actual physical position of plant components ’}’;
into account, for example, it is not possible to determine Pipe: ’pipe’ name = ID ’{’
’length’ length=INT
the flow direction between T101 and T102. Considering our ’endPoint1’ point1 = [Point]
demonstrator plant, shown in Fig. 2, there are situations where ’endPoint2’ point2 = [Point]
the fluid can only flow unidirectional. ’}’;
For example the connection between T102 and T101 has Direction: typeName=(’in’ | ’out’ | ’bi’);
only valve V102 in between, so due to gravity, a bidirectional Valve: ’valve’ name=ID ’{’
’type’ type = ValveType
flow of fluids is not possible in this case. By examining the ’connenctionPoint1’ connectionPoint1 = [
actual plant in Fig. 1, it can be seen that T102 is on a higher ConnectionPoint]
level than T101, which is why fluids will flow from T102 to ’connenctionPoint2’ connectionPoint2 = [
ConnectionPoint]
T101. In order to reflect such situations, the concept of flow ’flowDirection’ flowDirection = FlowDirection
direction was added to valves, whereas bidirectional means ’}’;
bidirectional flow is possible, and 1to2 and 2to1 signals a ValveType: type = (’continuous’ | ’OnOff’);
unidirectional flow from valve gate 1 to valve gate 2 (gates FlowDirection: flowDirection = (’1to2’ | ’2to1’ | ’
are marked with 1 and 2 in the P&ID) and vice versa, also the bi’);
tank level concept is used to model the difference of mount Point: Node | ConnectionPoint;
height of tanks, so it can be verified that a fluid flow without a Node: ’node’ name = ID;
pump in between, is always directed from the higher level tank

Authorized licensed use limited to: Universidad Del Norte Biblioteca. Downloaded on October 19,2024 at 09:03:35 UTC from IEEE Xplore. Restrictions apply.
 LI LI LI LI LI
B311 B321 B331 B341 B351
LI
YS
T310 T320 T330 T340 T350
B101
V101
T102
2 1
1

E105 1 1 1 1 1
LAS+
V3L6 1 1 1 1 1
M
YS YS YS YS YS YS YS YS YS YS
V102 V104 V3L3 V313 V323 V333 V343 V353 V3R3 V3R8
T101
2 1 1 2 1 2 2 2 2 2 2 1 2 1 2
2 3 2
1 1 1 1 1

FI YS YS YS YS YS YS YS
LS- B102 V3L2 V312 V322 V332 V342 V352 V3R2
NC
S112 P101 2 2 2 2 2
TI 2 1 2 1 2
B104
1 1 1 1 1 1
LS- YS M YS YS YS YS YS YS YS YS
B114 V103 V3L1 V311 V321 V331 V341 V351 V3R5 V3R1
1 2 2 2 2 2 2
LAS- 1 2 1 2 1 2
1
B113 1 1 1 1 1 1
FI
E104 YS YS YS B301 YS YS YS YS
x1 x2 V3L6 V3L5 V3L4 V3P1 V3R4 V3R6 V3R7
2 2 2 2 2 2 1 2
2 1

NC
M
P301

Fig. 2. The P&ID of the demonstrator plant. The red and blue paths are dynamically calculated from the recipe given in Listing 3, as a result from the Add1
(blue) and Add2 (red) recipe steps.

IV. I MPLEMENTATION would force the implementation of both PLC code and the
process recipe application to cope with lost, duplicated, or
The process actions identified and added to the PRD defined wrong-ordered messages, the Message Queue for Telemetry
in Section II as well as a workflow execution engine needs to Transfer (MQTT) client implementation Paho [38] is used. The
be implemented for the automation system. For the purpose of only information which needs to be provided to the systems
demonstration the open source IEC 61499 project 4DIAC [36], components is the address of the message broker, the central
[37] was chosen for controlling the PLCs, as the event-driven message hub of the message queue and the topic to which
execution semantics of IEC 61499 based control systems suites the associated Publish/Subscribe FB is registered to. Another
the execution model of our DSL and SOA-based approach parameter is the device name, which is an arbitrary string used
very well. Actions are triggered and the next step is initiated to identify a device in MQTT, but the actual value is of no
as soon as the requested action has finished, which can easily consequence for the execution of the recipe engine.
be modeled via events. The recipe is executed via a simple In this demonstration, the message broker Mosquitto [39]
workflow engine, which is a piece of software that takes a is used. All messages are tagged with a so-called topic sent
process model as input, interprets the input, and performs to the message broker, which relays them to all registered
actions based on this interpretation. In this case the workflow subscribers who registered for the respective topic. MQTT can
engine executes the process recipe by starting its execution guarantee that messages are delivered once and only once, and
at the Start node, and then stepping through the subsequent in the correct order, which is necessary for the recipe execution
recipe phases, although the PRD step elements point to their system.
former steps, in order to enable that the recipe steps occur In the case of our demonstrator, two Beckhoff CX5010
in their execution order (see Listing 3). Each recipe phase PLCs are used as the control hardware platform, with FOR-
is checked if a recipe expansion is necessary, and performed DIAC RunTime Environment (FORTE) as the IEC 61499 com-
if it is. After the current step has been fully expanded the pliant runtime environment. One Beckhoff CX5010 controller
resulting service requests are sent from the PC to all PLCs, as is controlling the Festo Didactic process industry plant with
no information is given in the recipe model which controller is all the associated valves, pumps, tanks, and tank equipment,
responsible for a certain resource. This is necessary in order to the other one is in sole control of the components of custom
exclude as much plant information from the recipe as possible. built storage system, both shown in Fig. 1, forming reusable
In order to synchronize the recipe execution with the plant, the components with clear responsibilities. The EtherCAT bus
workflow engine waits for confirmation signals from the plant terminal is controlled via the Beckhoff ADS interface. Each
before it further progresses through the recipe phases. component’s capabilities are exposed via their services, which
Since the recipe shall contain as little as possible infor- are the process actions adopted in the proposed DSL (see List-
mation about the physical plant, a multicast mechanism has ing 1). The developed process recipe creation and execution
to be used to provide the capability to inform all available software is deployed on a standard PC system.
PLCs without the need to either know how many PLCs Fig. 3 shows an example FBN how to implement the Agitate
need to be informed or the hostnames or IP addresses of service in IEC 61499. Requests are received via the leftmost
the devices. Instead of using the standard TCP/IP family Subscribe FB, and buffered in a First-In–First-Out (FIFO)
multicast mechanism via the unreliable UDP protocol, which buffer for sequential execution.

Authorized licensed use limited to: Universidad Del Norte Biblioteca. Downloaded on October 19,2024 at 09:03:35 UTC from IEEE Xplore. Restrictions apply.
 PUBLISH_CONF
INIT INITO
SUBSCRIBE Label2PLCName REQ CNF
INIT INITO FIFO LabelValueSeparator INIT INITO WRITE_BECKHOFF PUBLISH_1
RSP IND PUSH CNF REQ CNF REQ CNF INIT INITO
SUBSCRIBE_1 POP ERROR ERROR REQ CNF QI QO
FIFO LblVal_Seperator Label2PLCName WRITE_BECKHOFF fbdk[].mqtt[%ip%,PLC1,AgitateConf] ID STATUS
E_PERMIT SD_1
1 QI QO
fbdk[].mqtt[%ip%,PLC1,Agitate] ID STATUS DATA_I DATA_O MSG Label Lbl2PLC.txt Filename PLC_Identifier 1 QI QO EI EO
RD_1 Value Label 851 ADS_PORT E_PERMIT
VARNAME PUBLISH_ERRO
VALUE PERMIT INIT INITO
REQ CNF
PUBLISH_1

QI QO
fbdk[].mqtt[%ip%,PLC1,AgitateError] ID STATUS
SD_1

Fig. 3. The IEC 61499 Function Block network implementation of the Agitate service. The Subscribe and Publish FBs are configured to use MQTT, the first
parameter is a placeholder for the broker IP, the second parameter is the device name, the third parameter is the topic name.

When a message is ready to be processed the message gets levelSwitchBottomAlarm B113

parsed and the PLC checks if it is responsible for the requested directedConnectionPoint(T101C01,bi)
directedConnectionPoint(T101C02,in)
resource. The received message contains the resource name directedConnectionPoint(T101C03,in) }
(e.g., T101) for which the corresponding service (selected via tank T102 {
the MQTT topic) is requested. The PLC has a list of resources tankLevel 2
it shows responsible for, and if the PLC is not responsible levelSwitchBottomWarning S112
directedConnectionPoint(T102C01, bi)
the execution ends. If the PLC is responsible, the request directedConnectionPoint(T102C02,
. bi) }
is processed and a confirmation message is published to the .
.
confirmation topic via the Publish FB on the right side. As tank T350 {
tankLevel 2
soon as the central PC received all confirmations, it proceeds directedConnectionPoint(T350C01, bi) }
the execution of the recipe. valve V101 { type OnOff
connenctionPoint1 V101C01
V. D EMONSTRATION connenctionPoint2 V101C02
The proposed domain-centric design and SOA-based im- flowDirection bi.}
.
.
plementation and execution approach is demonstrated and valve V3R8{ type OnOff
evaluated on the 7-tank batch process plant setup, as shown in connenctionPoint1 V3R8C01
Fig. 1 and Fig. 2. The execution of a process is only defined by connenctionPoint2 V3R8C02
flowDirection bi }
the sample recipe given in Listing 3 (a graphical representation
pump P101 { input P101C01
is given in Fig. 4) and the plant model as given in Listing 4. output P101C02 }
Please note that only a reduced, but meaningful, model is given pump P301 { input P301C01
in Listing 4 for conciseness. Both the sample recipe and the output P301C02 }
plant model comply to their respective EBNFs. pipe P1001 { length 6 endPoint1 T101C01 endPoint2
V103C01 } .
Listing 3 .
.
R ECIPE L ANGUAGE E XAMPLE pipe P3P04 { length 8 endPoint1 N342 endPoint2 N334
}
Tanks
T101 T102 T310 T320 T330 T340 T350
Recipe The recipe execution is started at the Start node in Fig. 4,
start Start and as the start node execution is finished immediately the
add Add1 amount 2000 ml from T310 to T101 after single following step Add1 is triggered. As it can be seen
Start
agitate Agitate1 tank T101 after Add1 nondominant in Listing 3, the Add1 service step shall move 2000 ml from
heat Heat1 tank T101 up to 50.0 °C after Add1 T310 to T101, without giving details on how this can be
add Add2 amount 2000 ml from T101 to T102 after performed on the sample plant. The recipe execution system,
Heat1 Agitate1
stop Stop after Add2 therefore, triggers a recipe expansion procedure for Add1. In
order to create this additional information a path from T310 to
Listing 4 T101 is analyzed. In the first step, the pathfinding algorithm
TANK S YSTEM L ANGUAGE E XAMPLE checks if there is a gravity based route from T310 to T101.
tank T101 { As no such route exists, a route via the available pumps has
tankLevel 1 to be found. Utilizing Dijkstra’s shortest path algorithm [35],
heater actuator E104 sensor B104 the shortest partial routes starting from the start point of the
mixer E105
levelSwitchTopAlarm S111 Add1 step (T310) to both pumps (P101 and P301), and from
levelSwitchBottomWarning B114 both pumps to the goal tank (T101), of course without the

Authorized licensed use limited to: Universidad Del Norte Biblioteca. Downloaded on October 19,2024 at 09:03:35 UTC from IEEE Xplore. Restrictions apply.
 Start Start

Add1 *
T102 Level
Monitoring * V103 V101 P101

Agitate1 Heat1 *

Stop
Add2 *
Fig. 5. The generated internal structure of the Add2 service step, pumping
the fluid from T102 to T101, via the red-highlighted path in Fig. 2 (an asterisk
indicates a dominant phase [31], as defined in Section II).
Stop

In the last to final process step Add2, another recipe expan-

Fig. 4. The graphical representation of the recipe example given in Listing 3 sion analogously to Add1 is performed. After calculating the
(an asterisk[*] indicates a dominant phase [31], as defined in Section II).
transportation path from T101 to T102, the participating plant
components, V103, V101, and P101 can be identified. This is
possibility to reuse the paths used in the first calculation step. again shown in Fig. 2 by the red path, and the corresponding
The resulting path lengths are saved for the final construction sub-recipe is given in Fig. 5.
of the route, which is derived by combining the respective The execution of the sub-recipe, as shown in Fig. 6, and
partial routes (the shortest path from T310 to P101/P301 and the measured associated process variables of the sample plant
from P101/P301 to T101) are summed up and choosing the are given in Fig. 6. The top chart shows the time response
path with the minimum length in the end. The path lengths are of the level sensor of tank T102. The second chart shows the
obtained from the plant model given in Listing 4. Based on the state of the valves and pump, where on means that the valve
obtained final path plant components, which are participating is open and respectively the pump is active, and off means the
in the path are identified via the plant model, and the needed valve is closed and the pump is inactive. The third chart shows
activation commands for the components are generated. For the flow sensor (B102) value for pump P101. The lowermost
the Add1 process step, the participating components can be charts show the message flow for initializing the Add2 process
seen in Fig. 2, by examining the blue path, starting from as well as the end of the Add2 process.
T310 to V313, V3L6, P101, and over V104 finally into T101. As it can be seen in Fig. 6, after issuing the commands for
The activational services for these components are generated watching the tank level of tank T102, and to open the valves
as non-dominant phases, while the dominant phase in the V103 and V101, and the activation of pump P101, the flow
generated recipe is the Level Monitoring. The generation rules through the pump and the tank level is rising. As soon as the
for the Level Monitoring service as part of an add service are tank level is increased by the requested 2.0 l (see Listing 3),
as follows: the PLC is sending a signal that the requested tank level has
been reached, which prompts the recipe workflow engine to
1) The goal value is the desired value of the corresponding issue the requests to turn off the pump and to close the prior
add service. opened valves, therefore stopping the flow through pump P101
2) If the target tank has a level sensor, this sensor is used and stabilizing the level of T102.
to measure the transported fluid.
3) If the target tank does not have a level sensor, but the VI. C ONCLUSION
source tank has one, then the source tank sensor is used The presented novel SOA-based DSL driven programming
to measure the transported fluid. approach for batch process programming, enables plant oper-
4) If both tanks do not have a sensor, then the transported ators to easily create and change process recipes without the
fluid is estimated via the pump flow. support of automation experts, as the recipes themselves are
According to these rules, the Level Monitoring service is based on domain expert terms. In addition, it allows the reuse
generated for T301. of process recipes on different plants without adaption, and
After the Add1 service is successfully executed, the non- is able to cope with plant structure changes and faults during
dominant process step Agitate1 and the dominant process step execution time due to its interpreted nature. In this contri-
Heat1 with a goal temperature of 50 ◦C on tank T101 is bution, we have successfully developed and demonstrated a
executed. As all services are available and localized in T101 DSL driven programming approach for the batch processing
the execution of both process steps start immediately. domain on a Festo Didactic batch process plant. By focusing

Authorized licensed use limited to: Universidad Del Norte Biblioteca. Downloaded on October 19,2024 at 09:03:35 UTC from IEEE Xplore. Restrictions apply.
 level in mL 7000
using the open source IEC 61499 development environment
6000 Framework for Industrial Automation & Control (4DIAC) is
T102
5000 given.
4000
0 10 20 30 40 50 60 R EFERENCES
time in s

on
[1] T. Cucinotta, A. Mancina, G. F. Anastasi, G. Lipari, L.
Valves, Pump

V101 Mangeruca, R. Checcozzo, and F. Rusina, “A real-time

V103
P101 service-oriented architecture for industrial automation,”
off IEEE Trans. Ind. Informat., vol. 5, no. 3, pp. 267–277,
0 10 20 30
time in s
40 50 60
Aug. 2009.
60
[2] F. Jammes and H. Smit, “Service-oriented paradigms in
flow in mL/s

40 industrial automation,” IEEE Trans. Ind. Informat., vol.

B102
20 1, no. 1, pp. 62–70, Feb. 2005.
0
[3] S. Karnouskos, D. Guinard, D. Savio, P. Spiess, O.
0 10 20 30 40 50 60
time in s Baecker, V. Trifa, and L. M. S. De Souza, “Towards the
0 100 200 300 400 500
time
0 100 200 300 400 500 600
time
real-time enterprise: service-based integration of hetero-
PLC PLC
in ms in ms
geneous SOA-ready industrial devices with enterprise
2,2L)

;true)
;true)
true)

alse)

01;false)

01;false)
2)

applications,” in IFAC Symp. on Information Control

Filling (T10

V103;

Confirm Pump (P101;true)

Pump(P101
V101

Complete (T10
TankFilling (T102,2L)

Valve (V103;f

)
e)

01;false)
101;false
103;fals
e)

01;true)
Valve(
Valve(

Valve (V1

Pump (P1
ve(V103;tru

Problems in Manufacturing, 2009, pp. 2127–2132.

Confirm Tank

Pump (P1
Valve (V
Valve (V
Valve(V1

TankFilling

[4] T. Strasser, M. Rooker, G. Ebenhofer, I. Hegny, M.

Confirm Val

Confirm
Confirm

Confirm
Confirm

time time
Wenger, C. Sünder, A. Martel, and A. Valentini, “Multi-
PC PC
0 100 200 300 400 500
in ms
0 100 200 300 400 500 600
in ms
domain model-driven design of Industrial Automation
and Control Systems,” in IEEE Int. Conf. on Emerg-
Fig. 6. Time charts showing the execution of the expanded Add2 service as
requested in Listing 3. The top graph shows the rising of T102’s tank level. ing Technologies and Factory Automation, Sep. 2008,
The next graph shows the actual on/off state of valves V101 and V10 3, and pp. 1067–1071.
of pump P101. The third graph shows the flow-meter value B102 connected [5] T. Strasser, M. Rooker, G. Ebenhofer, A. Zoitl, C.
to P101. The bottom graphs show the communication flow of the SOA system
in the time frame depicted with the dotted lines. Sünder, A. Valentini, and A. Martel, “Structuring of
large scale distributed control programs with IEC
61499 subapplications and a hierarchical plant structure
on the domain of use of an automation system, this approach model,” in IEEE Int. Conf. on Emerging Technologies
relieves the plant operator from the burden of dealing with and Factory Automation, Sep. 2008, pp. 934–941.
automation code, in order to modify production processes. The [6] H. Lasi, P. Fettke, H.-G. Kemper, T. Feld, and M. Hoff-
desired processes to be performed on an automation system are mann, “Industry 4.0,” English, Business & Information
expressed exclusively by domain terms in the form of recipes, Systems Engineering, vol. 6, no. 4, pp. 239–242, Aug.
where automatic recipe expansion is performed in order to 2014.
fill plant-specific execution gaps. The domain terms are then [7] R. Drath and A. Horch, “Industrie 4.0: Hit or Hype?
used to implement an SOA-based automation system and [Industry Forum],” IEEE Ind. Electron. Mag., vol. 8,
automation components are exposing their domain capabilities no. 2, pp. 56–58, Jun. 2014.
via services. The approach is validated on a demonstrator plant [8] H. Bohn, A. Bobek, and F. Golatowski, “SIRENA – Ser-
from Festo Didactic, using off-the-shelf Beckhoff CX5010 vice Infrastructure for Real-time Embedded Networked
PLCs (Intel® Atom™ Z510 1.1 GHz, 512 MB) running Win- Devices: A service oriented framework for different
dows XP Embedded using 4DIAC/FORTE as IEC 61499 domains,” in Int. Conf. on Networking, Int. Conf. on
compliant runtime environment. The PLC responsible for the Syst. and Int. Conf. on Mobile Commun. and Learning
Festo Didactic process model is connected to four Beckhoff Technologies, IEEE Computer Society, 2006, pp. 43–48.
EL2008 8-channel 24 V digital output, one Beckhoff EL4004 [9] A. Cannata, M. Gerosa, and M. Taisch, “SOCRADES:
0 V–10 V 4-channel analog output, and two Beckhoff EL3064 A framework for developing intelligent systems in man-
4-channel analog output modules. The PLC connected to ufacturing,” in IEEE Int. Conf. on Ind. Eng. and Eng.
the tank storage system features two Beckhoff EL2008 8- Manage., Dec. 2008, pp. 1904–1908.
channel 24 V digital output, one Beckhoff EL4004 0 V–10 V [10] IEC TC65/WG6, IEC 61499: Function blocks for
4-channel analog output, one Beckhoff EL3064 0 V–10 V 4- industrial-process measurement and control systems –
channel analog output and one Beckhoff EL1018 8-channel Parts 1 to 4. Geneva: International Electrotechnical
24 V digital input module. The recipe execution program was Commission (IEC), 2004-2005.
run on a standard PC (Intel® Core™ i7 4800MQ 3.7 GHz, [11] M. Melik-Merkumians, T. Baier, M. Steinegger, W. Le-
16 GB) running Windows 7. The PLCs communicated with puschitz, I. Hegny, and A. Zoitl, “Towards OPC UA as
the recipe PC via standard 100 Mbit s−1 Ethernet. Last but portable SOA middleware between control software and
not least, an implementation example for a domain service external added value applications,” in IEEE Int. Conf. on

Authorized licensed use limited to: Universidad Del Norte Biblioteca. Downloaded on October 19,2024 at 09:03:35 UTC from IEEE Xplore. Restrictions apply.
 Emerging Technologies and Factory Automation, Sep. trollers,” IFAC Symp. on Inform. Control Problems in
2012, pp. 1–8. Manufacturing, vol. 48, no. 3, pp. 1573–1579, 2015.
[12] Int. Society of Automation, ISA-88 – Batch Control, [25] T. Strasser, G. Ebenhofer, M. Rooker, and I. Hegny,
1995. “Domain-Specific Design of Industrial Automation and
[13] J. Virta, I. Seilonen, A. Tuomi, and K. Koskinen, Control Systems: The MEDEIA Approach,” in 10th
“SOA-Based integration for batch process management IFAC Workshop on Intelligent Manufacturing Systems,
with OPC UA and ISA-88/95,” in IEEE Int. Conf. on 2010.
Emerging Technologies and Factory Automation, 2010, [26] T. Strasser, C. Sünder, and A. Valentini, “Model-driven
pp. 1–8. embedded systems design environment for the industrial
[14] B. Vogel-Heuser, D. Schütz, T. Frank, and C. Legat, automation sector,” in IEEE Int. Conf. on Ind. Informat-
“Model-driven engineering of Manufacturing Automa- ics, Jul. 2008, pp. 1120–1125.
tion Software Projects – A SysML-based approach,” [27] N. Josuttis, SOA in Practice: The Art of Distributed
Mechatronics, vol. 24, no. 7, pp. 883–897, 2014. System Design. O’Reilly Media, Inc., 2007.
[15] I. Hegny, O. Hummer, A. Zoitl, G. Koppensteiner, and [28] Festo. (2016). MPS® PA Compact-Workstation, [On-
M. Merdan, “Integrating software agents and IEC 61499 line]. Available: http://www.festo-didactic.com/.
realtime control for reconfigurable distributed manufac- [29] D. James, “Best of the batch [batch processing],” Com-
turing systems,” in Industrial Embedded Systems, 2008. puting Control Eng. J., vol. 17, no. 4, pp. 30–35, Aug.
SIES 2008. International Symposium on, Jun. 2008, 2006.
pp. 249–252. [30] D. Brandl, Design Patterns for Flexible Manufacturing.
[16] W. Lepuschitz, B. Groessing, E. Axinia, and M. Mer- ISA, 2006.
dan, “Phase Agents and Dynamic Routing for Batch [31] G. Godena, I. Steiner, J. Tancek, and M. Svetina,
Process Automation,” in Int. Conf. on Ind. Applicat. of “Design of a Batch Process Control Tool on the Pro-
Holonic and Multi-Agent Systems, 2013, pp. 37–48. grammable Logic Controller Platform,” in THE WBF
[17] M. W. Hofmair, M. Melik-Merkumians, M. Böck, M. BOOK SERIES–ISA 88 IMPLEMENTATION EXPERI-
Merdan, G. Schitter, and A. Kugi, “Patching process ENCES, ser. WBF book series, W. Hawkins, WBF,
optimization in an agent-controlled timber mill,” J. of D. Brandl, and W. Boyes, Eds., Momentum Press, 2010,
Intell. Manufacturing, vol. September, 2014. ch. 14, pp. 157–173.
[18] S. Panjaitan and G. Frey, “Functional Control Objects [32] W. Hawkins, WBF, D. Brandl, and W. Boyes, The WBF
in Distributed Automation Systems,” IMS’07, pp. 293– BOOK SERIES–ISA 88 Implementation Experiences,
298, 2007. ser. WBF book series. Momentum Press, 2010.
[19] K. P. Sycara, “Multiagent Systems,” AI Magazine, vol. [33] Eclipse. (2016). Xtext Framework, [Online]. Available:
19, no. 2, pp. 79–92, 1998. https://eclipse.org/Xtext.
[20] A. Helsinger, M. Thome, and T. Wright, “Cougaar: a [34] L. Bettini, “A DSL for Writing Type Systems for Xtext
scalable, distributed multi-agent architecture,” in IEEE Languages,” in Int. Conf. on Principles and Practice of
Int. Syst., Man and Cybern. Conf., vol. 2, 2004, Programming in Java, ser. PPPJ ’11, Kongens Lyngby,
pp. 1910–1917. Denmark: ACM, 2011, pp. 31–40.
[21] M. Melik-Merkumians, M. Wenger, R. Hametner, and [35] E. W. Dijkstra, “A note on two problems in connexion
A. Zoitl, “Increasing Portability and Reuseability of with graphs,” Numerische Mathematik, vol. 1, no. 1,
Distributed Control Programs by I/O Access Abstrac- pp. 269–271,
tion,” in IEEE Int. Conf. on Emerging Technologies and [36] Eclipse. (2016). 4DIAC - Framework for Industrial
Factory Automation, 2010. Automation & Control, [Online]. Available: https : / /
[22] M. Wenger, M. Melik-Merkumians, I. Hegny, R. eclipse.org/4diac/.
Hametner, and A. Zoitl, “Utilizing IEC 61499 in an [37] A. Zoitl, T. Strasser, and A. Valentini, “Open source
MDA Control Application Development Approach,” initiatives as basis for the establishment of new tech-
in IEEE Conf. on Automation, Sci. and Eng., 2011, nologies in industrial automation: 4DIAC a case study,”
pp. 495–500. in 2010 IEEE Int. Symp. on Ind. Electronics, Jul. 2010,
[23] IEC TC65/WG6, IEC 61131: Standard - Programmable pp. 3817–3819.
controllers – Parts 1 to 8. International Electrical Com- [38] Eclipse. (). Paho - Open Source messaging for M2M,
mission, 2003. [Online]. Available: https://www.eclipse.org/paho/.
[24] U. T. Bührer, C. Legat, and B. Vogel-Heuser, “Change- [39] ——, (). Mosquitto - An Open Source MQTT
ability of manufacturing automation systems using v3.1/v3.1.1 Broker, [Online]. Available: http : / /
an orchestration engine for programmable logic con- mosquitto.org/.

Authorized licensed use limited to: Universidad Del Norte Biblioteca. Downloaded on October 19,2024 at 09:03:35 UTC from IEEE Xplore. Restrictions apply.