Towards Increased Flexibility and Interoperabilityin Distributed Process Control Applications

Ahsan Zia, David HastbackaComputing SciencesTampere UniversityTampere, Finland

{ahsan.zia, david.hastbacka}@tuni.fi

Abstract—The modern process automation plants arechanging into flexible designs, which raises the require-ments for distributively controlled logic, a high degreeof interoperability, dynamic reconfiguration and softwarereusability. Thus, creating an opportunity to integratethe distributed control system standards and platformindependent communication protocols. In this paper, wepropose the use of OPC UA to increase interoperabil-ity of communication and the utilization of ArrowheadFramework to enhance interoperable service compositionsof control applications implemented in IEC 61499. Theconcept is outlined for the integration and modeling of adistributed control system for a FESTO laboratory batchprocess system. A control application example is providedto create distributed control of Cyber-Physical Systemsusing services that are connected using IEC 61499 inaccordance to Industry 4.0 for improved interoperabilityand flexibility.

Index Terms—Cyber-Physical Systems, Industry 4.0,IEC 61499, 4Diac, OPC UA, Arrowhead Framework

I. INTRODUCTION

The world of technological developments of industrialproduction systems are changing on a rapid pace. Indus-try 4.0 is a concept that explains how industrial produc-tion systems are enhancing over time [1]. Industry 4.0 isbased on Industrial Internet of Things (IIoT) and Cyber-Physical Production Systems (CPPS), an amalgamationof the real world and the virtual world [2] [3].

The implementation, development and use of the IEC61499 standard supports a model-based development ofdistributed control systems [4]. The key entity in theIEC 61499 standard is the Function Block (FB), whichenvelops the control and communication algorithms indifferent programming languages [5].

OPC Unified Architecture [6], simply referred to asOPC UA, is a standard that ensures interoperability,open connectivity, security and reliability of industrial

automation system and devices. It is vendor independentand works with different software platforms, offeringOPC UA an edge over the traditional industrial com-munication protocols [7].

Arrowhead is an open source framework for industrialService Oriented Architectue (SOA) based applications[8]. It has been designed to not interfere with the basiccontrol operation of industrial systems. The great chal-lenges of the Arrowhead Framework (AHF) are to enableinteroperability and integrability of services producedand consumed by the devices [9]. The AHF is addressingIoT based automation and it provides interoperabilitybetween services, in a SOA [10].

This paper serves as a base study for dynamic or-chestration of process control functions exposed in OPCUA to be utilized in IEC 61499 applications and usingArrowhead to manage the connections.

The rest of the paper is organized as follows. Section IIdescribes the related work, background and technologiesused. In Section III the objectives and the motivationbehind the approach is explained. Section IV detailsthe case process and gives a brief description aboutthe laboratory process. Section V presents the proposedconcept of connecting the Arrowhead services and OPCUA services to IEC 61499 applications. Section VIcontains results and discussion. Finally, the conclusionand future work is presented in Section VII.

II. RELATED WORK AND BACKGROUND

A few key arguments in support of Industry 4.0include modular structure, CPPS, remotely monitoringphysical processes, digital twins and decentralized deci-sion making. These requirements lead to the investigationand introduction of new concepts and standards [11]. Thestandards and concepts explained in Section I supportdistributed controlled logic, interoperability, portability,

reconfiguration, software reusability and platform inde-pendent communication protocols as explained by [2].

The integration of the IEC 61499 standard and Arrow-head IoT services for flexible manufacturing applicationspresent SOA where services are located at the devicelevel as well as in local and global clouds orchestratedby the AHF as proposed by [9].

A study [12] addresses a similar methodology ofcombining batch process design and control applica-tions with IEC 61499 for improving flexibility of thesystem. Regarding interoperability of CPPS, this hasbeen previously discussed by [13] for harmonizing theinterfaces using Semantic Web technologies. Similarly,in [14] Semantic Web technologies have further beencombined with OPC UA. The information model of OPCUA can also be seen to provide the required semanticsbut without the Semantic Web reasoning aspects.

The following subsections briefly explain the imple-mentation technologies for the development concept.

A. OPC UA

