Computers in Industry 72 (2015) 92–102

A cyber–physical system-based approach for industrialautomation systems

Kleanthis Thramboulidis *

Electrical and Computer Engineering, University of Patras, Greece

A R T I C L E I N F O

Article history:

Received 15 November 2014

Received in revised form 23 April 2015

Accepted 28 April 2015

Available online 16 May 2015

Keywords:

Industrial automation systems

Cyber–physical systems

System-based approach

Mechatronics

UML/SysML

IEC 61131

Java

IoT

A B S T R A C T

Industrial automation systems (IASs) are commonly developed using the languages defined by the IEC

61131 standard and are executed on programmable logic controllers (PLCs). Their software part is

commonly considered only after the development and integration of mechanics and electronics.

However, this approach narrows the solution space for software; thus, it is considered inadequate to

address the complexity of today’s systems. In this paper, we adopt a system-based approach for the

development of IASs. Based on this, the UML model of the software part of the system is extracted from

the SysML system model and it is then refined to get the implementation code. Two implementation

alternatives are considered to exploit both PLCs and the recent deluge of embedded boards in the market.

For PLC targets, the new version of IEC 61131 that supports object-orientation is adopted, while Java is

used for embedded boards. The case study used to illustrate our approach was developed as a lab

exercise, which aims to introduce to students a number of technologies used to address challenges in the

domain of cyber–physical systems and highlights the role of the Internet of Things (IoT) as a glue for their

cyber interfaces.

� 2015 Elsevier B.V. All rights reserved.

Contents lists available at ScienceDirect

Computers in Industry

jo ur n al ho m epag e: ww w.els evier . c om / lo cat e/co mp in d

1. Introduction

Industrial automation systems (IASs) are composed of thephysical plant, which performs the physical processes, andnetworks of embedded computers, which perform the computa-tional processes required to monitor and control the physical ones.The cyber part of the system is constituted by computationalprocesses, which receive inputs from the physical processes,calculate the required outputs and apply them to the physicalplant. This is usually realized using time triggered control in theform of the well known scan cycle paradigm.

Computational processes are commonly implemented based onthe de-facto standard IEC 61131, which defines a set of languagesfor programming on programmable logic controllers (PLCs) [1].This standard has been around for at least 20 years and isattributed the introduction of basic concepts of object orientationthrough the construct of function block (FB) in the domain ofindustrial automation [2]. However, it is of question whether thistechnology is able to address the new requirements of today’s

* Tel.: +30 2610 996436.

E-mail address: thrambo@ece.upatras.gr

http://dx.doi.org/10.1016/j.compind.2015.04.006

0166-3615/� 2015 Elsevier B.V. All rights reserved.

industrial automation systems [3]. This is primarily due to theirincreasing complexity and the need for flexibility. In particular,these requirements include among others distribution, portability,configurability, interoperability and reconfiguration, which haveall been identified as the high-level demands/requirements forfuture automation systems [4].

In order to address the restrictions imposed by version 2.0 ofIEC 61131, as well as to address the new challenges in thedevelopment of today’s complex industrial automation systems,the IEC has defined the IEC 61499 standard [5]. This standard ‘‘hasemerged in response to the technological limitations encounteredin the currently dominating standard IEC 61131’’, as claimed in [6],where IEC 61131 is characterized as ‘‘severely inadequate to meetthe current industry demands for distributed, flexible automationsystems.’’ The IEC 61499 has been widely accepted by the academiccommunity; a big number of publications have been producedand a debate on pros and cons is active [7,8]. Interestingly, thestandard has not been accepted by the industry [3] owing to anumber of reasons including the absence of support by thecurrently dominating tools and environments in industry andthe absence of a variety of new mature tools and run-timeenvironments to support the new standard. The lack of ‘‘matureengineering tools, reliable embedded control hardware, proven

K. Thramboulidis / Computers in Industry 72 (2015) 92–102 93

design methodologies, and trained engineers’’ is considered in [9]as the main barrier that prevents practitioners from using theIEC 61499.

On the other side, the IEC 61131 has been recently upgradedwith a new version [10]. Version 3.0 provides support for theobject-oriented (OO) paradigm. CoDeSys 3 [11] has alreadyimplemented an object oriented version of the IEC 61131 andother industrial vendors such as Beckhoff [12] are moving towardthis direction. However, programming in an object oriented wayis not a trivial task for industrial automation developers, who arealready accustomed with version 2.0 of the IEC 61131. Thus,shifting to a complete object oriented approach will require longtime. This transition will also be pushed by new developers, whoenter the field, especially since object oriented programming andUML/SysML is already included in the curricula of both universitiesand technical schools, e.g., object oriented programming is nowmandatory in the curriculum for technicians in Germany [13].

Apart from training, specific frameworks may facilitate thistransition and are expected to bring the benefits of applying theobject oriented paradigm and Model Driven Engineering [14,15] inthe industrial automation domain. These challenges have alreadyattracted significant research interest and numerous papers havebeen published toward this direction [16–18] to name a few. It isby now widely accepted that the factory automation industry isslowly but steadily experiencing a paradigm shift [19]; there is anincreasing adoption of technologies and standards of businesssoftware systems in the control level of the industrial automationsystems [20]. Moreover, there is a shift from the traditional device-centric programming paradigm adopted by the IEC 61131 to theapplication-centric one that utilizes mature state-of-the-arttechnologies for general purpose computing. These technologiesare currently integrated into a coherent set for industrial automationsystems in paradigms such as the Industrial Internet of Things orIndustry 4.0 [21].

At the same time, there is a lot of criticism regarding thetraditional development process of industrial automation systems,e.g., [22–24]. According to this traditional approach the constituentparts of the systems, i.e., mechanics, electronics and software, aredeveloped independently and are only then integrated to composethe system. This is considered to be inadequate to address thealways increasing complexity of these systems.

