IoT-based Integration of IEC 61131 Industrial Automation Systems ...

IEEE Inter. Symposium on Industrial Electronics, Santa Clara, CA, June 2016.

IoT-based Integration of IEC 61131 Industrial Automation Systems: The case of UML4IoT Foivos Christoulakis, Kleanthis Thramboulidis Electrical and Computer Engineering University of Patras, Greece

Abstract—Internet of Things (IoT) plays a key role in the new generation of industrial automation systems (IASs). Evolving IoT standards if effectively used may address many challenges in the development of IASs. However, the use of the IoT and the REST architectural paradigm that IoT is based on, is not an easy task for the automation engineer. In this paper, a model driven system engineering process is adopted for IASs and it is extended to exploit IoT standardization efforts in IEC 61131 based system. IoT is considered as an enabling technology for the integration of cyber-physical and cyber components of the system and humans, bringing into the industrial automation domain the benefits of this technology. A UML profile for IoT is exploited to automate the generation process of the IoTwrapper, i.e., the software layer that is required on top of the IEC 61131 cyber part of the cyberphysical component to expose its functionality to the modern IoT IAS environment. A prototype implementation and performance measurements prove the feasibility of the presented approach. Keywords—Industrial Automation Thing, Internet of Things (IoT), UML profile for IoT (UML4IoT), IEC 61131, Industry 4.0, cyber-physical systems.

I. INTRODUCTION Computational processes of Industrial Automation Systems (IASs) are commonly implemented based on the de-facto standard IEC 61131, which defines a set of languages for programming on PLCs. These processes accept inputs from the physical processes, calculate the outputs required to affect the physical plant and apply these outputs to the physical part of the system, being its cyber part. This definition characterizes IASs as cyber-physical systems [1]. IEC 61131 has introduced in the industrial automation domain basic concepts of object orientation through the construct of Function Block (FB) [2][3]. However, as the complexity of manufacturing systems increases and flexibility is of higher priority, the 20 years old technology is not able to address the new requirements [4]. To address restrictions imposed by version 2.0 of IEC 61131, the IEC has recently upgraded this standard with a new version, i.e., version 3.0. The Service Oriented Architecture (SOA) has attracted the interest of researchers from the IAS domain but SOA was mainly utilized at the upper layers of the automation pyramid [5]. SOAP and XML introduce a performance overhead that is not acceptable at the device level. Academia and industry are moving towards the adoption of IPV6 to get the benefits of the evolution of IoT and Cloud computing, e.g., [6]. Several

works report on the use of IoT in the IAS domain, as for example [7-9]. It is widely accepted today that manufacturing is slowly but steadily experiencing a paradigm shift [10] towards what is known as Industry 4.0, e.g., [10][11], or Industrial Internet of Things (IIoT). IIoT, which is a new initiative, considers the IoT as the new logical transition from the automation and connectivity concepts that exist in the IAS domain for many years. The line between real and virtual world is blurring and this will change the way we design, deploy and use services, as claimed by authors in [12]. New methodologies, frameworks and tools are required to support a robust and effective development process where automated code generation [13] (model driven engineering) will play a key role. In this paper, the IAS is considered as a composition of cyber-physical and cyber components and humans, with well defined interfaces [14][15]. Based on that, we envision the development process of IASs as an integration of components at the mechatronic layer of abstraction [14]. SysML and UML are used for the specification of these components and IEC 61131 for the implementation of the cyber part of the cyberphysical component. IoT is proposed to be used as a glue for the integration of the system’s constituent parts as far as it regards their cyber interfaces. Evolving IoT standards, such as CoAP, LWM2M and IPSO smart objects, have been adopted to address interoperability issues and increase reusability in the IAS domain. However, the use of IoT as glue for the integration of system components increases the complexity of the job of industrial engineers. Training may facilitate the transition to the new development process, but specific frameworks and model driven engineering [16] if properly used may not only facilitate this transition but also increase productivity and reliability of the development process. In this context, this paper describes a framework that automates the integration of IEC 61131-based smart objects into the modern IoT IAS environment. More specifically, an approach is proposed to automatically generate the wrapper that is required on top of the IEC 61131 layer to interface the cyberphysical component with the outside world through the IoT. This software layer, which we call IoTwrapper, exposes to the environment, in an IoT compliant way, the interface of the component. The main contributions of this work are: (a) it exploits in IEC 61131 based systems the UML4IoT profile, which was defined for the use of IoT in IASs, and, (b) presents a

