An App-Based Approach for Reconfigurable Field Devices

Transcription

1 An App-Based Approach for Reconfigurable Field Devices Syed Shiraz Gilani 1, Tim Tack 2, Holger Flatt 1, Jürgen Jasperneite 1,2 1 Fraunhofer Application Center Industrial Automation (IOSB-INA), Lemgo, Germany {syed-shiraz.gilani, holger.flatt, juergen.jasperneite}@iosb-ina.fraunhofer.de 2 init - Institute Industrial IT, Ostwestfalen-Lippe University of Applied Science, Lemgo, Germany tim.tack@hs-owl.de Abstract Today, automation suppliers need to provide a large variety of field devices because one device is especially designed to provide a limited and static range of functionalities, which are fixed at the delivery time of the device. This is expensive for both customers and device suppliers. To overcome this situation, device functionalities needs to be adapted or extended on demand according to the changing market requirements, even if the devices have already been delivered to customers. In this work, an app-based approach is proposed and evaluated to serve that purpose. This approach is adapted from the smart device industry and it is used to provide software-based functionalities for field devices as an enabling technology in the context of reconfigurable manufacturing systems. This paper describes the essential elements of such an approach with a practical perspective. I. INTRODUCTION Today s automated technical systems are composed of dozens of field devices, which may differ in type, functionality and performance. Such field devices are typically developed to provide a specific range of functionalities, which are statically built into the device at delivery time. This is disadvantageous since it makes technical systems hard to adapt to new customer requirements during its life cycle, which is time consuming and expensive. Since Cost reduction remains the main driving force in automation [1], it seems beneficial to overcome this situation by the introduction of reconfigurable field devices (RFD). RFDs can be adapted to customer requirements on demand in a very short time frame, even if the functionality has not been built into the device at delivery time. An approach to provide such RFDs is by providing the device functionality as application specific software, install it on demand and execute it on the device. However, the concept where functionality is provided through small software applications is not new and its already used with smart phones and tablets as apps. According to [2], an app is defined as: a piece of software specifically designed to run on a mobile device, such as a smart-phone or tablet that cooperates with the operating system (OS) of the device in order to take advantages of the device features, e.g. built-in sensors like GPS. According to [3], apps offer benefits such as the ease of discovering an app through the search engine built into a distribution platform and the ability to exploit native device features. Furthermore, no expert knowledge about the programming language or the OS of the smart phone is needed to install, setup and use an app. Apart from smart device market, this concept was also extended in a research project, MARION [4]. This project, which is funded by the German Federal Ministry for Economic Affairs and Energy, has setup a software market to distribute software based functionalities for the agricultural machinery. However, the app concept has not been evaluated in terms of suitability as an enabling technology for RFDs in the automation industry yet. An RFD is part of a reconfigurable manufacturing system (RMS), which can be summarized as: An RMS is a system designed at the outset for rapid change in structure, as well as in hardware and software components, in order to quickly adjust production capacity and functionality within a part family [5]. The contribution of this work is to evaluate the suitability of an app concept in the automation industry as an enabling technology to facilitate RFDs within an RMS. This is achieved by providing software based functionality that can be commissioned easily and within a very short time frame. This paper is structured as follows: In section II, the field device app concept is proposed. To complement the proposed concept with practical insights, two application scenarios are analyzed in section III and finally this work is summarized in section IV. II. FIELD DEVICE APP CONCEPT In this section, the field device app concept is introduced as depicted in Figure 1. Within this concept, the device suppliers will be able to publish software functionalities in an app distribution platform, in order to add an additional value to the devices. The device customers, such as machine builders, system integrators or plant operators, will be able to use the app distribution system to find, buy and download the required app-based functionality to the field device. On the field device, a software execution platform will be used to access the distribution system, to install apps with 1-click mechanism and to execute the application. 1-click mechanism is a feature that let users install apps with 1 click, without expert knowledge about the OS or a programming language. Based on this, the proposed concept will have the following three central elements: A. Development environment The mature development environment is a very important feature within the smart device app concept, since it assists the app developers in the implementation of apps. Thus, a mature development environment reduces the entry barrier for the developers and therefore supports the smart phone app