In this paper, we adopt a synergistic integration of the variousdisciplines involved in Mechatronic systems at the componentlevel, thus aiming to address the new challenges in industrialautomation systems. The Mechatronic component (MTC), whichconsists of mechanics, electronics and software, is considered thekey construct for the composition of Mechatronic systems. Basedon this, a cyber–physical system-based approach is described inthis paper. Our approach exploits composability and composition-ality [25] on the Mechatronic or cyber–physical component-levelsand is used to define the system level functional and non-functional properties by applying synergistic integration at thecyber–physical component level. It adopts the object-orientedparadigm, and, exploits SysML for system level modeling and UMLfor modeling the software part of the system.

The main focus of this paper is on modeling the cyber part of thesystem with an emphasis on the software part. Two alternativeimplementations of the proposed design are discussed. One isbased on the IEC 61131 3.0 for PLCs; the other is based on a generalpurpose object-oriented programming language to allow the use ofthe various embedded boards mainly based on ARM processorsthat have appeared in the market recently. The entire design andthe prototype implementation are presented in the context ofan educational approach that is designed for both studentsand industrial practitioners. We emphasize on the use of higherlayers of abstractions and on the differences between the two

implementation alternatives so as to successfully: (a) realize theshift toward the object-oriented paradigm, and, (b) apply themodel driven development (MDD) paradigm. Moreover, we havebeen particularly careful to clarify the scan cycle model, which iswidely used in PLC programming, given that the users of embeddedboards are typically accustomed to the event triggered program-ming paradigm. The objective is for the framework to support (i)scheduling abstraction [26], which would enable the developer toneglect the scheduling of components, and, (ii) timing abstraction,which would allow the developer to neglect timing issues andfocus on causality instead.

In order to illustrate all the steps of our approach starting fromthe system level and moving down to the executable code weutilize the Liqueur Plant system, which was first used in [3]. Themodel of the cyber part, which is derived from the system levelmodel, is refined, following the proposed approach, for: (a) thecyber parts of cyber–physical components, and (b) the processcontrollers, which are modeled as cyber components. The layeredarchitectural style is adopted for structuring the cyber–physicalcomponent, while the REST network-based architectural style isadopted for the integration of system level components regardingtheir cyber interfaces. Alternatively, for the case in which a tightercoupling between system components is not prohibitive, SOAP[20] or even a traditional middleware technology such as CORBAmay be used. The software part of the prototype implementationwas implemented using Java and the scan cycle model, and, it wastested with a simulator of the physical plant. Java is considered atechnology that may speed up the adoption of advances in generalpurpose computing in the domain of industrial automationsystems [27].

The remainder of the paper is organized as follows. Section 2further discusses relevant work. In Section 3, the case study used isdescribed and the fundamental concept of the system-basedapproach is briefly presented. Section 4 describes the proposed inthis paper structure for the cyber part of the system. In Section 5,two implementation alternatives are discussed and finally thepaper concludes in Section 6.

2. Related work

Progress in general purpose computing has attracted the interestof both industry and academia from the domain of industrialautomation systems. Several approaches that exploit the newtechnologies have been proposed so far; object and serviceorientation, component based and model driven development areamong the ones that have been extensively promoted since theyhave been able to improve the development process in this domain.

Object-orientation (OO) has already attracted the interest of theresearch community and various approaches have been proposedon how to exploit OO in this domain, e.g., [28,29]. However, as isclaimed in [30], most of these do not take into account the OOaspects of the IEC 61131 in the direction of extending it to supportthe object oriented paradigm. This has resulted to inefficientproposals regarding the object-oriented extension of the IEC 61131model.

Service oriented architectures (SOA) have already attracted theinterest of researchers in the industrial automation domain, e.g.,[19,31–34] and vendors are already moving toward exploiting theInterent of Things (IoT), e.g., [35]. To support discovery andcomposition of capabilities of entities that constitute cyber physicalsystems and their just-in-time assembly, authors in [36] describe anapproach to enable the use of SOA methods for this domain.

UML and SysML are both utilized in industrial automationsystems, e.g., [16–18,25,38]. SysML was defined as an extension ofUML for system modeling and is replacing UML last years inmechatronic systems modeling, e.g., [24,37]. It may be used for

Fig. 1. The physical plant used as case study in this paper [3].

K. Thramboulidis / Computers in Industry 72 (2015) 92–10294

modeling systems not only in an object oriented way but also in aprocedural way. However, most of the approaches based on UMLand SysML do not increase the abstraction level in modeling so asto facilitate the development process in this domain. To ourunderstanding, an effective use of UML and SysML should supportthe construction of more abstract models than the ones supportedby the IEC 61131 constructs; this is the approach adopted in thispaper. Authors in [13] report their experience from an evaluationof a UML-based versus an IEC 61131-3-based software engineeringapproach for teaching PLC Programming. Even though twodifferent levels of abstraction in software specification arecompared, the finding are quite interesting and can be utilizedto facilitate the shift to the object oriented programming paradigmin the development of industrial automation systems.

Component based development has been proposed by variousresearch groups to increase flexibility and effectiveness of thedevelopment process [39–41]. Composability and composition-ality are defined as main properties in component baseddevelopment [25]. Composability ensures that, when componentsare properly integrated to compose a system, their properties donot change. Compositionality ensures that properties of the systemcan be computed from components’ properties. Both properties areprerequisites for an effective component based developmentprocess.