IEEE Inter. Symposium on Industrial Electronics, Santa Clara, CA, June 2016.

transformer to automate the generation of the IoTwrapper of the IEC 61131-based smart object. By marking the properties of the smart object, that would be exposed to the outside world, with the UML4IoT profile model elements and applying the model-to-model transformer, the mechatronic component is transformed to an Industrial Automation Thing (IAT) in the IoT world. The approach presented in this paper is based on the new version of 61131 but it can also be adapted to the old one to allow legacy components to be transformed to IATs and reused in the modern IoT industrial automation environment. To demonstrate the effectiveness of the proposed approach, the liqueur plant case study has been implemented using as computation node for the cyber-physical component a Raspberry Pi running the CODESYS Runtime [17]. Other works refer also on the use of UML to facilitate the exploitation of IoT in IASs. For example, authors is [18] describe an early approach to model RESTful interfaces for the IoT with UML. A visual domain specific modeling language for the IoT based on UML is described in [19]. To the best of our knowledge there is no other work that proposes a model-driven development process for the construction of the Industrial Automation Thing based on IEC 61131. The remainder of this paper is structured as follows. In the next section background work is briefly presented. The proposed approach for integrating an IEC 61131 cyberphysical component into the IoT is presented in section 3. In section 4, the prototype implementation is presented and performance measurements are given. Finally, the paper is concluded in the last section. II. BACKGROUND Based on the traditional approach for the development of mechatronic systems, the three discipline parts of the system, i.e., mechanics, electronics and software, are developed independently starting from the mechanical parts and ending with the software, and then are integrated. Several works, e.g., [14][20], consider this process inadequate to address the always increasing complexity of IASs. The mechatronic component [14] is proposed as the level of integration of the different discipline parts, i.e., mechanics, electronics and software, which are closely integrated to perform the component’s functionality in terms of material, energy and information transformations. In this sense the mechatronic component is a cyber-physical component that encapsulates its constituent parts and their interactions behind high level cyber interfaces, which transform the mechanical unit to a smart component with embedded intelligence. It encapsulates low level control and provides an interface without stringent realtime constraints. A. The myLiqueur production system The myLiqueur production system, based on the mechatronic component approach adopted in this work, is composed of the following cyber-physical components, shown in figure 1: smartSilo1, smartSilo2, smartSilo3, smartSilo4 and smartPipe. The myLiqueur production system is simple

but good enough to demonstrate the applicability and the benefits of using the proposed approach. It is based on the case study used in [4] and [15] and is extended to exploit the benefits of the IoT technologies and allow end users to produce custom types of liqueur. The end user may define, through the myLiqueur App, the production parameters of the desired type of liqueur, as shown in figure 1.

Fig. 1. The myLiqueur production system used as a case study. A cyber-physical component has a well defined interface through which it exposes its behavior to be used by the liqueur production processes (LiqueurGenerationProcesses). This interface is in the form of functionalities offered by the silo such as fill, empty, mix and heat. Implementation issues regarding the physical silo such as input and output valves and sensors for upper and lower level as well as those regarding the heaters, the mixers and the temperature sensors are encapsulated and hidden from the component’s environment. Smart silos are reserved in couples for the production of a specific type of liqueur. Smart silos 1 and 4 form one couple.; smart silos 2 and 3 the other. There are two constraints: (a) using the common pipe for the liquid transfer among the silos, and (b) mixing the liquid in silos smartSilo3 and smartSilo4 at the same time is not permitted due to a constraint in power consumption. B. ICE 61131 basic concepts used in this work Automation engineers use the IEC 61131 standard to specify the software part of their systems, mainly when programmable logic controllers (PLCs) are used [4]. Requirements of hard real-time systems in the industrial domain are also addressed by this standard [21]. In 2013 the third edition of IEC 61131-3 – Programming Languages, version FDIS (Final Draft International Standard) of 2012 was approved as International Standard and version 3.0 of IEC 61131 is officially available by IEC. The main feature of the new version is the extended support it provides for adopting the object oriented programming paradigm. Key constructs of the new version include among others: (a) the INTERFACE keyword to separate the interface from the

IEEE Inter. Symposium on Industrial Electronics, Santa Clara, CA, June 2016.