OPC UA is a communication protocol [6], that isplatform independent SOA, which integrates all the func-tionality of the individual OPC Classic specifications intoone extensible framework. It is deployed over TCP/IP butmore recently also supports UDP. OPC UA has its ownbinary protocol but can also make use of Web Servicecommunication. Different control systems can provide itsown OPC UA servers, and clients can access it directly.

Typical application areas for OPC UA is communica-tion between Process Control Systems (PCS) and Manu-facturing Execution Systems (MES) as well as betweenthe individual components of production systems [15].

B. Arrowhead Framework

AHF is addressing IoT based automation. It is an opensource framework for industrial SOA based applications[8]. It has been designed to not interfere in the basic con-trol operation of industrial systems. AHF are to enableintegrability and interoperability of services producedand consumed by any system or device. AHF definessystems as the participant entities of the SOA. The sys-tems then communicate via service contracts. The corefunctionalities of the framework include orchestration,service registry and authorization [10].

C. IEC 61499 standard

IEC 61499 standard for the distributed systems, whichis able to handle the complexity of inter-connectedautomation systems. It also significantly decrease the

development time by overcoming driver programmingand signal mapping for communication between differ-ent systems and devices [4]. IEC 61499 also allowsplatform-independent PLC code development [16].

III. OBJECTIVES OF THE APPROACH

The diagram in Figure 1 shows the approach behindthe the idea of this implementation. The control is boundto logical data points and functions of the devices. Thecommunication takes place through a number of OPCUA services represented as corresponding interface FBs.

Run

time

(FO

RT

E)

Distributed Control Application

OPC UA Server

Process equipment

Service Interface Function Block

(OPC UA)

Service Interface Function Block

(OPC UA)

Service Interface Function Block

(OPC UA)

Control algorithms and function block networks

Process equipment Process equipment

OPC UA Server OPC UA Server

Logical data points and device functions

Control algorithms and function block networks

Interchangeable OPC UA connections to devices and subsystems

Fig. 1. Block Diagram for the implementation of the System

OPC UA connection

61499 Application

Bind to equipment using OPC UA

Measurements Control logic

Arrowhead Registered Services

fieldbus

Industrial PC(MPP)

OPC UAserver

Twincat run-time

ProcessequipmentSiemens IO

61499 run-time

Easily exchangeable,from development to

deployment

Simulation server(MPP)

OPC UAserver

OPC UA Dynamic Endpoints

Fig. 2. Exchangeable OPC UA connections with agreed, interoper-able interface definitions facilitate development.

A benefit of the approach is that the control systemcomponents have the capability of being interchangeablegiven that same interface semantics are adhered to. Thisis also the case in our example between a simulationprocess and corresponding actual hardware as shown inFigure 2. In our example, a simulation server is usedto ease development as well as testing and it is easilyreplaceable with the real hardware due to an exactlyidentical OPC UA interface of the physical setup.

Figure 2 also shows the integration of AHF to thesystem where the idea is to acquire these service end-points dynamically at run-time for the application to use.In comparison, OPC UA discovery is typically used ina local network whereas AHF provides discoverabilityand composability across the internet, if required.

IV. CASE PROCESS LABORATORY SETUP

This section explains the hardware of the Mini PulpProcess (MPP) system. Figure 3 presents the physicalsetup of the laboratory process.

Fig. 3. Image of the actual physical process with its equipment

The MPP system processes are divided into five unitprocedures. These unit procedures are controlled by thefunctional elements such as valves and pumps along withtemperature sensors and analogue gauges. The equip-ment consists of four large tanks, of different capacities.One of the tanks is a pressure-controlling vessel, which isused to control pressure inside the system environment.The equipment includes two pumps, a heater and twocontrol valves and a series of open shut valves.

Fig. 4. The mini pulp process simulator user interface

In addition to that, there is a manual valve; PVC pipesused for the connection between the tanks. The tanksare connected either directly or through a connectionof second tank. Liquid can be pumped into any of thealternative tanks using the pipe system.

Apart from a few alterations and a few additions, theprocess Simulator contains all the functionalities. Figure4 presents the MPP simulator user interface.

V. INCREASED INTEROPERABILITY AND FLEXIBILITY

A. Connecting OPC UA services

