Formal Behavioural Models to Facilitate Distributed Development and

Commissioning in Industrial Automation

James Harland, Jan Olaf Blech, Ian Peake and Luke Trodd

RMIT University, Melbourne, Australia

Keywords:

Software Engineering, Spatial Modeling, Cyber-physical Systems.

Abstract:

We aim to facilitate semi-automated collaborative distributed development, commissioning, operation and

maintenance using formal behavioural models. We are interested in a whole-of-system context, where proper-

ties of the physical systems increasingly depend explicitly on software conﬁguration, thus requiring validation.

Our models are cyber-physical, comprising not only the control software itself but also mechatronic elements

under control involving sensing/actuators, such as pneumatics, hydraulics, and motor drives. We discuss vari-

ous issues relevant to the problems of collaboration, and we provide requirements for collaboration in a speciﬁc

experimental context involving elements of a small-scale food packaging plant.

1 INTRODUCTION

Cyber-physical systems involve both physical aspects

such as sensors, actuators, pneumatics, hydraulics and

motor drives as well as various kinds of software

for controlling them. Such systems often have sev-

eral components which contain sensors and actuators,

which allows the components to operate without any

direct control based purely on their sensor inputs.

We are interested in modelling such systems us-

ing behavioural models in order to analyse and pre-

dict overall properties of the system. The increas-

ing dependence of such systems on software control

makes it increasingly important not only to validate

such software but also to explore possible conﬁgura-

tions of the system. The variety and sophistication

of the technologies used means that the development

and commissioning of such systems usually requires

a team of varied skills, such as electrical engineering,

mechatronics, hydraulics and software development.

An appropriate formal model of the system will thus

provide both a framework for co-operative work as

well as a method of dividing work amongst the team.

Dividing tasks such as the development of a com-

ponent into subtasks and assigning them to different

teams as well as the identiﬁcation of communication

dependencies between the teams and its individual

members (Figure 1) can beneﬁt from automatic so-

lutions. Here, we are targeting formal methods based

solutions.

Our particular context is a small-scale demon-















Figure 1: Collaboration overview.

strator food plant. This has a number of compo-

nents which are connected by programmable logic

controllers (PLCs) and other devices (see Figure 2).

We are particularly interested in the handling of bot-

tle caps in preparation for placing caps onto bottles.

Blue colour-coded elements and clear tubes are for

pneumatic (air pressure) actuation. Black cables carry

sensor/actuator signals. A piston feeds pushes caps

from a column of caps (right of centre in Figure 2)

to a pickup plate. A pneumatic lever rotates to the

plate to pick up the cap and then rotates to a raised

conveyor (centre of Figure 2). A mechanical gripper

(left of centre in Figure 2) picks caps off the conveyor,

lifts them and places them onto bottles. The opera-

tion of the level can be better seen in Figure 3; the

lever moves a single cap (pushed out from the col-

umn of caps by the piston) onto the end of the con-

veyor (at the right of Figure 3). Once the cap reaches

the end of the conveyor, the gripper moves to a posi-

tion above the cap, and then descends. Once the cap

Harland, J., Blech, J., Peake, I. and Trodd, L.

Formal Behavioural Models to Facilitate Distributed Development and Commissioning in Industrial Automation.

In Proceedings of the 11th International Conference on Evaluation of Novel Software Approaches to Software Engineering (ENASE 2016), pages 363-369

ISBN: 978-989-758-189-2

363

Figure 2: Experimental setup — mini food processing plant

with relevant parts highlighted.

Figure 3: Experimental setup — mini food processing plant

2 with cap movement highlighted.

Figure 4: Experimental setup — gripper with motion path

highlighted.

is in its grasp, the gripper reverses its path, moving

the cap upwards and then across (see the motion path

highlighted in Figure 4).

Components in such systems typically operate via

sensors. When the sensor is activated (for example,

by the piston detecting the presence of a bottle cap),

the component is activated. The recent development