implementation, (b) the METHOD construct that extends the declaration of Function Blocks with the definition of methods, (c) the CLASS construct offered as an alternative to the FB building block, and (d) the EXTENDS keyword to support inheritance. This new version has been greatly influenced by the Java programming language. The INTERFACE keyword is used to define the interface construct which is similar to the Java interface. An interface contains a set of (implicitly public) method prototypes. It can be implemented either by a class or by an FB and may inherit another interface [22]. The CLASS keyword is used to define a class as this is defined in the object oriented programming paradigm. A class is similar to the FB except that it has no body and thus no inputs and outputs; it may define only methods. It has no graphical representation of its external interface. CODESYS 3 has already implemented an OO version of the IEC 61131 and other industrial vendors, e.g., Beckhoff (https://www. beckhoff.com/), are moving to this direction. The CODESYS Runtime, which is used in this work, converts the Raspberry Pi into a full-fledged IEC 61131-3 controller. IEC 61131 provides also support for the interaction of the constituent parts of an application that are allocated to different PLC-systems. According to the communication model of 61131, programs allocated on different configurations may communicate either through communication function blocks or access paths which are mechanisms to realize connections among application programs [22]. Both are considered in this work as alternative mechanisms on top of which the IoT wrapper could be developed. Moreover, IEC 61131-5 combines communication over different networks with a common user interface with the objective to harmonize the currently existing different communication solutions and systems [23]. The UML profile for IoT contributes to the IEC 61131-5, by considering the IoT wrapper as the unified interface on top of the currently existing different communication solutions and systems. III. INTEGRATING AN IEC61131-BASED SMART OBJECT INTO THE IOT A. The Architecture and the Interface of the IEC 61131 based cyber-physical component The SmartSilo mechatronic component is composed of the mechanical, electronic and software parts. Specific ports of the three disciplines are used to interconnect the components in terms of material, energy and information flow. In this work the focus is on the cyber interface, which is assumed to be specified in the object oriented traditional way using UML. A detailed description of the architecture of the mechatronic component can be found in [15]. In figure 2a the cyber interface is defined in terms of provided and required interfaces which are represented with the corresponding UML artifacts. The same information can also be captured in the graphical notation of the smartSilo 61131 FB (Fig. 2b). An IEC 61131 class may also be used to have a closer to the UML notation 61131 representation of the same information. Based on this, the smart silo exposes functionality expressed in the

form of four METHODS: fill(), empty(), heat2Temp() and mix(). The SmartSiloUserIf captures the required interface for the SmartSilo to be able to provide its functionality. For the mechatronic component to be considered as Thing in the IoT environment, this interface should be exposed in the environment in an IoT-compliant manner. A specific wrapper should be developed to transform the 61131-like interface to an IoT-compliant one.

(b) (a) Fig. 2. The provided and required interface of the SmartSilo. (a) using UML, (b) using the 61131 FB notation. B. The adopted IoT protocol stack IoT based solutions exist in the market for several years now. However, these solutions are based on proprietary protocol stacks that place a big barrier on the integration of different Things, even in the same application domain. Interoperability in the IoT is one of the key challenges. The IPSO alliance has identified the value added of IETF standard protocols for IP-enabled networks on Constrained Resource Environments (CoRE), and more specifically the Constrained resource Application Protocol (CoAP) [24]. CoAP is an application protocol for machines and connected devices, considered as a replacement of the http protocol. Based on the above, the IPSO alliance has defined the Smart Object Guidelines, which provides a common design pattern, i.e., an object model, that utilizes the IETF CoAP protocol to provide high level interoperability between smart objects and connected software applications on other devices and services [25]. The common object model defined by IPSO reuses the simple object based resource model defined by the OMA Lightweight M2M (LWM2M 1.0) specification [26] and its main objective is to generate guidelines that are required to have interoperable smart objects. The protocol stack that is used in this paper to transform the mechatronic component to an IAT is shown in figure 3. It is based on the LWM2M protocol, which is running on top of CoAP, and utilizes the IPSO guidelines for smart objects. At the time, there is no initiative to define industrial automation smart objects. However, it is expected that the IPSO Alliance will initiate in the near future the definition of LWM2M objects for this domain to increase interoperability and reusability. Custom smart objects have been defined in the context of this work. As shown in figure 3 the IAT is composed of the mechatronic component, which can be legacy or new, and the IPSO-compliant IoTwrapper. C. The UML4IoT profile The interface of the LWM2M, which is defined on top of an