The control application created in 4Diac framework iscomposed of different FBs and data connection amongthe FBs. The OPC UA servers expose all the services ofthe process equipment (simulator or hardware). From theOPC UA address space each node representing a devicethat offers input or output is translated into a FB. Figure5 presents a snapshot of a distributed control application.

Fig. 5. 4Diac application SIFBs

The Service Interface Function Block (SIFB) PUB-LISH FB is to write to an OPC UA variable to a remoteserver, and uses the SIFB CLIENT FB to read theincremented value from the remote server, which readsthe variable’s value as soon as the request is triggered.

B. Envisioned Usage of Arrowhead Framework

The envisioned usage of AHF is that the OPC UAendpoint services can be registered at the service reg-istry from where they can be discovered to be com-bined into applications. AHF provides the endpoints tothe applications dynamically at run-time. For example,a controller requests the orchestrator and the serviceregistry for which devices and sensors it should use.The orchestrator has the configuration and the setup ismaintained centrally, instead of declaring it locally in the4Diac control applications. 4Diac FB library have beendefined for AHF version 4.1.2 [17] but they are not yetavailable for the newer AHF versions. Figure 6 presentthe application in the Arrowhead Function Blocks in the4Diac application.

Fig. 6. Arrowhead FBs developed for 4Diac ease integration ofArrowhead orchestrated services into IEC 61499 applications.

VI. RESULTS AND DISCUSSION

The ambition behind the work is the integration ofOPC UA endpoint services as interoperable and ex-changeable building blocks of devices and their func-tionality in IEC 61499 control applications.

These services contain OPC UA endpoints which areprovided to the SIFB. SIFBs avail OPC UA as aninformation model to exchange data between the IEC61499 (4Diac) control applications and the industrial

systems and externally triggers the different application’sservices.

To summarize, OPC UA is a more open, secureand dependable mechanism for transferring informationbetween clients and servers. It provides added opentransport, greater security and a complete informationmodel over the traditionally used controller interfaces,as well as is able to connect to databases and enterprisemanagement systems with real world data from actu-ators, controllers, sensors and monitoring devices thatare able to interact with real processes [6]. In addition,the advantage of IEC 61499 over other programminglanguages is that, it utilizes eXtensible Markup Language(XML) as a storage and exchange format, which enablesthe migration among other IEC 61499 software tools andpermits platform independent PLC code development.This facilitates the reusable nature of FBs on otherplatforms, and therefore offering increased flexibilitycompared to IEC 61131 [16].

The interoperability and flexibility is expected to beincreased with the use of AHF providing an interoperableand common model for discovering and composingservices dynamically, including also a model for authen-ticating and authorizing application systems for securecompositions. In its simplest form AHF can be used todirectly retrieve service endpoints from the registry forthe applications to compose their interaction. This model,however, leaves the burden on the application to decideand know what specific services to use. By using theAHF orchestration some of this logic can be shifted to becentrally managed. The OPC UA discovery is currentlylimited to use in a local network environment. In com-parison AHF provides discoverability and composabilityacross the internet.

VII. CONCLUSION AND FUTURE WORK

There is an increase in demand for the distributed con-trol systems, with the requirement of integrating devicesand systems from different vendors. By utilizing IEC61499, we can now model and implement the controllogic to control processes without dependencies of thedevice specific features or vendor specific communica-tions.

This paper demonstrates how OPC UA can improvethe interoperability of communication and provide meansto interchangeably switch target devices to support devel-opment. The concept is extended by envisioning the useof AHF to provide the OPC UA endpoints to IEC 61499distributed control application dynamically at run-time.This is to further increase flexible use of interoperable

services using the AHF model for service compositionand management. For example, a controller requests theservice registry or orchestrator for which devices andsensors it requires. The orchestrator has the configurationand the setup is maintained centrally instead of declaringit locally in various application instances.

This improves flexibility of the system as well as easesthe engineering effort through improved interoperabilityonce standards based information models are being used.In our small example the control system is fully capableto be interchangeable between the simulator and theactual hardware which proves the point of interoperablesemantics as well as facilitates further development.

ACKNOWLEDGMENT

This work is related to the Productive4.0 projectand has received funding from the EU ECSEL JointUndertaking under grant agreement no. 737459 and fromthe national funding authority Business Finland. Theauthors are also grateful to the Academy of Finland fortheir funding supporting this work (grant no. 310098).