of cheap miniature computers such as the Raspberry

Pi (Raspberry Pi) means that it is now possible to in-

troduce more intricate control mechanisms into envi-

ronments such as this, which provide greater oppor-

tunities for exploring possible conﬁgurations of the

bottling system, and particularly when it comes to co-

ordination of concurrent activities. For example, the

lever can only pick up the cap when one is present,

which could be detected by a sensor. However, if the

controller (i.e. the Raspberry Pi) knows that a cap has

just been put into position, there is no need to sense

whether one is present or not, and the lever can be

activated independently of its sensor. This allows for

greater variations of co-operation during the concur-

rent operation of the components by centralising some

aspects of control in the Raspberry Pi. Raspberry Pis

are now a well-known technology designed for exper-

imentation and innovative applications. They are also

cheap, based on open source software and are rela-

tively well-documented. This makes Raspberry Pis

an attractive platform for analysing the possibilities

for controlling the bottling system.

In this position paper we discuss the ways in

which we can apply the techniques of formal meth-

ods in order to analyse conﬁgurations of the bot-

tling system. As noted above, there are a variety of

skills needed to investigate end-to-end properties of

this system, such as throughput, safety, energy efﬁ-

ciency and robustness. In particular, the presence of

the Raspberry Pis means that it is possible to investi-

gate tradeoffs between co-ordination via sensors and

via explicit control. The naturally reactive nature of

co-ordination via sensors has a greater amount of ro-

bustness and redundancy, but allowing programmed

control will allow for potentially greater exploitation

of global properties of the system.

It should be noted that this context requires an ag-

ile approach to conﬁguration and deployment. This

is due to not only the multi-disciplinary nature of the

skills needed to deploy the system but also the dy-

namic nature of the environment in which it operates.

Over the life of the plant, not only may components

and other parts of the system change or be replaced,

but also the requirements for the system may evolve.

This means that we expect a cycle of continuous up-

dates to the system, which will involve regular recon-

ﬁguration and reﬁnement. Hence we are not using

formal methods for the articulation and satisfaction

of deployment constraints, but as a means of captur-

ing properties of the system in a way which will al-

low regular reconﬁguration and collaboration. This

will also allow us to explore “what if” scenarios, such

as potential reconﬁgurations, and speciﬁc ideas about

what constitutes optimality for the system (whether

it be safety properties, numbers of sensors required,

measures of concurrency, or an ability to recover from

mishaps).

This also means that the semantics will need to be

able to express contracts for each component. For ex-

ample, the piston that moves the bottle caps forward

COLAFORM 2016 - Special Session on Collaborative Aspects of Formal Methods

364

may vary the way in which its internal hydraulics

work, but as long as there is no change in the fre-

quency at which the caps can be moved or the way in

which it is triggered, the rest of the system need not

be concerned. However, if a change to the hydraulics

affects, say, the power consumption, or the timing at

which the caps can be moved, then there is a need to

collaborate in order to reconﬁgure the system appro-

priately. This means that the formal description of the

system becomes an important element of the collab-

oration, as it is the place where interactions between

the components are expressed and analysed. This will

also provide a means for standardising the terminol-

ogy used.

This means that our point of distinction from other

approaches is to use the food processing plant as a

concrete case study of how to organise collabora-

tion between a diverse group of people. In particu-

lar, supervision of the plant is often where the need

for collaboration arises. For example, a new man-

ager may need to have an overview of what the plant

does and how the various components work together.

This overview may result in some changes in the man-

agement of the plant, such as prioritising electronics

over hydraulics due to the availability of local exper-

tise. In general, there may be mismatches between

skills required for the plant and the local availability

of qualiﬁed personnel, or imperfections in some com-

ponents that require some subtle changes to the way

the plant operates. Suppliers may change over the

lifetime of the plant, or come from various different

parts of the world, which, together with local market

factors (taxes, exchange rates etc.) may vary the way

in which components are valued. Naturally recalling

and exchanging components is much less preferable