Model driven development has been proposed as a paradigm toincrease the effectiveness of the development process of industrialautomation systems, e.g., [39,41,42]. Authors in [43] define threedesign layers and allocate cyber–physical Objects at the physicallayer. The proposed in this paper approach in high-level modelingof cyber physical systems differs from [22] in that: (a) it considersthe cyber–physical component as an integration of entities fromthe three layers, i.e., physical, electronics and software, and (b) thecyber–physical components are allocated at the Mechatronic orcyber–physical layer that is on top of these three layers of the MIMarchitecture. In this way, the construct of cyber–physical compo-nent encapsulates the heterogeneous interactions among thedifferent discipline constituent parts facilitating the integration ofcomponents at the system level.

Basile et al. describe in [3] an approach for modeling the cyberpart of industrial automation systems. They propose an extensionto the IEC 61131 model to support, according to authors, an event-based execution order in a similar way with the IEC 61499 stan-dard. Authors define the structure of the cyber part consisting oftwo types of function blocks. Device function blocks (DFBs) areused to implement the basic functionality that requires access to I/O field signals. Operation function blocks (OFBs) are used toimplement operations that use the functionalities provided byDFBs to perform specific working cycles. To facilitate the develop-ment of distributed automation systems avoiding the disadvantagesof the IEC 61499 standard, authors also adopt supervisory controlto solve the problem of programming the concurrent function blockbehaviors so as to satisfy desired sequencing and logical constraints.For the modeling of the controller they use petri nets. Our approachis based on the widely used, by developers familiar with the objectoriented paradigm, notations of UML statechart and activitydiagram. Furthermore, it provides inherent support for distributionby decomposing the cyber physical system at the system layer interms of cyber–physical and cyber components and adopting the IoTas the glue for the cyber interfaces. It also provides inherent supportfor the exploitation of the service oriented paradigm since it is basedon clearly defined cyber physical components that offer theirservices through IoT at the system layer. Moreover, it addressesseveral shortcomings of the above approach and may be consideredcomplimentary to it.

Synergistic integration of the three discipline flows ofMechatronic systems, i.e., material transfer, energy conversion

and information processing, is proposed by many researchers as atool to address the always increasing complexity in the domain.The traditional development process is criticized, e.g., [22–24], asinadequate to address the always increasing complexity of thesesystems. Authors in [44] claim that the dynamic coupling betweenvarious components of a mechatronic system requires anintegrated approach instead of considering the different domainsseparately and sequentially. System integration is considered asthe elephant in the chine store of large-scale CPSs [43]. The authorin [14] claims that ‘‘the lack of an integrated view often forcesdevelopers to implement suboptimal solutions’’ and that thesesolutions unnecessarily duplicate code, violate key architecturalprinciples, and complicate system evolution and quality assurance,as far as it regards the development of software. This claimbecomes stronger when applied to the system developmentprocess as is the case with the proposed in this paper approach.

3. A cyber–physical system-based approach for systemdevelopment

3.1. The liqueur plant case study

The case study used in this paper is based on the one used in[3]. It is further assumed that the plant is used to produce twotypes of Liqueur, hence it is called Liqueur Plant. Fig. 1 presents themechanical part of the plant, i.e., the physical part of the targetsystem that performs the physical processes. The plant iscomposed of four silos connected by a pipe. Each silo i has aninput valve INi and an output valve OUTi through which is cyclicallyfilled and emptied with liquid. It also has a sensor Ei for the lowerlevel and a sensor Fi for the upper level. Silos 2 and 4 have aresistance Ri to heat the liquid and a sensor Ti to monitor thetemperature. Silos 3 and 4 have a mixer Mi to mix their content.

Simplified descriptions of the two processes, which areexecuted in the plant, are assumed. Silos S1 and S4 are used forthe production of liqueur of type A. Raw liquid undergoes a basicprocess in S1 and then it is poured into S4 where it is furtherprocessed, i.e., it is heated and then mixed. Silos S2 and S3 are usedfor the production of liqueur of type B. Raw liquid is heated in S2until a given temperature is reached and then it is transferred to S3where it is mixed for a given time. The two liqueur generationprocesses are independent and can be executed in parallelassuming that they use the pipe in an exclusive way. Moreover,

K. Thramboulidis / Computers in Industry 72 (2015) 92–102 95

mixing the liquid in silos S3 and S4 at the same time is notpermitted due to a constraint in power consumption.

3.2. The system level modeling process

The development process that has been adopted is based onrefinement of models of decreasing level of abstraction as capturedon the MTS-V model [37]. The SysML requirement diagram andessential use cases are used for requirements modeling. Thedeveloper captures the required at the system level functionality interms of system responsibilities, as well as required quality ofservice (QoS) characteristics. The requirements model is next usedto construct the system architecture, which defines the system as acomposition of components and connectors, as shown in Fig. 2,where the proposed system level architecture for CPSs ispresented. A CyberPhysical-SystemComponent may be CyberPhysi-

calComponent, CyberComponent or PhysicalComponent, i.e., thekinds of components that constitute a CPS.

The system architect has to split the system level functionalitythat includes physical processing into chunks of subsystem orcomponent level functionalities. Chunks of system level function-ality that include physical processing should be allocated to cyber–physical components, captured as CyberPhysicalComponent inFig. 2. Chunks of system level functionality, that would probablybe provided by already existing cyber–physical components, areidentified. For example, mixing and heating functionalities, whichare required to fulfill the corresponding requirements of the rawliquid to generate Liqueur, would probably be provided by aheating and mixing Silo cyber–physical component. Based on this,the architecture of the system is defined as a composition ofexisting or well defined cyber–physical components and theconnectors required to interconnect them. A CPS usually interfacesto humans and may be considered as composed of subsystems, asshown in Fig. 2.

Hopefully, vendors of cyber–physical components would havealready developed components that provide these functionalities.They would have published in the semantic web, in a machinereadable way, the information that is required for using thesecomponents. Developers may use their browsers to find the propercomponents [31]. They have to download the virtual cyber–physical components, i.e., the ones that instead of the real worldmechanical part contain their simulator. Using the properdevelopment environment they integrate the virtual componentsand construct the virtual plant. This can be used for model analysis