2 Device Supplier Fig. 1. develop / publish APPs App Distribution Platform App: Provide field device functionality as software Data preprocessing Enhanced device control The field device app concept Field-Device Software Execution Platform App1: control Store Access find, download, install App2: Control based on sensor data Sensor Machine Builder / System Integrator / Plant Operator business model (cf. [6]). However, in order to provide a final statement about its impact and the needed functionalities, the development environment needs to be further evaluated, which is out of scope of this work. Development environment will be further evaluated once an app concept would actually be established on the market. B. Central distribution platform The central distribution platform (CDP) is the second building block of the app concept. It allows both developers and customers to make business through a central billing system, which removes hurdles, like regional tax specifications (cf. [6]). The CDP also allows customers to search for the desired functionality and to obtain it in a very short time frame. Therefore, it reduces the device commissioning effort and helps the customers to adapt the software based field-device functionality through ready-to-use applications on demand. Thus, it helps to evolve the technical system during its lifecycle, to keep up with the customer requirements. In order to ensure a base quality level, the major platform providers Apple and Google use an app approval process (cf. [6]). However, a more detailed approval process is mandatory for field device applications, since the field devices need to provide the functionality with high requirements on reliability. Also, legal consultation is required to establish that who is responsible for eventual guarantee claims in the case of malfunction caused by an app. Besides the functional quality of an app, security aspects must be considered likewise as automation devices are attractive to be attacked by computer viruses. This implies that the platform vendors need to provide means to ensure that the application is not modified once it has been approved. This could be done through developer certificates that can be checked at the customer side before the installation. CDP location is an important aspect as well, since a direct internet connection between store and industrial network would imply a huge security risk. In addition to the security aspects, the ability to establish a communication between the distribution system and the field device needs to be discussed. There are field devices without own high level communication interface that can be used for the app installation. An approach to overcome this situation could be, e.g., a wireless hand held device that is connected to both the distribution system and the field device. It could be used to bridge the communication, access the distribution platform and download the application to the device. C. Execution system The execution system provides certain features, with most important being the access to the distribution platform and the ability to install apps with 1-click mechanism without the need for expert knowledge about the execution system and programming skills. However, a 1-click mechanism is needed that not just transfer the compiled app to the device but also connect the app to the actual hardware interfaces of the field devices at device commissioning instead of development time. This is essential in order to respect the huge amount of different devices and their modular hardware structure. In the smart phone app concept, hardware is accessed through an application programming interface (cf. [7]). Hereby, the application hardware is used without the knowledge about the actual hardware topology of the device. The mapping between hardware and application is done automatically through the application framework provided by the execution platform, without the user interaction, while the application is executed on the device. This approach can also be adapted for the field device app concept, since a mechanism that provides an assisted or automatic mapping of the field device app to the device hardware could further simplify and speed up the device commissioning phase. The following features are required for this adaptation: (i) The application must be able to state its hardware requirements. (ii) The actual hardware configuration of the field device needs to be described in a formal way. (iii) The execution system must provide a mechanism that checks the compatibility between the required hardware of the app and the actual hardware configuration of the device. (iv) The execution system must provide a mechanism to create a mapping between the apps hardware interfaces and the device hardware when the application is installed on the device and not when the application is developed, in order to allow hardware changes during the device life cycle. (v) In the case that the hardware mapping could not be done automatically, the execution system must at least allow the technician to establish the mapping during the device commissioning. The execution system must also provide the recommendations of compatible hardware, which are either required by the app or connected to the device, during this phase. Unlike smart phones, field devices are typically not equipped with a touch screen. Thus, a mechanism needs to be provided that allows to configure a huge variety of field devices with its functionalities through a well-defined and easy to use interface. A potential solution could e.g. be provided through Field Device Integration (FDI), which is supported by several vendors (cf. [8]) and provides mechanisms to configure the devices. It is also important for RFD to store the configuration consistently and make it traceable. This is important as in the case of a device failure, the automation industry strives to replace a device within a short time frame. This avoids a production lock down and thus save money. A possible solution to this requirement can be seen by the IO-Link system, where the device configuration is stored at a central point and in case of a device failure, the replacement device is automatically set up with the configuration of the replaced device. However, the realization of such a functionality is also tightly coupled to the actual device, since e.g. the device needs to be identified in order to upload the correct configuration. In case the device is a

