PLCs as Industry 4.0 Components in Laboratory Applications

—This paper focuses in three main subjects; the first one and the most important is the presentations and implementation of a concept to use an standard PLC as an Industry 4.0 (I40) component following the specification defined by the Industry 4.0 architecture RAMI 4.0. With this realization those industrial controllers can be easily integrated in Industry 4.0 production environments using the service paradigm. The next subject of this work involves some tests to evaluate the developed concept based on a prototype implementation. As result, the transmission time for the process data from the PLC to the IP network was determined for two use cases. The last part of the paper presents a practical implementation using a laboratory installation intendent to educational applications. With the PLC as an I40 component, process data can be transferred directly from the controller to an IP network without additional delays. The achieved result forms, amongst other things, the basis for outsourcing parts of the control program to a cloud. The prototype applications are available for learning and training purposes.


INTRODUCTION
Industrial controls and, in particular, PLC controllers currently form an important technological basis for the automation of industrial processes. Even in the age of Industry 4.0 (I40) and Industrial Internet, it can be assumed that these controllers will continue to be required to a considerable extent for the production of tomorrow. However, the controllers must fulfil a range of additional requirements resulting from the new production conditions.
When applying Industry 4.0 principles [1], high-quality networked production systems result based on Cyber Physical Systems (CPS), also referred to as Cyber Physical Production Systems (CPPS). A series of I40 requirements are placed on the future controllers used in these systems. These include: a. Autonomy, re-configurability and agility (Plug&Work); b. Overcoming the strict information encapsulation of controllers; c. Introduction of the service paradigm in the production automation (production services); d. Networking in local and global networks; e. Interoperability between heterogeneous control systems; f. Dependencies are to be changeable dynamically to the runtime; g. Use of models for the development of "higherquality" control approaches; h. Orchestration of heterogeneous controllers.
Current PLC controllers cannot yet fulfil the majority of these requirements or can only do so on a rudimentary basis or with extremely high expense.
One of the basic requirements of future and I40-able PLC controllers involves efficient networking in an, at least partially, global network. Here the IP network (IP -Internet Protocol) functions as a global network in the version as Intranet or Internet with all associated standardized Information and Communication (IC) technologies. Only in this way can the required integration become part of a future I40 production landscape. This paper will concentrate on the basic requirement of the global networking and describe the concept and a prototype implementation for a PLC controller as I40 component. Additionally some laboratory implementations are presented with the purpose to support learning and training related to Industry 4.0.

II. STATE-OF-THE-ART
Resulting from the historical development of PLC controllers, these have been developed as proprietary device systems that are operated locally under real-time conditions. If a networking of these controllers is necessary from a user viewpoint, proprietary TCP/IP protocols or those standardized in the automation sector (Modbus TCP, Profinet etc.) are used for this. The standard technologies widespread from the Internet and Web have so far played hardly any role for PLC controllers.
For a number of years, however, a transformation has been under way, with PLC manufacturers increasingly integrating IC technologies from the web world in their systems, such as web server and HTML pages for diagnosis and configuration, in order to adapt the controllers incrementally to the new requirements.
Three different approaches to make PLC controllers I40 compatible can essentially be revealed from the state-of the-art. These include the introduction of basic web technologies, the global networking of process data and the introduction of service principles.

A. Introduction of basic web technologies
Most of the newer PLC controllers already contain a web server as well as special HTML pages on the device, these enabling a browser-based configuration and diagnosis of the controller. Process data or program variables form the control program and can also be read, and sometimes also written, with restrictions. Access via a web PAPER PLCS AS INDUSTRY 4.0 COMPONENTS IN LABORATORY APPLICATIONS browser is via the HTTP protocol and is hence querybased and relatively slow. Examples of this can be found in [2]. The solutions are proprietary and adapted to the relevant controller. Open and consistent web interfaces are not available. The above I40 requirements cannot therefore be fulfilled.