REFERENCES

[1] D. Vuksanovic, J. Vesic, and D. Korcok, “Industry 4.0: thefuture concepts and new visions of factory of the future devel-opment,” in Sinteza 2016 - International Scientific Conferenceon ICT and E-Business Related Research, 01 2016, pp. 293–298.

[2] M. Garcia, E. Irisarri, F. Perez Gonzalez, E. Estevez, andM. Marcos, “Automation architecture based on cyber physicalsystems for flexible manufacturing within oilgas industry,”RIAI - Revista Iberoamericana de Automatica e InformaticaIndustrial, vol. 15, pp. 156–166, 01 2018.

[3] M. V. Garcıa, F. Perez, I. Calvo, and G. Moran, “Developingcpps within iec-61499 based on low cost devices,” in 2015 IEEEWorld Conference on Factory Communication Systems (WFCS),May 2015, pp. 1–4.

[4] A. Zoitl and R. Lewis, Modelling control systems using IEC61499. 2nd Edition, 01 2014.

[5] T. Bezak, “Iec standards and distributed control systems mod-elling,” in 2012 IEEE Symposium on Industrial Electronics andApplications, Sep. 2012, pp. 242–245.

[6] OPC Unified Architecture Specification Part 1: Overview andConcepts v.1.01, OPC Foundation, 2008.

[7] S. Kozar and P. Kadera, “Integration of iec 61499 with opcua,” in 2016 IEEE 21st International Conference on EmergingTechnologies and Factory Automation (ETFA), Sep. 2016, pp.1–7.

[8] Arrowhead. Project github-repository and documen-tation. Accessed: 2020-02-10. [Online]. Available:https://github.com/arrowhead-f

[9] H. Derhamy, D. Drozdov, S. Patil, J. van Deventer, J. Eliasson,and V. Vyatkin, “Orchestration of arrowhead services usingiec 61499: Distributed automation case study,” in 2016 IEEE21st International Conference on Emerging Technologies andFactory Automation (ETFA), Sep. 2016, pp. 1–5.

[10] J. Delsing, P. Varga, L. Ferreira, M. Albano, P. Punal Pereira,J. Eliasson, O. Carlsson, and H. Derhamy, 3 The ArrowheadFramework architecture: Arrowhead Framework, 02 2017, pp.43–88.

[11] A. Bicaku, S. Maksuti, S. Palkovits-Rauter, M. Tauber, R. Ma-tischek, C. Schmittner, G. Mantas, M. Thron, and J. Delsing,“Towards trustworthy end-to-end communication in industry4.0,” in 2017 IEEE 15th International Conference on IndustrialInformatics (INDIN), July 2017, pp. 889–896.

[12] D. Ivanova, S. Panjaitan, I. Batchkova, and G. Frey, “Iec 61499component based approach for batch control systems,” IFACProceedings Volumes (IFAC-PapersOnline), vol. 17, 01 2008.

[13] D. Hastbacka and A. Zoitl, “Towards semantic self-descriptionof industrial devices and control system interfaces,” in 2016IEEE International Conference on Industrial Technology (ICIT),2016, pp. 879–884.

[14] V. Jirkovsky, M. Obitko, P. Kadera, and V. Marık, “Toward plugplay cyber-physical system components,” IEEE Transactions onIndustrial Informatics, vol. 14, no. 6, pp. 2803–2811, 2018.

[15] J. Virta, I. Seilonen, A. Tuomi, and K. Koskinen, “Soa-basedintegration for batch process management with opc ua and isa-88/95,” in 2010 IEEE 15th Conference on Emerging Technolo-gies Factory Automation (ETFA 2010), Sep. 2010, pp. 1–8.

[16] M. Kazmierkowski and F. A. Silva, “Distributed control appli-cations: Guidelines, design patterns, and application exampleswith the iec 61499 [book news],” IEEE Industrial ElectronicsMagazine, vol. 10, no. 4, pp. 81–82, Dec 2016.

[17] 4Diac. Documentation. Accessed: 2020-02-10. [Online]. Avail-able: https://www.eclipse.org/4diac/enhelp.php?helppage =html/communication/arrowhead.html