Fig. 2. Key constructs for the system

and verification. Afterwards, the real cyber–physical componentscan be ordered and integrated to construct the target system, i.e.,the real plant.

Based on the above process, the Liqueur Plant is defined at thefirst abstraction level of the architecture model as a composition ofthe following cyber–physical components: (a) a simple silo (Silo),(b) a heating silo (HSilo), (c) a mixing silo (MSilo), (d) a mixing andheating silo (MHSilo) and (e) a pipe (Pipe). The refined systemarchitecture model, which is partially shown in Fig. 3, captures alsocyber components, which are required to capture the coordinationlogic of the constituent cyber–physical components so as to fulfillthe system level requirements. These cyber components maycapture the coordination logic in a static or in a dynamic way. Inthe latter case, the functionalities offered as services at the cyber–physical component level can be orchestrated to define therequired system level functionality. For example, the specificcomponent collaboration or orchestration of services to generateliqueur of type A represents system specific logic, and is capturedby the cyber component GenLiqueurA, which utilizes servicesoffered by silo 1 and silo 4 as shown in Fig. 3.

The Pipe has been represented as a cyber–physical componentthat is defined as a specialization of the cyber componentCommonResource, which captures the logic of acquiring andreleasing a common resource since it was decided to implementthis logic by software. Common structure and behavior of thevarious processes has been captured in the LiqueurProcess cybercomponent (see CyberComponent in Fig. 2) that will also beinherited by the GenLiqueurB cyber component (not shown inFig. 3), which captures the coordination logic of generating liqueurof type B. The cyber component PlantController captures coordina-tion logic of the various plant processes.

3.3. The proposed architecture for the cyber–physical component

Fig. 4 presents the proposed architecture for the cyber–physicalcomponent using MHSilo as example. The cyber–physical compo-nent is composed of the physical part, i.e., itsPhUnit and the cyberpart, i.e., itsCyberPart. The cyber part of the cyber–physicalcomponent is further decomposed into: (a) the software part(itsS-part), which represents the software required to transformthe physical unit into a smart unit, and (b) the electronic part (itsE-

part), which represents the processing node required to executethe software part. As described in the next section, the softwarepart is further decomposed into the software representative of

level architecture of the CPS.

Fig. 3. Part of the architecture of the LiqueurPlant system.

K. Thramboulidis / Computers in Industry 72 (2015) 92–10296

the physical unit into the software domain (itsSR), and thecontroller (itsController).

SysML ports [45] are used to represent the interaction points ofthe cyber–physical component with its environment. The type ofthe port specifies features available to and requested from theexternal entities via connectors to the port. For example, theitsProcessPort of MHSilo is of type ProcessPort, which specifiesthe features of its internal part itsController that are visible throughexternal connectors to the environment of the MHSilo. It should be

Fig. 4. Architecture of cyber–physical component. Ports define the interaction

points of the cyber–physical component with its environment.

noted that the processPort is of type proxy port since it acts as aproxy of the itsProcessPort of itsControler. On the other side theitsProcessPort on the border of the itsControler part is a full port sinceit defines with its own features the interaction point in itsboundary. The implementation of the port design space constructis described in the next section. Fig. 4 does not capture theinteractions between the constituent parts of the cyber–physicalcomponent.

Traditional communication technologies in industrial automa-tion can be utilized for the integration of cyber and cyber–physicalcomponents. However, in order to bring into the industrialautomation domain the benefits of IoT, the Intranet of Things isadopted for the integration of cyber and cyber–physical compo-nents.

4. Design of the cyber part

The described in this paper design approach for the cyber part ofthe system can also be applied in the traditional developmentprocess, where the software is considered as a whole for thesystem. In this case, the software part is either developedsynchronously with the development of the mechanics andelectronics or it may be developed when these parts have alreadybeen developed and integrated. In this section, the application ofthe proposed design for the multidiscipline-component approachadopted in this paper as well as the application of the traditionaldevelopment process are described.

4.1. The system as a composition of cyber–physical components

In the case that the system is considered as a composition ofcyber–physical components the first design of the cyber part of thesystem results from the SysML-view model. This constitutesthe cyber-view of the system and is generated by projecting thesystem model, which is expressed in SysML, to the cyber domain.The cyber-view can be considered as the software view (S-view) ofthe system, since: (a) no chunks of functionality are assigned toelectronic parts; the whole control functionality is assigned tosoftware and, (b) only system level functionality is captured in thesystem model at this stage of modeling. The trend today is to assignall the functionality of the controller to the software part and use

K. Thramboulidis / Computers in Industry 72 (2015) 92–102 97

general purpose embedded boards or PLCs just for the execution ofthe software part. As a result of this approach the electronic part ofthe cyber–physical system is not captured at these early designdocuments.

A cyber component is generated in the cyber-view, for everycyber–physical component of the system level model. This cybercomponent is assigned the behavior of controlling the physicalcomponent to perform the services that have been defined at thecomponent level. Thus the MHSilo cyber component has beenassigned the behavior of controlling the MHSilo physical compo-nent to perform the operations fill(), empty(), heatToTemp() andmix(), which have been assigned to the corresponding MHSilo

cyber–physical component. Moreover, every cyber component atthe SysML view results to a component at the cyber view. TheGenLiqueurA component is an example of such a component.

The so created architecture is further refined so as to beimplementable in an effective way. Modularity and reuse areprimary concerns in defining the proposed approach in furtherrefining the software part of the automation system. Specific UMLdesign constructs if properly used will provide a solid frameworkfor semi-automating the refinement process but also provide the

Fig. 5. Part of the architecture of the cyber part of th