B. Global networking of process data
For integration of the PLC controllers in supervisor, management and coordination systems (e.g. SCADA or MES systems), which are partly based on web technologies, additional modules are integrated in the PLC controllers, these enabling a bidirectional and event-based process data transmission between the controller and supervisor & management system. This includes, for example, solutions such as the use of Java-Applets on websites for access to Siemens controllers [3], the Web connector with MQTT broker in Bosch-Rexroth controllers [4] or also browser-based access to controllers that already contain an OPC UA server [5].
These solutions also involve proprietary and closed control-integrated modules. Although the modules utilize web technologies, they cannot be transferred to other controllers. The global process data communication is used for HMIs (HMI -Human Machine Interface) and/or supervisor & coordination functions in the higher level of the automation hierarchy (e.g. plant management level). Authoritative statements regarding the time response of the process data transmission are not available. However, different statements result from the latency times greater than 100 to 300 milliseconds. Open and consistent web interfaces are not available. The above I40 requirements can only partly be fulfilled with sometimes high adaptation expense for integration in a CPPS.

C. Introduction of service principles
Based on the I40 requirement for the service capability of an I40 controller, some projects [6,7] are involved with the integration of service functions in PLC controllers. Thus the Device Protocol for Web Services (DPWS) enables, as standardized protocol, service-based access to PLC controllers [8] etc. also for reading/writing process data. The internal functional system of a PLC is to be equipped correspondingly for this with the support of the controller manufacturer.
An option for implementation of the DPSW independently of the manufacturer of a PLC is shown in [9]. A service server is implemented here as a functional module based on the standard IEC 61131-3 programming language. This can then be used for the control programming.
However, the DPWS solutions have a principle disadvantage: Instead of reducing or removing the information encapsulation (I40 requirement), further functionalities (service functions) are encapsulated in the controller. Although the service paradigm can consequently be implemented, it significantly encumbers the implementation of other I40 requirements (e.g. Plug&Work, change of dependencies on the runtime). Moreover, DPSW uses the very heavy-duty and complex Microsoft web service protocols. The attainable transmission times of process data via a global network therefore tend to be in the upper range (here too, hardly any definitive statements are available).
In summary, it is to be estimated that there are various solutions and endeavours to provide PLC controllers with additional functions in order to network the controllers in an IP network as defined by Industry 4.0. However, there are considerable deficits in respect to the global networking in particular.
• The process data communication between the controller as a device and a global web functional landscape is slow. Effective statements regarding transmission times and for guaranteeing their quality are not available. • However, the controllers do not have any web interfaces or, if they do so, such interfaces are inadequately disclosed. • Available I40 models and architectures have not yet been considered. • Tools for the migration of classical PLC controllers to the new CPS-based production environment corresponding to Industry 4.0 are practically non-existent.

D. Learning and training with the IoT and I40
There is big growing community of innovators, engineers, leaders, etc working and researching in IoT and I40. Furthermore, there is a much bigger and also increasing community including dreamers interested on learning, practice and doing with such technologies. In the literature it is possible to find out hundreds of papers, reports, technical notes, product, just comments, etc involving studies, developments, applications, etc referring to this topics. It is also not clear for non-specialized people getting frequently confused with concepts like IoT or a near one Internet of Everything (IoE) and the I40 or even the Industrial internet of things [18]. As a consequence, special attention must be drawn to such concepts and particularly to its practices in engineering and technical schools. Especially I40 represents a high level of interdisciplinary interaction between IT, automation and communication requiring flexibility and excellence from the specialists. Therefore, professors, teachers and laboratories must be very well prepared regarding to that technology representing a challenge in the future engineering education. In opinion of the authors any remote labs can be created, operated and utilized simply and quickly via web-based engineering [19].
The existence of laboratories to teach or training students on such technologies is nowadays quite limited and usually based on proprietary systems. However some interesting realizations can be found in the literatures that are close to such technologies. A novel approach in hardware and software architecture for implementation of remote laboratories for automatic control is presented in [20]. Here, the physical setup and communication principles of hardware architecture are based on two types of devices: the programmable logic controllers and industrial network routers; the user interface of client application is designed as a Web page, powered by optimized JavaScript, using the sophisticated on-the-fly content generation. An educational experience presented as a Cyber-Physical Systems (CPS) challenge develops an Androidbased remote control system for tele-operating an educative mobile robot in [21]. The design and implementation of an innovative IoT experimental platform using gateways and wireless network technologies is presented in [22]. Other interesting research that can contribute to have more online laboratories is described in [23] and [24].