than adapting existing ones to changing conditions.

It is also worth noting that collaboration may

come in a number of forms. One is collabora-

tion across disciplines, but there is also a need to

collaborate over temporal differences (e.g. compo-

nents that change over time), distance (e.g. mining

operations controlled from hundreds of kilometres

away), or across phases as in the well-known V-model

(ISO26262). There may be many forms of collabora-

tion, and it is important to allow as wide a variety of

collaboration as possible.

A further pragmatic issue is that the semantics

must be sufﬁciently simple so that it can be readily

understood by a wide variety of professionals. This

means that temporal logics and other semantically

rich formalisms are not appropriate in our context.

Whilst such formalisms are well-known in software

engineering, it is highly likely that people outside the

formal methods community will ﬁnd them too difﬁ-

cult to use. This means that our semantics will be

based around ﬁnite state automata, and particular vari-

ants such as timed automata (Alur and Dill 1994).

This also has the advantage of being able to switch be-

tween levels of abstraction. For example, if we wish

to focus our attention on the gripper, rather than the

system of the piston, lever, conveyor and gripper, then

it is relatively straightforward to consider the gripper

as the conﬁguration of a number of components, such

as the gripper arm itself, the pin that moves vertically

up and down, and the mechanism that moves the grip-

per horizontally.

A key observation is that we are interested in vali-

dation of the current conﬁguration, no matter what the

current stage of development may be. This is in the

same spirit as the V-model, in that at any point in the

process, we are able to identify validation issues, and

potentially address them. This is another reason for

keeping the semantics relatively simple, as it is more

focused on the interaction between components than

on the particular properties of the components them-

selves.

While the number of components in our example

is small, and hence can be manually reconﬁgured as

need be, in general it will be a lot more difﬁcult to

revise and validate a particular conﬁguration of the

plant. For this reason we anticipate using satisﬁability

modulo theory (SMT) solvers and related technolo-

gies in order to analyse conﬁgurations of the plant.

This seems particularly appropriate given the poten-

tially global nature of the control mechanisms made

possible by the Raspberry Pis, and in particular the

way in which the overall properties of a conﬁguration

can be inferred from the properties of individual com-

ponents. The problem of determining an appropriate

architectural conﬁguration can then be transformed

into a problem of determining whether a speciﬁc for-

mula is satisﬁable or not, which can then be provided

as input to an SMT solver.

2 EXAMPLE SYSTEM

As shown in Figures 2 and 3, we focus on a partic-

ular part of the Festo installation. A column of bot-

tle caps (which can be seen in the left of Figure 3) is

supplied, and the bottom cap in this column is pushed

forward by the piston so that it is underneath the pneu-

matic lever. The lever then descends and collects the

cap, rotates through around 135

◦

before halting and

dropping the cap on the conveyor. The conveyor then

moves the cap around 30cm to the other end, where

the gripper then descends, collects the cap and places

it on a rotating platform (to the right of Figure 4),

Formal Behavioural Models to Facilitate Distributed Development and Commissioning in Industrial Automation

365







































Figure 5: Overview on our methodology.

from which the caps are placed onto bottles (by an-

other part of the plant). The cap’s journey from the

initial column to the rotating platform takes about 20

seconds.

One point to note is that in the conﬁguration in

the plant, the lever can only rest when it is at the po-

sition where it drops the cap onto the conveyor belt.

However, in order for the cap to move along the con-

veyor, the lever has to be moved from this position,

because otherwise the end of the lever remains inside

the cap. This means that an extra iteration of the lever

movement is required (so that the lever has to make

two movements in order to move one cap) to allow

the tip of the lever to be out of the way when the cap

is moved by the conveyor. This is an artefact of the

cyber-physical nature of the system.

We construct a possible abstract speciﬁcation of

the physical process. In this example our method is

based on composition and synchronisation of cyclic

state machines of local processes corresponding to

underlying cyber-physical components including ma-

chinery and their associated sensors and/or actuators,