3 simple sensor without own processing capabilities (e.g. CPU), first a solution needs to be found that enables the device to identify itself, e.g. through a unique field device ID that is communicated on power up. Besides the automatic installation and the configuration of the app, the execution system used for field device apps needs to provide the ability to execute software cyclically and event based with real-time requirements. Otherwise, the execution system could not be used to provide field device functionality that is tightly coupled to the industrial process. selected. The hardware setup consists of 5 central elements: (i) The pneumatic cylinder. (ii) Two binary pressure control actuators, one is used to open the cylinder, the other one is used to close the cylinder. (iii) The actuators are connected to the IO system through a digital terminal block. (iv) This IO system is used to provide the field device data for the app that is executed on the PC. (v) A pressure adjustment valve refines the pressure that drives the cylinder. The future field device, for which apps are developed, is represented through the combination of IO system and the RT-Linux PC. III. PROOF OF CONCEPT DEMONSTRATION To complement the concept, a proof of concept demonstrator has been developed that was used to gain first practical insights about central functionalities of the field device app concept like app distribution, execution and device commissioning. Two application scenarios are analyzed using this demonstrator to determine whether the field device app concept is able to provide the stated benefits. Pressure Adjustment Valve Pneumatic Cylinder ETH A. Field device demonstrator The demonstrator has been developed for a first functional evaluation of the app concept for field devices. In Figure 2, the structure of this demonstrator is depicted in an abstract way: A PC is used as a platform. The PC provides a built-in Profinet interface card that supports communication with sensors and actuators, which are connected to an IO system. The data from the sensors and actuators is collected every 4 ms. Once the data is collected, the app is executed. As software execution platform, an Ubuntu Linux distribution with real-time patches is used. It supports the execution of the field device app with temporal requirements. The CDP is represented through a software repository, which is accessed by a Linux packet management system through an Ethernet connection of the PC. Fig. 2. Value 1 Value N App1: Control Device Field Device Demonstrator ETH Real Time Linux PC Packet Management... App 2: Enhanced Device Control Field Device Data t Field Bus IF Structure of the field device demonstrator App repository s Field Bus Connection IO System Sensors In Figure 3, the actual field device hardware setup is depicted. For the demonstration, a pneumatic cylinder has been Fig. 3. Binary Pressure Control (open/close) Air pressure tube Electrical control connection The field device hardware setup B. Application scenarios IO System Profinet RT Linux App Future field device boundaries The shown demonstrator setup was used to analyze the app concept in the following two application scenarios: 1) Scenario 1: Providing field device functionality through an app: In this case, the customer demands a control application for a pneumatic cylinder. In order to use the demanded functionality, two steps are needed: (1) The customer searches for the app in the CDP and installs it with 1-click mechanism. (2) The app is executed on the execution platform to control the device. Step1 - Find and install the app: In order to find the application, the customer uses the graphical user interface of the package management tool to search for the appropriate application on a CDP, which in this case is a package repository server. The app SimpleCylinderControl is selected from the search results and installed through the integrated installation process of Linux. Through 1-click installation, no further user interaction, expert knowledge about the OS or any programming language is needed. Furthermore, the mapping between app interfaces and device hardware is done at commissioning time through manually configured start parameters. Step2 - Execute the application and use the field device: In the second step, the user executes the application to control