information required for automating the generation process ofthe implementation code. The software component of every cyber–physical component of the system level is further decomposedinto: (a) the software representative (SR) and (b) the controller.

The SR is the representative of the corresponding physical partin the software domain. It acts as the proxy of the real world objectin the software domain and encapsulates all the interface detailswith the real world object. It should be noted that the SR does notadd any further functionality to the one provided by the real worldobject. It captures not only properties but also information of thereal world object that may be of interest to the software part of thesystem, such as model type, manufacturer, serial number,dimensions, etc. For example, the itsSR of type SiloSR in Fig. 4 isthe representative of the physical Silo in the software domain.

The controller captures the logic required to convert the lowlevel operations performed by the physical part to moresophisticated operations offered at the cyber–physical componentlevel. The itsController in Fig. 4 is an example of such a component.The MHSiloController may be used to implement operations such asfill(), empty(), mix() and heatToTemp(). In other words thecontroller transforms the physical object to a smart object.

e Liqueur Plant system using predefined classes.

K. Thramboulidis / Computers in Industry 72 (2015) 92–10298

Different controllers may convert the same physical object to adifferent smart object with the controller to play a key role in thisphysical object transformation process.

In Fig. 5, a part of the cyber-view of the system is given. This partcaptures the structure of the software that is used to realizethe process of generating liqueur of type A. As shown in Fig. 5, thecyber components are represented only by their softwareconstituents. However, in case that the developer decides toassign chunks of system level functionality to electronic compo-nents then these components should appear in the cyber-view ofthe system at this level of specification.

There are two alternatives to capture the basic structure of theproposed framework. One is through predefined generic classesthat capture this knowledge and allow the developer tore-use itthrough the mechanism of generalization–specialization. In Fig. 5,which is based on this approach, classes Process and Controller aswell as interfaces ProcessIf and ControllerIf represent predefineddesign constructs used to capture the basic structure adoptedby the framework. These classes are used by the developer todefine the classes of her system. Thus, GenLiqueurA is defined toinherit the Process class and the SipleSiloIf is defined to inherit theinterface ControllerIf. The use of interfaces allows an independentof silos’ implementations definition of the GenLiqueurA class.Based on this, the GenLiqueurA class may be used with any cyber–physical silo that implements the specific interfaces. On the upperlevel, the use of ProcessIf imposes a low coupling between theprocess and the PlantController cyber component.

Based on the second alternative for reusing the framework’sknowledge, a profile is used to define specific stereotypes such as‘‘controller’’, ‘‘controllerIf’’, ‘‘process’’ and ‘‘processIf’’. Fig. 6 presentspart of the architecture of the cyber part of the Liqueur Plantsystem exploiting the appropriate profile. It is evident that theprofile mechanism simplifies the design specification and makesthe design process more friendly to the developer.

4.2. The system as a composition of cyber and physical parts

In the case of the traditional development process ofMechatronic systems the software is considered after the

Fig. 6. Architecture (part) of the cyber part of the

development of the hardware parts. In this case, the structure ofthe already developed part of the system is used as a basis for thedefinition of the structure of the software. In the high level ofabstraction of the software architecture there is a softwarecomponent for every physical unit and also for every plantprocess. It is evident that the constraints in defining the softwarelevel in this case are more, compared to the 3+1 SysML-view modelapproach since the implemented software has now to be compliantwith the already implemented hardware which defines theinfrastructure on which the system services have to be imple-mented. This approach can be characterized as a middle-outapproach since the implemented software has to meet require-ments imposed not only from the system layer specification butalso from already defined lower layer services that the softwarehas to utilize in order to meet system requirements. On the otherside, in the top–down approach, the one applied when the systemis considered as a composition of cyber–physical components, thesoftware is concurrently and synergistically developed withelectronics and mechanics to meet the requirements of the systemlevel. This approach does not impose constraints on the softwaresolution space as is the case with the middle-out approach.

5. Implementation alternatives

Industrial automation software is typically implemented basedon the scan cycle model. According to this model, plant inputs areread, controller code is executed based on these inputs and thegenerated outputs are written to the plant to affect its operation.This is known as READ–EXECUTE–WRITE cycle and is animplementation of the time triggered control. The cycle timehas to be properly defined to address the response timerequirements imposed by the physical plant.

In this section, two implementations are presented for theproposed in this paper design. One based on the widely used IEC61131 standard and more specifically on version 3.0 of thestandard that supports object-oriented programming and theother on a general purpose object oriented language. Java wasselected as language of this type. Both implementations are basedon the scan cycle model. A key issue in these implementations is

Liqueur Plant system based on a UML profile.

Fig. 7. Snapshot of the educational version of the Liqueur Plant example application.

Fig. 8. Sample IEC 61131 code.

K. Thramboulidis / Computers in Industry 72 (2015) 92–102 99

that the framework has embedded the high level control flow ofthe application so the developer has to focus on the selection ofcomponents that will constitute the system and their integration.This greatly simplifies the construction of this kind of systems.The high level control flow is that introduces several bugs andmakes the programming of these systems difficult to compre-hend. The java implementation allows a better integrationwith state-of-the-art technologies and allows an easier transitionto the new industry paradigm, where distribution, reconfigur-ability, portability, evolvability and scalability are primaryrequirements. For example, the IoT infrastructure based on CoAPis already available for the Java language. An example of this isCalifornium [46], a Java implementation of CoAP that providesthe basis for the integration of the plant’s components. On theother side specific wrappers should be implemented for the IEC61131 implementation to allow the exploitation of IoT infra-structure.

5.1. A Java based implementation

The proposed design can be implemented in Java and executedon the various embedded boards, mainly based on ARM processors,that recently appeared in the market. A mapping to Java constructsis proposed in this section so as to apply the scan cycle basedexecution. The design of the software part of the cyber–physicalsystem has been implemented in Java and executed with asimulator of the liqueur plant to prove the effectiveness of thedesign. The system has been developed as educational tool to beused in labs in related courses. An executable version of thisimplementation is available for download from the web site of theauthor.