following the approach in (Schmidt et al 2003). State

machines capture that local physical processes are in

contact with neighboring processes via synchronisa-

tion such that output actions of one process corre-

spond to input actions of a contacting process. For

several components, actions imply synonyms for la-

bels on corresponding input or output transitions link-

ing connecting states: The piston is initially home,

then push(ing), at limit of extension (output: limit),

retracting (input: retract) or in the home position.

The lever and gripper are either carrying, waiting to

drop, dropping, or (return)ing. The conveyor is ei-

ther moving or stopped. Sensors on the conveyor in-

dicate via transitions when a cap at the entry (placed

by lever) and exit (lifted by gripper) positions arrived

or departed, hence for example the overall cyclic se-

quence: entry.arr, entry.dep, exit.arr, exit.dep. The

(rotating) platform is either moving or stopped.

The overall behaviour of the system is a synchro-

nised composition of all these. The description of the

system can be derived incrementally by pointwise-

synchronising pairs of component processes. In com-

position, for example, the conveyor states are guarded

by actions move and stop which are paired with ac-

tions in a synchronisation process which interacts

with the lever and the gripper.

3 COLLABORATIVE SCENARIOS

Figure 5 provides an overview of our methodology.

The Festo equipment is designed to be ﬂexible, and

hence generally requires tailoring to speciﬁc needs.

The introduction of the Raspberry Pis means that

there are greater possibilities for co-operation than

when the components are operated by sensors alone.

This means that we may be able to alter some of the

end-to-end properties of the conﬁguration by utilising

more explicit control mechanisms. For example, it

takes around 20 seconds for the cap to travel from the

initial column to the place where it is put down by the

gripper. We can potentially increase the throughput

of the system by utilising the conveyor as a buffer for

caps. From the images, it seems that around 6 caps

would ﬁt on the conveyor at one time (note that there

is an arm on the conveyor which means the caps can-

not proceed past a certain point without an explicit

command from a controller). The time taken for the

piston to move the cap is about 1 second, and the time

for one cycle of the lever and the gripper is about 3

seconds and 8 seconds respectively. It takes the con-

veyor around 3 seconds to move the cap from one end

to the other. This means that it would be possible to

have up to 3 caps on the conveyor at any one time,

with the gripper (being the slower of the two moving

arms) working continuously while the lever can work

at a slower rate, as it only needs to ensure that there

are 3 caps on the conveyor at any time.

We may also wish to experiment with the fre-

quency of the lever action, as it may be better (for

hydraulic, electrical or maintenance reasons) to move

the lever for three continuous cycles (to ﬁll an other-

wise empty conveyor) and then remain idle for three

cycles (allowing the conveyor’s store of caps to emp-

tied before moving again), rather than to initially ﬁll

the conveyor (for three cycles) and then work one cy-

cle at a time to maintain three caps on the conveyor

(i.e. synchronise the movement of the lever with the

gripper). As mentioned above, we also need to take

into account the property that caps cannot move on

the conveyor when the lever is at rest at 135

◦

, mean-

ing that it may be necessary to move the lever even if

there is no cap to collect.

Alternatively, we may wish to maximise the pos-

sibility of recover from an error, such as the lever

COLAFORM 2016 - Special Session on Collaborative Aspects of Formal Methods

366

placing the caps on the conveyor in slightly different

ways each time, which may mean it is safer to limit

the number of caps on the conveyor at any time to 2.

We may also want to minimise the number of active

sensors (or other parts) in the system, or to focus con-

trol on the most critical aspect of the system (such as

the number of caps on the conveyor at any one time)

and allow the other components to be operated purely

by sensors.

We may also wish to reconﬁgure the lever itself, so

that it can come to rest at a vertical position after drop-

ping the cap. This will avoid the problem of having

to move the lever so that the conveyor can move the

cap, but requires more sophisticated hydraulic man-

agement, and will presumably mean that the lever

moves at a signiﬁcantly slower pace. The change of