PAPER PLCS AS INDUSTRY 4.0 COMPONENTS IN LABORATORY APPLICATIONS
Security is also another important issue related to those subjects. Many companies still rely on management and production systems that are unconnected or closed. With the increased connectivity and use of standard communications protocols that come with Industry 4.0, the need to protect critical industrial systems and manufacturing lines from cyber security threats increases dramatically. As a result, secure, reliable communications as well as sophisticated identity and access management of machines and users are essential [24]. Reference [26] is a good approach as an introduction on such concept and specific examples to improve security are given in [27] and [28].

III. CONCEPT [17]
A. Basic model Initial architecture and reference models have been available for the new CPS-based production structures since 2015. The Reference Architectural Model Industry 4.0 (RAMI 4.0) was developed in Germany and published in April 2015 by the ZVEI [10]. Two months later, the Industrial Internet Reference Architecture (IIRA) was published by the US organization IIC (Industrial Internet Consortium) [11].
Both architecture models deal comprehensively with the future production process, to some extent from different viewpoints, but essentially remain very general and provide only limited information in respect to a practical implementation. RAMI 4.0 forms an exception in respect to the question of which structure an I40 component should actually exhibit.   Fig. 1 provides an initial basis that is to be outlined further below.

B. Device
The physical object (device) or the object of the information world (virtual object) is only considered generally in the RAMI model. A suitable connection to the IP network is presupposed without further discussion. However, this results in the problem that a normal PLC is only provided with a corresponding web-compatible interface to an inadequate extent. A Device Gateway is therefore introduced, which must be able to provide the process data of the PLC controller in the IP network and hence in the web world, rapidly, reliably and securely. The device gateway should be set up so that it can also be integrated in existing PLC controllers without intervention and, if possible, without additional device-technical expense. A "lean" and web-compatible protocol is required for communication with the IP network.

C. Management shell
According to RAMI 4.0, the management shell has the following features, amongst others: e) It manages the information belonging to the object in the system environment.
f) The management is coherent and consistent in this system environment.
g) It has precisely one resource manager.
The management shell is located outside the controller in the information world of the Internet/Web and must therefore also utilize the corresponding technologies from this environment in order to be able to establish a connection with web services, clouds and other objects in the Industrial Internet of Things. In relation to a PLC controller as a device, a Service Shell is defined as a functional interface with a management data set, which can be used in the above automation-technical context in a consistent manner (if possible for all devices, not only PLC controllers). As a giving system environment is assumed for the present solution, the further RAMI property of various management shells does not have to be considered. But also other management shells res. service shells for different system environments are possible (if required).

D. Resource manager
The following RAMI properties of the resource manager are of particular interest in relation to a PLC controller as I40 component.
h) It organizes the data exchange with the device in online mode.
i) It organizes the internal information management.
According to the authors of this paper, the resource manager must also establish a virtual mapping of the device in the selected system environment (Internet/Web) so that it can communicate with other IT objects in the IT world via the service shell. The resource manager is therefore modelled as a Virtual Device (VD) for the present solution.
The further RAMI properties of the resource manager such as participants in an I40 service system and organization of the external access to information in the management shell should preferably be assigned to the management shell, in the opinion of the authors.
Based on the above versions, the structure outlined in Fig. 2 is derived for the model of a PLC controller as an I40 component. The communication between the virtual device and device gateway is realized for initialization and parameterization via the HTTP protocol. The websocket protocol is used for rapid bidirectional process data transmission. The pragmatic and "lean" WOAS Device Protocol developed in the WOAS project (WOAS = Web-Oriented Automation System) [13] and based on JSON functions is used as an application protocol. In a next version also UBJSON (Universal Binary JSON) will be tested as the data transmission protocol in order to reduce more the roundtrip time.
The data set (or multiple data sets) integrated in the service shell contain requisite parameterization and management information for the I40 component. These data sets can be an element of the I40 component itself or outsourced to an external database (e.g. in a cloud).