Fig. 7 presents a snapshot of this implementation, where silosS1, S2 and S4 have been instantiated. Using this system, studentsmay comprehend the differences of a traditional Java basedimplementation of the plant controller from the cycle based oneand identify challenges and technologies that provide solutionsto both implementations. They can be exposed to the use ofhigher layers of abstraction and also to the various mechanismsof the implementation environment to address mutual exclusionproblems that appear in the traditional Java event-basedimplementation and compare this with the time triggeredimplementation that is adopted in PLC systems. The scan cycle

based Java implementation is based on the use of Java Timers. Thisis actually the implementation of the Task construct of the IEC61131 model.

The LiqueurPlantSystem in this implementation is defined as acomposition of cyber–physical components. A visualization frameis used to instantiate the required virtual cyber–physicalcomponents and the plant processes such as GenLiqueurA andGenLiqueurB. Power has been modeled as resource to re-use thealready developed generic infrastructure for handling the pipe as acommon resource. The PlantController setups the timer anddefines through the execute operation of the controllerTimerTask the activity that should be executed by this timer, asfollowing:

controllerTimer = new Timer();

controllerTimer.schedule(newcontrollerTimerTask(), 0, 500);

where the controller has been defined to extend the TimerTask and sooverride its run method.

Fig. 9. Implementing ports for the MHSilo controller.

Fig. 10. Implementing ports for the GenLiqueurA process.

K. Thramboulidis / Computers in Industry 72 (2015) 92–102100

5.2. IEC 61131 based implementation

The new version of IEC 61131, i.e., version 3.0, which providessupport for object oriented programming, allows for a morestraightforward mapping of the SysML/UML design specs to the

Fig. 11. Implementing por

implementation language constructs. However, a mapping to thewidely used today IEC 61131 is also possible, exploiting the alreadyexisting support for object based programming that is provided byversion 2.0 of the standard. An example of such an implementationis given in [3].

The function block and the class constructs of the IEC 61131 areused to implement classes of the design specification, while theinterface construct is used to implement interfaces. Fig. 8 presentsexample IEC 61131 code that will be automatically generated fromthe design specification.

Cyber components of type ‘‘process’’ can be hosted in cyber–physical components that offer hosting services of the requiredquality of service, if any, or they may be allocated to shared orexclusively used execution environments. In the remaining ofthis section the implementation of the port design construct ispresented.

The proposed implementation for the port construct providesvery low coupling between the system components. Fig. 9 presentshow the two ports of the MHSilo controller, which is shown inFig. 4, are implemented based on the proposed approach.

One port, the itsProcessPort, which is used to interconnect thecontroller with its process, is of type MHSiloProcessPort, which

ts for the Silo Driver.

K. Thramboulidis / Computers in Industry 72 (2015) 92–102 101

inherits the Controller2-ProcessPort and implements theMHSiloIf. This port contains also the data member itsProcess

through which the MHSilo component accesses the services that itrequires from the process level corresponding component that willbe interconnected to this port. These required services arespecified by the type of the itsProcess data member that is of typeProcess2MHSiloIf as shown in Fig. 10.

The other port, the itsDriverPort, which is not shown in Fig. 4, isused to interconnect the controller with the corresponding SR inthe case that a higher modularity is also required for the cyber partof the cyber–physical component. This port implements theMHSiloCtrl2DriverIf and includes a data member itsDriver of typeMHSiloDriver2ControllerIf (see Fig. 11). It should be noted that dueto high coupling between the physical part and its SR the first levelof reusability is the one above the SR. However, also at this level thecoupling between the SR and the controller is high in most ofthe cases. Due to this high coupling between the controller andthe SR that results to a low potential for reusability at this level,interfacing with ports at this level is considered not effective. Thisis also the reason for considering as effective reusability the cyber–physical component level and adopt a more effective compared toport implementation of interfacing between SR and the controller.

Compliant ports may be interconnected by means of con-nectors. Establishing a connector means to setup the correspond-ing data members of the connected ports.

6. Conclusion

The shift from the PLC and the traditional IEC 61131 baseddevelopment process to the new object-oriented version of the IEC61131 is an involved task for industrial developers, who are used tothis programming paradigm for many years. Knowledge of thebasic concepts of the object oriented paradigm is required, buteven in this case the shift is quite complicated. In this paper, wehave presented a cyber–physical system-based approach thatgreatly simplifies this process. In particular, we have proposed alayered architecture for the cyber–physical component, and, wehave adopted the REST network-based architectural style for theintegration of system level cyber physical components with thecyber components that realize the plant’s processes. Importantly, amore tightly coupled implementation based on SOAP and XML isalso supported by the proposed approach.

An example application has been developed in the form of a labexercise to be used by students and industrial developers. Thepurpose is for them to understand both the use of higher layers ofabstraction in system modeling expressed in UML/SysML and theirrealization using the IEC 61131 and state-of-the-art technologiessuch as IoT. Our approach can also be used to generateimplementations on the various ARM-based embedded boardsthat have recently appeared in the market. This would simplify theadoption of new technologies from the general purpose computingdomain and would lead to a better exploitation of the IoT.

The presented architecture may be criticized as one thatintroduces performance overhead, but at the same time it greatlysimplifies the development process and increases the quality androbustness of the generated code. Our focus here has been on thesystem-based approach. Note however that the traditionalapproach in the development of these systems is also supportedwhich allows the approach to be applied to legacy systems as well.

For the case of the IEC 61131, we plan to fully integrate the IoTcommunication infrastructure within the function block modelin order to facilitate the system integration for the industrialdeveloper. In particular, our priority is on the generation of theglue code that is required for the integration of process cybercomponents with the corresponding cyber physical components,which realize the plant’s process. In this context, support will be