the properties of the lever will be reﬂected in the se-

mantics, which can then be used as a tool for com-

munication and hence collaboration between the hy-

draulics expert, the conveyor expert and the software

engineer in charge of the Raspberry Pis.

The semantics could also be used as a speciﬁca-

tion of what behaviour is desired, which can then be

used to investigate the potential behaviour of the sys-

tem. In the above example with the lever, the soft-

ware engineer may be interested to know if the lever

can be made to rest in a vertical position with a cy-

cle time (including picking up the cap from the piston

and placing it on the conveyor) within 9 seconds; the

hydraulics expert can then analyse whether this is pos-

sible or not, and what other consequences there may

be. This is how we envisage the semantics assisting

with collaboration, in that it provides a means of stat-

ing precisely what the (ideal or actual) behaviour of a

speciﬁc component may be, as well as how the vari-

ous components interact. This also means that the ex-

pression of a contract, i.e. the properties of one com-

ponent of interest to another, will also need to be a

central part of the semantics.

4 APPROACH

Our approach is to develop the semantics for each

component (in our running example, the piston, lever,

conveyor, and gripper) and then to compose the se-

mantics of the overall system from those for each

component. This will involve both the internal states

for each component (with the associated transition

conditions between states) and the interfaces between

components. Our running example is fairly small,

and in general it seems possible to handle the seman-

tics for this system by hand. However, for a system

with dozens of components, it is likely that some au-

tomated tools will be required to manage the scale in-

volved. For this reason we anticipate using tools such

as SMT solvers to manage the overall conﬁguration of

the system. In particular, we envisage a speciﬁcation

of a desired conﬁguration of the system being mapped

to a speciﬁc physical conﬁguration, with the mapping

between the two being found by the SMT solver.

It should be noted that we do not necessarily ex-

pect this process to be fully automatic; in fact, it is

likely that this will only be feasible with some human

input at critical points, especially for larger systems.

In the extreme, there may even be a completely hu-

man speciﬁcation that is checked by the solver, but in

many cases a human expert may provide some partial

input, such as the conﬁguration for a particularly intri-

cate or critical component, with the SMT solver being

used to ﬁll in the rest of the conﬁguration task. It may

also be that the solver will provide some choices, from

which a team of humans may choose the most appro-

priate one. In this way the use of formal models with

appropriate tool support can provide opportunities for

collaboration and distributed development.

The use of a solver in this way means that it is pos-

sible for collaboration to take place across distances,

with the semantics for each component being input

to a solver in the cloud. It also means that it is not

required that any one person in the team know the

global properties of the system, but only the proper-

ties of the components for which they are responsible.

5 RELATED WORK

Our demonstrator is based on Festo equipment, cus-

tomized using Raspberry Pis as controllers running

on the 4DIAC (Strasser et al. 2008) runtime environ-

ment. A similar demonstrator setup has been used

in (Wenger et al. 2015) where formal models (behav-

ioral types) serve as a speciﬁcation basis for monitor-

ing of an IEC 61499 based system. Moreover, similar

speciﬁcations have been extended for cyber-physical

systems (Blech and Herrmann 2015). Ultimately, our

work is intended to complement a framework that

supports other aspects of collaboration such as spatio-

temporal models and decision support based on them.

Such a framework has been introduced in (Blech et

al. 2015). (Blech et al. 2014) describes usages for

speciﬁcations for similar demonstrators.

The V-model (as e.g., incorporated in the ISO

26262 standard (ISO26262) in the automotive do-

main) uses a divide and conquer approach for iden-

tifying and developing components. This provides

some suggestion on possible teams, tasks and de-

pendencies in the development of cyber-physical sys-

Formal Behavioural Models to Facilitate Distributed Development and Commissioning in Industrial Automation

367

tems.

Interface automata (Alfaro and Henzinger 2001)

are one form of component-based speciﬁcations that

inspired the modeling formalisms proposed in this