4 the field device. Through the installed app SimpleCylinder- Control, the customer is able to control, i.e. open and close, the pneumatic cylinder through the pressure control actuator (cf. Figure 3) via a simple user interface, similar to the one shown in Figure 4. 2) Scenario 2: Enhancing a device with additional functionality through an app: In this scenario, the functionality of a field device is extended in order to detect a sporadic device failure. In this scenario, the cylinder does not open properly. In practical terms, this could lead to a degraded product quality. The customer adapts the device by the following two steps: Step1 - Device Reconfiguration: In this first step, two proximity sensors are mounted on the pneumatic cylinder and connected to the IO system through digital IO ports. After that, customer search for an appropriate application in the distribution system, where they are able to find the EnhancedCylinderControl application. This application is able to control the pneumatic cylinder and additionally evaluates proximity sensors, in order to detect whether the cylinder has been opened or closed properly. Step2 - Usage of the enhanced functionality: Once the app has been installed and the mapping between device hardware and app has been done, the user will be able to control the pneumatic cylinder through a graphical user interface, which additionally provides the health status of the device. As the enhanced control applications detect the device failure, i.e. the open command has been issued. As the proximity sensor does not detect that the cylinder is opened, the user is informed about the device failure through the user interface as depicted in Figure 4. Fig. 4. Enhanced cylinder control user interface In the above scenario, the sensors and actuators do not provide own processing power and therefore cannot provide information about their device type or status. Any mapping algorithm that creates the connection between the app and the device hardware would at least need the information that which device type is connected to which hardware port. Thus, an additional mechanism would need to be developed that allows simple sensors and actuators without own processing power to identify themselves. Alternatively, a semi-automatic approach could be used, in which the operator provides the information about the actual hardware configuration. It needs to be stated that within both scenarios, the mapping between application and field device hardware is done through a manual setup of start parameters by the technician during device commissioning. As already pointed out, hardware access through an entirely automated mapping between application and field device hardware is beneficial, but needs further development. IV. CONCLUSION In this paper, a field device app concept was introduced and analyzed, which has been adapted from the smart device industry. The analysis has been focused to determine whether the field device app concept could be used as an enabling technology, to allow for software based reconfiguration of field devices and therefore improving automation systems to evolve during their life-cycle. It has been shown that the field device app concept is potentially able to act as enabling technology to provide software based field device functionality. The proposed manual approach used in this work provides the benefit that the app does not have to be entirely rebuilt to support a variable field device hardware structure. This benefit of reconfigurability was achieved by providing the option of mapping between app and device hardware during device commissioning. In future work, the demonstrator will be extended in order to be used in more complex scenarios for further analysis. This analysis will provide basis for discussion with potential platform vendors and customers, to determine that up to which extent apps are able to reflect the specific requirements of automations systems and which application scenarios apps might not be suitable. Furthermore, future work will evaluate the integration of app-based software distribution for module level control logic into the proposed architecture for reconfigurable real-time automation systems as published in [9]. REFERENCES [1] V. Vyatkin, Software engineering in industrial automation: State-of-theart review, Industrial Informatics, IEEE Transactions on, vol. 9, no. 3, pp , [2] P. Salz and J. Moranz, The Everything Guide to Mobile Apps: A Practical Guide to Affordable Mobile App Development for Your Business. Adams Media, [3] J. McWherter and S. Gowell, Professional Mobile Application Development. Wiley, [4] F. M. for Economic Affairs and Engery, Marion project - Mobile autonome, kooperative Roboter in komplexen Wertschöpfungsketten (in German), [Accessed 12-March- 2014]. [5] Y. Koren, General RMS characteristics. comparison with dedicated and flexible systems, in Reconfigurable Manufacturing Systems and Transformable Factories, A. Dashchenko, Ed. Springer Berlin Heidelberg, 2006, pp [6] F. Cuadrado and J. Dueas, Mobile application stores: success factors, existing approaches, and future developments, Communications Magazine, IEEE, vol. 50, no. 11, pp , [7] Android, Developer resources, , [Accessed 11-March-2014]. [8] FDI-Cooperation, Field device integration - official website, http: // [Accessed 12-March-2014]. [9] L. Dürkop, H. Trsek, J. Otto, and J. Jasperneite, A field level architecture for reconfigurable real-time automation systems, in 10th IEEE Workshop on Factory Communication Systems, Toulouse, May 2014.

5 Year: 2014 Author(s): Gilani, Syed Shiraz; Tack, Tim; Flatt, Holger; Jasperneite, Jürgen Title: An app-based approach for reconfigurable field devices DOI: /ETFA ( IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE. Details: Institute of Electrical and Electronics Engineers -IEEE-: ETFA 2014, 19th IEEE International Conference on Emerging Technologies and Factory Automation : September 2014, Barcelona, Spain Piscataway, NJ: IEEE, 2014 ISBN: ISBN: pp.