A. Device gateway
In line with the specifications for the present concept, the internal structure of the PLC controller is not to be changed, nor is additional device technology such as industrial PCs or specific gateway hardware to be added to the controller.
As a result, only the IEC61131-3 control program itself remains as an implementation environment, i.e. a device gateway was implemented as a prototype by means of the IEC61131-3. This device gateway can be executed for the runtime as a functional module together with the PLC control program. Fig. 3 shows the prototype implementation for the device gateway as an FBD program (FBD -Function Block Diagram). The device gateway is integrated as a library with the three functional modules shown in Fig. 3 for the PLC programming and can then be used in the PLC program.
Three problems were to be solved for the implementa-  Problem 2 was solved by integrating a primitive HTTP web server as a functional module in the device gateway. The web client thus communicates its IP address to the device gateway by means of an HTTP request, which the WS server can then use. An embedded web server that might be present in the PLC cannot generally be used, as this is normally already reserved in the PLC for diagnostic and/or parameterization purposes.
A solution to Problem 3 turned out to be relatively simple, as the standard functional modules available under FBD can be used without any problem for the required protocol conversion.
The HTTP server, the WS server and the protocol conversion are realized jointly in the function block (FB) I40_PLC. Two additional FBs are required for the reading and writing connection of the WS server, via which the interconnection with the process variables in the PLC program occurs. The PLC can then provide these process variables in the IP network. This is realized in the two FBs IOs_To_StrI40 and StrI40_To_Ios. The amount of process data to be provided was limited in the prototype for these two FBs. However, both FBs can also be replaced by customer-specific and extended FBs, if required.

B. Service Shell
The service shell realizes the management shell provided for an I40 component according to the RAMI 4.0 concept. It is responsible for integration of the PLC controller in the information world of the Internet/Web. At the same time, the service shell therefore also forms the web interface in order to be able to interact with the PLC in regard to its process data.

PAPER PLCS AS INDUSTRY 4.0 COMPONENTS IN LABORATORY APPLICATIONS
The service shell manages the relevant instances for the PLC controllers with concrete connection to the system via corresponding parameterized data sets.
The service shell provides a simple and pragmatic set of JavaScript methods for the web client, these serving as a client-end function interface for the PLC controller. Table 1 lists the most important methods for communication between a web client and the PLC as an I40 component.

C. Virtual device
The virtual device realizes the resource manager of the I40 component as defined by RAMI 4.0. This involves a JavaScript object that forms a virtual image of the automation device in the Internet/Web world, while communicating via the HTTP or WS protocol. The structure and setup of such a virtual device are described in detail in [14]. Fig. 4 shows the general data model of a virtual device.
Each virtual device consists of a general data as well as specific data. The general data is specified by the manufacturer of the virtual device. The general data characterizes the virtual device class here. The specific data characterizes the virtual device instance for a concrete PLC and is generated and parameterized by a user with the role Admin.
A "lean" and flexible device model is required for the I40 component for the rapid and reliable transmission of process data. Familiar device models from automation technology (GSD, FDT/DTM, EDS, FDI etc) are optimized for engineering purposes and less suitable for a runtime operation via IP networks owing to their complexity and large scale. The VD device model therefore uses a simple input/output channel concept (comparable with the port concept from AutomationML) in order to provide process data in a uniform manner for automation services. Each channel has defined parameters and can be extended as required via options (e.g. with a semantic description) A virtual device can have any number of channels.

A. Demonstration example
A PLC controller ILC-150 ETH with the programming tool PC WORX from Phoenix Contact is currently used as a demonstration example for the PLC as I40 component. The PLC is integrated in a starter kit with several digital and analog input and output signals as well as peripheral devices (switches, potentiometer, LEDs etc.) as shown in Fig. 6. An example program for operation/ visualization of the periphery runs on the PLC.