provided for uploading new behavior to the cyber physicalcomponents to satisfy the reconfigurability requirement that isof high priority in today’s industrial automation systems.

Acknowledgments

Part of this work has been funded by Bayerische Forschungs-stiftung (Grant no. PIZ-204-14) in the context of an internationalcollaboration. Thanks are due to anonymous referees for thenumerous remarks and suggestions that have resulted in animproved version of the paper.

References

[1] International Electrotechnical Commission, IEC International Standard IEC 61131-3: Programmable Controllers, Part 3: Programming Languages, IEC, 2003.

[2] K. Thramboulidis, G. Frey, An MDD process for IEC 61131-based industrial automa-tion systems, in: 16th IEEE International Conference on Emerging Technologies andFactory Automation (ETFA11), September 5–9, Toulouse, France, 2011.

[3] F. Basile, P. Chiacchio, D. Gerbasio, On the Implementation of industrial automa-tion systems based on PLC, IEEE Trans. Autom. Sci. Eng. 10 (October (4)) (2013)990–1003.

[4] T. Strasser, A. Zoitl, J.H. Christensen, C. Sunder, Design and execution issues in IEC61499 distributed automation and control systems, IEEE Trans. Syst. Man Cybern.C: Appl. Rev. 41 (January (1)) (2011).

[5] International Electrotechnical Commission, International Standard IEC61499,Function Blocks, Part 1–Part 4, IEC, 2005.

[6] L.H. Yoong, P.S. Roop, V. Vyatkin, Z. Salcic, A synchronous approach for IEC61499 function block implementation, IEEE Trans. Comput. 58 (December(12)) (2009) 1599–1614.

[7] K. Thramboulidis, Design alternatives in the IEC 61499 function block model, in:11th IEEE Int. Conf. on Emerging Technologies and Factory Automation (ETFA’06),September, Prague, 2006.

[8] K. Thramboulidis, IEC 61499 vs. 61131: a comparison based on misperceptions, J.Softw. Eng. Appl. 6 (July) (2013) 405–415.

[9] V. Vyatkin, IEC 61499 as enabler of distributed and intelligent automation: state-of-the-art review, IEEE Trans. Ind. Inform. 7 (November (4)) (2011).

[10] International Electrotechnical Commission, IEC 61131-3 International Standard,Edition 3.0 (2013-02-20) Programmable controllers – Part 3: Programminglanguages.

[11] CODESYS. http://www.3s-software.com/.[12] http://www.beckhoff.com/.[13] B. Vogel-Heuser, M. Obermeier, S. Braun, K. Sommer, F. Jobst, K. Schweizer,

Evaluation of a UML-based versus an IEC 61131-3-based software engineeringapproach for teaching PLC programming, IEEE Trans. Educ. (2012).

[14] C. Douglas, Schmidt, Model-driven engineering, IEEE Comput. 39 (2) (2006) 25–31.[15] K. Thramboulidis, Using UML in control and automation: a model driven ap-

proach, in: 2nd IEEE International Conference on Industrial Informatics (INDIN04), 24–26 June, Berlin, Germany, 2004.

[16] K. Thramboulidis, S. Sierla, N. Papakonstantinou, K. Koskinen, An IEC 61499 basedapproach for distributed batch process control, in: 5th IEEE International Confer-ence on Industrial Informatics, July 23–27, Vienna, Austria, 2007.

[17] L. Bassi, C. Secchi, M. Bonfe, C. Fantuzzi, A SysML-based methodology formanufacturing machinery modeling and design, IEEE/ASME Trans. Mechatron.16 (December (6)) (2011) 1049–1062.

[18] D. Witsch, B. Vogel-Heuser, PLC-statecharts: an approach to integrate UML-statecharts in open-loop control engineering—aspects on behavioral semanticsand model-checking, in: Proc. 18th IFAC World Congress, Milan, Italy, 2011,7866–7872.

[19] T. Cucinotta, A. Mancina, G.F. Anastasi, G. Lipari, L. Mangeruca, R. Checcozzo, F.Rusina, A real-time service-oriented architecture for industrial automation, IEEETrans. Ind. Inform. 5 (3) (2009) 267–277.

[20] P. Spiess, S. Karnouskos, D. Guinard, D. Savio, et al., SOA-based integration of theinternet of things in enterprise services, in: IEEE International Conference on WebServices (ICWS 2009), 6–10 July, Los Angeles, CA, (2009), pp. 968–975.

[21] Design Principles for Industrie 4.0 Scenarios, 2015 Available from: http://www.snom.mb.tu-dortmund.de/cms/de/forschung/Arbeitsberichte/Design-Principles-for-Industrie-4_0-Scenarios.pdf.

[22] G. Rzevski, On conceptual design of intelligent mechatronic systems, Mechatro-nics 13 (2003) 1029–1044.

[23] J. Amerongen, Mechatronic design, Mechatronics 13 (2003) 1045–1066.[24] F. Mhenni, et al., A SysML-based methodology for mechatronic systems architec-

tural design, Adv. Eng. Inform. (2014), http://dx.doi.org/10.1016/j.aei.2014.03.006.[25] G. Gossler, J. Sifakis, Composition for component-based modeling, Sci. Comput.

Program. 55 (1–3) (2005) 161–183.[26] B. Schatz, A. Pretschner, F. Huber, J. Philipps, Model-based development of

embedded systems, in: Proc. of OOIS’02. Lecture Notes in Computer Science.vol. 2426, Springer, Berlin, 2002, pp. 298–312.