paper. Component descriptions in (Alfaro and Hen-

zinger 2001) are based on timed automata. The

focus of interface automata is on interactions be-

tween components and as in our work can serve as

a basis for facilitating collaboration between differ-

ent development teams. Behavioral types from the

Ptolemy framework (Lee and Xiong 2004) are a mod-

eling mechanism for components and are primarily

aimed towards the software part of real-time systems

such as execution time of code. External State Ma-

chines (Kraemer and Herrmann 2009) are based on

UML state machines describing the interface behav-

ior of software components or building blocks for the

control of cyber-physical systems. Tangible user in-

terfaces (Shaer and Hornecker 2010) provide another

way of exemplifying underlying principles of cyber-

physical speciﬁcations. Cyber-physical characteris-

tics can be described using a behavioral speciﬁcation,

e.g., using a domain speciﬁc language.

Ways to use SMT solvers for generating PLC

functionality have been described in (Cheng et al.

2014) (Cheng et al. 2012). In contrast to this, we

are investigating solutions to facilitate the collabora-

tion between different stakeholders. We propose the

use of solvers to facilitate this. Formula is a frame-

work for specifying systems and using SMT-based

constraint solving to ensure properties

. The frame-

work is speciﬁcally tailored towards the use of the z3

SMT solver (Moura and Bjøner). Modelica is another

logic-based speciﬁcation framework

which has been

applied in a variety of contexts.

Several industry-academia collaborations have de-

veloped frameworks for component interfaces and

aim at facilitating collaboration between different

stakeholders for different system components. The

combest project (Bensalem et al.)

, Recomp

, d-

mils

, and Aramis

all follow these goals providing

some sort of component description language. Ap-

plication domains include industrial automation, au-

tomotive engineering, avionics and trains.

Formula (Jackson et al. 2009) provides a generic

modeling language for specifying properties of com-

http://research.microsoft.com/en-us/um/people/

ejackson/

https://www.modelica.org/documents/

ModelicaSpec33Revision1.pdf http://book.xogeny.com

http://combest.imag.fr/home

https://artemis-ia.eu/project/21-recomp.html

http://www.d-mils.org/page/publications-1

http://www.projekt-aramis.de/projekt/ziele

ponents and means to reason about them. Reasoning

is based on SMT solving. The framework targets non-

functional requirements of software systems.

Modelica (Fritzson 2010) is a language aimed to-

wards the modeling of cyber-physical systems. Spec-

iﬁcation of industrial automation systems using a the-

orem prover has been investigated, e.g., in (Blech

and Ould Biha 2011). The speciﬁcation is based

on the IEC 61131–3 standard for programming pro-

grammable logic controllers. In our work, we are

not addressing a particular programming standard, but

are experimenting with IEC 61131–3, IEC 61499 and

Python code running on our Raspberry Pi based con-

trollers.

6 CONCLUSION

This position paper is an outline of our plans for

developing an appropriate semantics for reasoning

about the properties of the Festo system. We will

further develop the semantics for the Festo system

described above, and to use it to investigate various

properties. This will provide us with a speciﬁc sce-

nario for the discussion of reconﬁguration problems

and related issues. We envisage using tools such as

the SMT solver z3 for this purpose. We also plan to

empirically derive requirements for collaborative sce-

narios based on an observational study of a project

involving the Festo system.

REFERENCES

L. de Alfaro, T.A. Henzinger (2001). Interface Automata. In

Symposium on Foundations of Software Engineering,

ACM.

R. Alur, D. Dill (1994, April). A theory of timed automata.

Theoretical Computer Science 126(2):183-235.

S. Bensalem, M. Bozga, T.-H. Nguyen, J. Sifakis (2010,

June). Compositional veriﬁcation for component-

based systems and application. In Software,

IET, vol.4, no.3, pp.181-193. doi: 10.1049/iet-

sen.2009.0011

J. O. Blech, M. Spichkova, I. Peake, H. Schmidt (2014).