B. Time characteristics
Extensive time measurements were conducted for the PLC as an I40 component using the same demonstration example.
For the client-end determination of the time response, an HTML page generates a pulse frequency that is sent to an output of the PLC. This output is connected via hardware with a PLC input, which feeds its value back to the HTML page. A time difference measurement and logging in a histogram then occurs. This measuring method provides the time characteristics of the bidirectional process data transmission over a longer time period and also logs isReady This function is called up by the VD if the VD is ready for process data transmission to the real device.
readChannel Asynchronous reading of a process date.
writeChannel Asynchronous writing of a process date.
subscribe Subscription of the VD process data for the event-based transmission.
unsubscribe Stopping the event-based transmission of process data.
refreshChannelData Listing function; called up by the VD object if the value of a subscribed process date is changed.
getProfilData Reading out a VD profile file (if such a file is available)  The PLC was located in the Düsseldorf University of Applied Sciences in both cases.
In the Internet, an average transmission time for the unidirectional transmission of a process datum of 25 milliseconds resulted when using the I40 component (15 milliseconds in the Intranet). The following approximation can be assumed as a guide value for the transmission time: A similar measurement with a web connector, which works with an OPC DA server as access to the PLC, yielded 40 milliseconds for the average transmission time of the unidirectional transmission of a process datum [15]. The essentially higher transmission time results from the internal delay time of the OPC server here.
A significant improvement to the time response in the IP network is attained by using the I40 component and direct access to the PLC without OPC server as presented by the study in [29].

C. Service integration
An important target from RAMI 4.0 and Industry 4.0 is the application of the service paradigm to automation functions. Realization of the PLC controller as an I40 component provides a uniform interface in the Internet/Web world with the service shell, this able to be used as a service interface.

VI. LABORATORY APPLICATIONS
With the objective to spread the use of the developed concept and implementation and also provide a proper online place to test I40, an existing laboratory installation was upgraded with this technology and included in the above mentioned WOAS portal. Fig. 7 in its top left part shows a photo of the laboratory installation used. It is a miniature production line with 4 montage stations in an automotive process. Each station has some stoppers, a gripper to mount or dismount a specific car component and some indicators, as in the photo in Fig. 7 top right part. The route path between the stations is a conveyor that transports the required parts cyclically from one to the next.
In the bottom part of Fig. 7 are two sections of the workspace created in the web site to control the station 3 as a specific example. An additional diagnostic/ test page that can be acceded from a mobile device was also developed.
An additional approach of this laboratory installation and WOAS is the implementation of a Big Data automation service which can be used to store real time process data from systems/ machines in a cloud [30]. An available and open implementation to do and practice is the CPS Integration Platform WOAS (http://woas.ccad.eu), see Fig.8. The WOAS portal [13] is a multi-client-enabled and role-based web portal, which can be used to connect services and devices to and among one another. On the client side (browser) the platform is completely implemented in HTML5 and JavaScript. No any PlugIn is required and the system is runnable in each existing browser and device.
In principle, every PLC can be integrated in this portal as an I40 component when using the described device gateway. Together with other automation services (operating services, visualization services etc.) requisite functional systems (SCADA and HMI systems, remote labs etc.) can easily be created and utilized in the web browser without additional software complexity.
Additionally, the complete software for the PLC as an I40 component including the documentation and example implementations are available free of charge for downloading and non-commercial use. The WOAS platform itself as well as some other remote laboratories are provided via a cloud server in the Düsseldorf Telelaboratory.
The PLC used in the demonstration example is currently integrated in the WOAS portal as an I40 component and a publicly accessible website is available for test purposes.

VIII. CONCLUSION AND FURTHER WORKS
The present work develops a concept to use an industrial controller (PLC) as an I40 component. The most remarkable advantage is that with this component the PLCs can be seamlessly integrating in Industry 4.0 product environments using the service paradigm. As a direct result, existing conventional PLC systems can be also integrated in a new CPS-based Industry 4.0 automation without any changes, just include the available library in the user program.
The created concept was tested and evaluated within the framework of a prototypical implementation with Phoenix Contact controllers and the programming tool PC WORX. This resulted in a fastest transmission of process data from a PLC in an IP network.
The use of the I40 component with the WOAS portal and the laboratory applications created shown the flexibil-ity of the complete system as a CPS test and training platform.
The extension as an I40 component for controllers from other manufacturers will be examined in the next step. This will include software controllers with CoDeSys as runtime system as well as standard Siemens PLCs.
As part of the R&D project "Cloud-based Industrial Control Services -CICS" [16], the use of PLC controllers as an I40 component is also envisaged, in order to outsource non-time-critical parts of control programs in a cloud as services and enable these to execute in the cloud itself and/or on a web client in a runtime machine.