[27] M. Basanta-Val, I. Garcıa-Valls, Estevez-Ayres, Towards a cyber–physical archi-tecture for industrial systems via real-time Java technology, in: 10th IEEE Intern.Conf. on Computer and Information Technology (CIT 2010), June 29–July 1,Bradford, UK, 2010.

K. Thramboulidis / Computers in Industry 72 (2015) 92–102102

[28] B. Werner, Object-oriented extensions for IEC 61131, IEEE Ind. Electron. Mag. 3 (4)(2009) 36–39.

[29] V.M. Gonzalez, A.L. Sierra Diaz, P. Garcia Fernandez, A. Fernandez Junquera, R.Mayo Bayon, MIOOP. An object oriented programming paradigm approach on theIEC 61131 standard, in: 15th IEEE Conference on Emerging Technologies andFactory Automation (ETFA), September, Bilbao, Spain, (2010), pp. 13–16.

[30] K. Thramboulidis, Towards an object-oriented extension for IEC 61131, in: 17thIEEE International Conference on Emerging Technologies and Factory Automa-tion, (ETFA), September 17–21, Krakow, Poland, 2012.

[31] K. Thramboulidis, G. Doukas, G. Koumoutsos, A SOA-based embedded systemsdevelopment environment for industrial automation, EURASIP J. Embed. Syst.2008 (2008), Article ID 312671, 15 pp..

[32] S. Karnouskos, A.W. Colombo, T. Bangemann, K. Manninen, R. Camp, M. Tilly, P.Stluka, F. Jammes, J. Delsing, J. Eliasson, A SOA-based architecture for empoweringfuture collaborative cloud-based industrial automation, in: IECON 2012-38thAnnual Conference on IEEE Industrial Electronics Society, 2012, 5766–5772.

[33] G. Starke, T. Kunkel, D. Hahn, Flexible collaboration and control of heterogeneousmechatronic devices and systems by means of an event-driven, SOA-basedautomation concept, in: 2013 IEEE International Conference on Industrial Tech-nology (ICIT), 2013, 1982–1987.

[34] J. Puttonen, A. Lobov, J.L.M. Lastra, An application of BPEL for service orchestrationin an industrial environment, in: IEEE International Conference on EmergingTechnologies and Factory Automation, 2008 (ETFA 2008), 2008, 530–537.

[35] Manufacturing and the ‘‘Internet of Things’’, AutomationWorld. Available from:http://www.automationworld.com/information-management/manufacturing-and-internet-things.

[36] J. Huang, F. Bastani, I.-L. Yen, W. Zhang, A framework for efficient servicecomposition in cyber–physical systems, in: Proceedings of the Fifth IEEE Inter-national Symposium on Service Oriented System Engineering (SOSE), June, Nanj-ing, 2010.

[37] K. Thramboulidis, The 3+1 SysML view-model in model integrated mechatronics,J. Softw. Eng. Appl. 3 (2) (2010) 109–118.

[38] M. Jamro, B. Trybus, An approach to SysML modeling of IEC 61131-3 controlsoftware, in: 18th International Conference on Methods and Models in Automa-tion and Robotics (MMAR), 2013, 26–29 August, (2013), pp. 217–222.

[39] K. Thramboulidis, D. Perdikis, S. Kantas, Model driven development of distributedcontrol applications, Int. J. Adv. Manuf. Technol. 33 (June (3–4)) (2007).

[40] C. Secchi, M. Bonfe, C. Fantuzzi, R. Borsari, D. Borghi, Object-oriented modeling ofcomplex mechatronic components for the manufacturing industry, IEEE/ASMETrans. Mechatron. 12 (2007) 696–702.

[41] E. Estevez, M. Marcos, D. Orive, Automatic generation of PLC automation projectsfrom component-based models, Int. J. Adv. Manuf. Technol. 35 (6) (2007) 527–540.

[42] G. Barbieri, et al., A model-based design methodology for the development ofmechatronic systems, Mechatronics (2014), http://dx.doi.org/10.1016/j.me cha-tronics.2013.12.004.

[43] J. Sztipanovits, X. Koutsoukos, G. Karsai, et al., Toward a science of cyber–physicalsystem integration, Proc. IEEE 100 (1) (2012) 29–44.

[44] C.W. de Silva, S. Behbahani, A design paradigm for mechatronic systems, Mecha-tronics 23 (2013) 960–966.

[45] OMG Systems Modeling Language (OMG SysMLTM), Version 1.3, 2012.[46] Californium. https://eclipse.org/californium/.

Kleanthis Thramboulidis is a research and teachingstaff professor in software engineering in the Depart-ment of Electrical & Computer Engineering at Universi-ty of Patras, Greece. Visiting professor at TechnischeUniversitat Munchen (2014), Saarlandes UniversityGermany (2010–2011) and Aalto University Finland(2009–2010). He teaches courses as Software Engineer-ing, Programming Languages, Advanced ProgrammingTechniques, Software Engineering for Embedded Sys-tems, IoT, etc. He has authored seven books onprogramming and modeling and contributed 3 bookchapters. He proposed a constructivism based approachto teach object oriented programming and organizedseveral Special Sessions in the domain of Factory

automation and industrial informatics. He is the designer of REDOM, an OOLanguage to define and on-line manipulate regulations in the resource (re)schedul-ing problem used in the airline domain, and CORFU, a framework for the unifieddevelopment of distributed control systems (http://seg.ece.upatras.gr/corfu/). Hehas proposed Model Integrated Mechatronics (MIM), a new paradigm for the modeldriven development of Mechatronic Manufacturing systems. Research areas coverIndustrial Automation Systems, Mechatronics, object technology, model drivendevelopment, meta-modeling, distributed control and automation systems,embedded systems, component and service based development, service-orientedarchitectures, semantic web and IoT. He is a member of the IEEE IndustrialElectronics Society, the Association for Computing Machinery and the IEC WG7-TC65-SC65B.