Cyber-Virtual Systems: Simulation, Validation & Vi-

sualization. Evaluation of Novel Approaches to Soft-

ware Engineering. SciTePress ISBN 978-989-758-

030-7.

J. O. Blech, P. Herrmann (2015). Behavioral Types for

Space-aware Systems. Model-based Architecting of

Cyber-Physical and Embedded Systems. CEUR pro-

ceedings, vol. 1508.

J. O. Blech, S. Ould Biha (2011). Veriﬁcation of PLC Prop-

erties Based on Formal Semantics in Coq. 9th In-

ternational Conference on Software Engineering and

COLAFORM 2016 - Special Session on Collaborative Aspects of Formal Methods

368

Formal Methods (SEFM), Montevideo, Uruguay, vol.

7041 of LNCS, Springer.

J. O. Blech, I. Peake, H. Schmidt, M. Kande, A. Rahman,

S. Ramaswamy, S.D. Sudarsan, V. Narayanan (2015).

Efﬁcient Incident Handling in Industrial Automation

through Collaborative Engineering. Emerging Tech-

nologies and Factory Automation (ETFA), IEEE.

C.H. Cheng, C.H. Huang, H. Ruess, S. Stattelmann (2014,

January). G4LTL-ST: Automatic generation of PLC

programs. InComputer Aided Veriﬁcation (pp. 541-

549). Springer International Publishing. ISO 690

C.H. Cheng, M. Geisinger, H. Ruess, C. Buckl, A. Knoll

(2012, January). MGSyn: Automatic synthesis for in-

dustrial automation. In Computer Aided Veriﬁcation

(pp. 658-664). Springer Berlin Heidelberg.

P. Fritzson (2010). Principles of object-oriented modeling

and simulation with Modelica 2.1. ohn Wiley & Sons.

ISO 690

ISO 26262 standard (2011), ISO, Geneva.

E.K. Jackson, D. Seifert, M. Dahlweid, T. Santen, N.

Bjørner, W. Schulte (2009, January). Specifying and

composing non-functional requirements in model-

based development. In Software Composition (pp. 72-

89). Springer Berlin Heidelberg.

F. A. Kraemer and P. Herrmann (2009). Automated En-

capsulation of UML Activities for Incremental Devel-

opment and Veriﬁcation. In Model Driven Engineer-

ing Languages and Systems (MoDELS), vol. 5795 of

LNCS, pages 571–585. Springer-Verlag.

E. A. Lee, Y. Xiong (2004). A Behavioral Type System

and its Application in Ptolemy II. Formal Aspects of

Computing, 16(3):210–237.

L. Moura, N. Bjørner (2008). Z3: An Efﬁcient SMT Solver.

In Proceedings of the 14 International Conference on

Tools and Algorithms for the Construction and Analy-

sis of Systems (pp. 337-340).

Raspberry Pi. https://www.raspberrypi.org. Accessed De-

cember 2015.

H. Schmidt et al. (2003). Modelling predictable component-

based distributed control architectures. In the Ninth

IEEE International Workshop on Object-Oriented

Real-Time Dependable Systems, 2003. WORDS 2003

Fall.

O. Shaer, E. Hornecker (2010). Tangible user interfaces:

past, present, and future directions. Foundations and

Trends in Human-Computer Interaction 3(!-2):1-137.

T. Strasser, M. Rooker, G. Ebenhofer, A. Zoitl, C.

under, A. Valentini, A. Martel (2008, July). Frame-

work for distributed industrial automation and con-

trol (4DIAC). In Industrial Informatics, 2008. INDIN

2008. 6th IEEE International Conference on (pp. 283-

288). IEEE.

M. Wenger, J. O. Blech, A. Zoitl. Behavioral Type-based

Monitoring for IEC 61499 (2015). Emerging Tech-

nologies and Factory Automation (ETFA), IEEE.

Formal Behavioural Models to Facilitate Distributed Development and Commissioning in Industrial Automation

369