Enhancing Device Exchange Agility in Service-oriented ... - IEEE Xplore

Enhancing Device Exchange Agility in Service-oriented Industrial Automation Gonc¸alo Cˆandido∗ , Carlos Sousa∗ , Giovanni Di Orio∗ , Jos´e Barata∗ , Armando W. Colombo† ∗ CTS

– UNINOVA, Dep. de Eng. Electrot´ecnica, FCT–UNL, 2829-516 Caparica, Portugal Emails: [email protected], [email protected], [email protected], [email protected] † Schneider Electric Automation GmbH, Germany and University of Applied Sciences Emden-Leer, Depart. of Technology, Constantiaplatz 4, D-26723 Emden, Germany Email: [email protected]

Abstract—The industrial automation domain is known for its plethora of heterogeneous equipment encompassing distinct functions, form factors, network interfaces and I/O specifications supported by dissimilar software and hardware platforms. There is then an evident and crescent need to take every device into account and improve the agility performance when handling device breakdowns or lifecycle modifications. Emerging from higher level IT domain, Service-oriented Architecture (SOA) paradigm is currently a widely endorsed approach for both business and enterprise systems integration. SOA promotes discoverability, loose coupling, abstraction, autonomy and composition of services relying on open web standards – features that can provide an important contribution to the industrial automation domain. The present work implements a SOA-based infrastructure comprising Semantic Web concepts to enhance the process of exchanging a device in an industrial automation environment by assisting (and even automate) this task supported by service and device semantic matching whenever a device breaks down or needs to be replaced. The infrastructure was implemented and tested in an educational shop floor setup composed by a set of distributed entities each one managed and controlled by its own SOA-ready PLC. The performed tests revealed that the tasks of discovering and identifying new devices, as well as providing assistance when a device is down or disconnected offered a valuable contribution and it can increase the agility of the overall system when dealing with operation disruptions or modifications at device level.

I. I NTRODUCTION A. Background and Motivation The world of embedded computing in industrial automation is characterized by a high degree of diversity in device functionality, form factor, network protocols, input/output features, as well as for the presence of several unlike hardware and software platforms. Along the years several initiatives and approaches have helped steering the progress and provide guidelines and solutions for the upcoming deployments supported by previous advances. Interoperability tends to be considered simply as a technical issue and its real implications are sometimes underrated. As referred in [1], interoperability consists in exchanging information between two systems and to use the information that has been exchanged despite the differences in language, interface or execution platform. Nevertheless, it is more dependent from semantics more than over a simple software or hardware compability [2]. Semantic interoperability emerged as the

capability of automatically interpret the exchanged information precisely in systems [3]. It is not sufficient to state that agility, alongside interoperability, corresponds to being flexible or lean since the concept extends more than that. Firstly, flexibility refers to an enterprise that can easily adapt itself to produce a range of planned products. Secondly but differently, lean essentially means producing without superfluous waste, reconfigurability denotes an ability to tackle uncertainty by relying on reconfigurable modules that can be composed to adapt to a new unpredictable situation [4]. Thus, an agile company must be able to adjust as quickly as possible in order to respond to the demands of globalization, environmental and working conditions regulation and improved standards for quality. Only if the lower level entity cannot accomplish the wanted agility target, will the overall system be incapable of delivering the desired performance. That is to say, in a complete system, its agility is always set back by its least agile element. Overall company agility is mainly supported by the device level in industrial automation, since a device is the last border where higher level process requirements, guidelines and workflows are turned into a structured collection of physical actions and services. With the progressive evolution of the technology and availability of development platforms new options become available to deploy innovative solutions that can support the deployment of features and functionalities previously unconceivable for the industrial automation. In this direction, the systems integration community demands for new tools and services to assist his daily work and reduce the effort, cost and delay of lifecycle (re)engineering interventions. B. Service-oriented Architecture Firstly referred in [5], Service-oriented Architecture (SOA) paradigm has emerged and rapidly grown as a standard solution for publishing and accessing information in an increasingly Internet-ubiquitous world. This new approach defined standard interfaces and protocols that allow developers to encapsulate functions and tools as services that clients can access without knowledge or control over their concrete implementation [6]. SOA establishes an architectural model that aims to enhance the efficiency, interoperability, agility, and

productivity of an enterprise by positioning services as the primary means through which solution logic is represented in support of the realization of strategic goals [7]. The increasingly interest in SOA has been stimulated by an influential industry trend: Web Services technology [8]. Although Web Services do not necessarily translate to SOA, and not every SOA is based on Web Services, these last ones recognition are helping to bring SOA to a wider audience, while SOA concepts and principles will contribute to more successful web services initiatives [9]. As for other domains, service-oriented approaches are now entering the industrial automation domain in a top-down way as introduced by [10]. Its application at device level has a direct impact on how industrial automation applications will be designed and developed. A complete industrial automation application comprises a smooth integration and alignment between complex high level management layers and field level automation control. This way, the task of managing the system along its lifecycle becomes simplified by only having to handle more abstract and complex information encapsulated under a standard open interface instead of device low-level intricacies. There is then a crescent tendency to push higher level IT approaches and technology into automation devices as depicted in the work from several authors such as [11], [12], [13], [14], [15]. In fact it is a natural path from traditional logic based control into state-of-the-art IT technology and integration platforms. Semantic Web is an envisaged Internet evolution in which the meaning of online information and services is clearly defined, making it possible for the web itself understand and satisfy the requests of all to exploit it [16]. Based on previous premises, the concept of semantic web services was born as complement to traditional web services technologies, as presented in [17]. Semantic web solutions such as ontologies and logic-based reasoning engines are considered agile factors to enhance enterprise integration tasks and can be extended to device level reengineering assistance and possible automation. The current work addresses this theme by presenting a reference test bench for a set of procedures and tools that allow a systems integrator to perform a SOA-capable device exchange in a more effortless and natural manner by implicitly employing semantic web techniques and transparent interoperability. II. SOA L IFECYCLE S UPPORT I NFRASTRUCTURE The present article addresses part of the test and validation of the SOA lifecycle support architecture proposed in [18]. In general terms, as depicted in Fig. 1 the followed infrastructure defines elements and methodologies to increase devices interoperability and agility performance at device level in a service-oriented industrial automation context. Device interoperability and subsequent overall system agility can be enhanced through the employment of semantic techniques on top of a collection of devices operating in a service-oriented industrial environment able to discover, recognize and process available information to assist or automate certain integration

or reengineering tasks. In this setting, the systems integrator is assisted by a distributed collection of intelligent entities and tools to complete his assignments in a more agile manner.

Fig. 1.

Service-oriented device lifecycle support infrastructure [18]

In this context, a service is a software component that encapsulates a function or behaviour under its interface following SOA principles of design and technology. It can be discovered and exploited by other network entity in order to execute a particular task or to retrieve some kind of information. A device, or more specifically a logical device, represents the entity that abstracts an application element, while its hosted services embody the functionalities that it allows others to exploit. A service-oriented application is the result of composing several resources that cooperate between them exploiting the services each one offer in a coordinated routine. The control configuration is not strictly predefined and can be constructed based on available building blocks – logical devices and services, all hosted in physical devices such as a PLC or a industrial PC. In a holistic overview, the application will emerge from the composition of simpler modules to progressively create more complex structures and behaviours. Previous articles [19], [20] already addressed other aspects and components of this same reference architecture. The present work puts then the focus on the following resources: 1) Device Explorer: This element is a software component mostly employed for analysis, setup and troubleshooting of a service-oriented application and its constituent devices and services. It comprises a perceptive GUI (Graphical User Interface) that allows the integrator to discover available devices and services in the network, check their status, visualize metadata, test available services, etc. Features such as the retrieval of current devices topology, deployment of semantic translation solutions, access to the Semantic Assistant to easily identify devices and improve posterior interactions. 2) Semantic Assistant: This element does not only support the execution of semantic reasoning tasks based on the current state of the system ontology, but also exposes these functionalities in the network as services. These services can include the semantic identification of devices and services,

retrieval of generic services for a range of devices, mapping of features and services, service translation and mapping, etc. It can be configured to accordingly behave with different levels of autonomy depending on the system critical factor set by the systems integrator. As a first step, the semantic input must be kept in the scope of systems integrator assistance. Then, regarding run-time performance and results, it can be envisaged to gradually automate certain common tasks to avoid constant need of human intervention. 3) Process Management Tools: For every industrial automation installation there is a need to define the set of processes to be executed by the system during run-time or for atypical situations. In the context of a service-oriented application, a process consists of a flow of invocations of services or events handlers provided by the available shop floor devices in a predefined way to execute predetermined production tasks. This element is responsible for creating and managing these processes supported by a GUI that enables a visual composition of resources and their interaction patterns to create these processes. III. MOFA S HOP F LOOR C ELL APPLICATION A. Installation The MOFA kit by Staudinger GmbH simulates a flexible manufacturing system as a closed loop manufacturing circuit, achieving various possible situations based on generic manufacturing tasks (see Fig. 2). Staudinger models replicate complex industrial projects in close-to-reality details. This educational kit is composed by four machines, a buffer area, a crane robot, local transporters (conveyors or tables) and sensors to detect pallet positions. As verified in [21], this platform proved to be extremely useful for testing purposes since a lot of effort can be saved if an educational platform is used assuming that the key aspects of a real industrial environment are taken into account, such as real-time and reliability, resources concurrency, mechanical and electrical relations, etc. Of particular relevance is the easier addition and removal of physical modules and control equipment.

(a) MOFA main components Fig. 2.

(b) Photo of MOFA kit

MOFA shop floor cell overview

The original control equipment that included a legacy data acquisition board installed in a PC that allowed the access to the kit I/O using a C++ API was replaced by a new control solution composed by a distributed collection of Inico S1000 modules. The Inico S1000 is a smart Remote Terminal Unit (RTU) capable of real-time control, field data processing, webbased monitoring and integration running on a 32-bit CPU running at 55 MHz and 8 MB of available flash memory with a 10/100 Mbit Ethernet port, 8 digital inputs and 8 digital outputs. Besides handling typical I/O control using IEC611313 Structured Text language possibly of being programmed using any regular web browser due to its embedded web server, it also implements a XML/SOAP interface based on Devices Profile for Web Services (DPWS) standard [22] to ease up the integration of industrial processes in a SOA context. For PC-side implementations the DPWS JMEDs stack from [23] and OWL-S API from OSIRIS Next [24] were also used. B. Device Explorer As referred before this element is a software component mostly used during analysis, setup and troubleshooting of a service-oriented application. It comprises a perceptive GUI that allows the integrator to search the network for available devices and services, check their status, visualize metadata, or test available services. 1) Logical topology of Devices: The Device Explorer supports a network broadcast discovery exploiting the WSDiscovery standard embedded in the DPWS stack. This enables system integrators to check for devices and services currently available. It will collect and present the list of devices found and their hosted services, along with each according metadata to the systems integrator (top section of Fig. 3). Here, moveX is an operation and reachedX is an event source supported by the moveAxisX service hosted by the device AxisX which is responsible for controlling the movement on the x axis of the crane. In this view, all devices are presented at the same level since they are all connected to the same network in a flat layout. By embedding this kind of distributed discovery mechanism into each device, this simple feature already represents a major input to enhance device out-ofthe-box connectivity and setup – one of the biggest known customer demands. During this process there is no need to connect to each device independently using always a different protocol and connector to check its status and configure it. Each device friendlyName is itself a sematic tag in Uniform Resource Identifier (URI) format that will indubitably identify that device in the context of the current service-oriented application. Based on this simple solution, it would be also possible to extract not only the physical network topology but also the logical view of the system only based on local information from devices metadata. In the current Device Explorer GUI this topology is presented by a tree-map format (bottom section of Fig. 3). Here it is possible to visualize a higher-level devices with all its sub devices; e.g. Crane device orchestrates AxisX and AxisYZ devices. This was achieved by agreeing on a common URI format – its value will determine

the logical level of each device and define its position within the current application.

Fig. 3.

Detail of network and logical devices topology in Device Explorer

2) Heartbeat monitoring: Even though the functioning of each device was seen as highly reliable, a heartbeat event was implemented in each one to increase the robustness of the architecture and the time of response to anomalies that might occur. Whenever a device goes offline for some reason, i.e. connection problems, hardware conflicts or a power surge, Device Explorer is able to update the status of the device with the information provided by the event (or by the lack of it). When Device Explorer starts to search for devices in the network, it subscribes to all events with the service named heartbeatService, having guarantees that each heartbeat event is deployed on a service with that name. This service, through a configurable time, sends a cyclic message to all subscribers warning about its current state. Hence, after subscribing to a heartbeat event, a control thread is associated to it and launched to monitor every change of the status of that particular device. This control thread activates a timer that expires after a configurable time. Evidently, this configurable time must be longer than the heartbeat service cadence. When an event is received, it refreshes its own timer. Consequently, when this timer expires it means that the device is now unreachable in the network and Device Explorer will trigger a warning message and remove the device from the list.

composition of simpler modules to progressively create more complex structures and behaviours. In this implementation the Process Management Tool is used by the system integrator to naturally create a process plan to achieve a behaviour in accordance with current system requirements and constraints (see Fig. 4). Here the user can pick the operations directly from the list of devices discovered in the network, enter the according parameters and compose them to create a sequential process plan. Each process plan is saved in a XML-based format comprising all the required information to clearly identify each service operation included in the process. When a systems integrator decides to launch a new process instance he can retrieve one previously stored or create a new one from scratch and start its execution for a particular pallet. The tool will then trigger a new generic process execution thread that will be responsible for executing and monitoring the correct execution of the actual process plan. For the time being, the focus was not put concretely on providing an advanced process management environment but on allowing the creation of some simple processes that employed services hosted by the available devices. The goal was then to verify the different approaches proposed in the following section. Future work include the use of more sophisticated service-oriented process execution solutions such as WSBPEL. D. Semantic Assistant The ability to transparently exchange one device by another that exposes the same interface and hosted services is not explicitly related with the proposed architecture itself but with the aspect of being in the context of a service-oriented application. Devices are discovered in the network by their service interfaces and metadata values, i.e. application level interaction. This way when a faulty or deprecated device needs to be replaced by a new one, this new device can be configured to expose the same interface and metadata values as the previous one. The other resources that interacted with the old device will now seamlessly convey their messages to the new device. To show the transparency in each device, an INICO PLC responsible for controlling a MOFA workstation was disconnected, powered off, and a new one exposing similar metadata and identical service interfaces was put in place.

C. Process Management Tool A service-oriented application is the result of a composition of several resources that cooperate between them exploiting the services each one offer in a coordinated routine. The control configuration is constructed based on the available building blocks – services hosted by network devices. In a holistic overview, the application will emerge from the

Fig. 4.

Example of a process plan creation

This change shows no problems or issues: the active process run as expected using these new services. When launching a production process, the Process Management tool searches over the network for all the required services and operations to validate if it is capable of executing successfully before launching it. If for some reason a device and consequently its hosted service become unavailable, the process task is able to handle an invocation error and start searching for an identical service in the network. If Device Explorer finds an identical service the process will continue as planned. When searching for an identical service, Device Explorer will execute a broadcast search looking for a service with metadata values which matches with the old service. As expected due to the intrinsic abstraction layer provided by the services interfaces and WS-Discovery peer-to-peer and IP-transparent mechanism included in DPWS middleware, a change of a device by another presenting the same interfaces revealed to be entirely straightforward as expected. 1) Semantic Matching: In a context where it is not feasible to plug a substitution device with metadata values and hosted services identical to a device that was unplugged for maintenance or inactive due to a fault, an alternative solution must be available. In these conditions the system needs to quickly adapt by assisting the systems integrator or even provide an automated resolution. After identifying the missing or faulty elements, the Semantic Assistant is solicited to retrieve services semantically equivalent to those now currently unavailable in the network. Whenever a device is discovered in the network, the prototyped tool is able to automatically create a OWL-S file for every existing operation by extracting information from the service WSDL and according device metadata. Each operation is specified using the OWL-S format [25] so that each operation is semantically defined in terms of profile, functionality, parameters and grounding. By having this information stored and updated, it was possible to run reasoning tasks to determine which services can be semantically equivalent to the one missing. The systems integrator using the according Semantic Assistant GUI can also specify a service matching mapping between two service interfaces. While discovery implies service description and semantic tags comparison, the invocation might need some translation mechanism to adapt to a possible unlike interface – services coming from different sources might differ in the interface although implementing the exact essential function. As the example in Fig. 5, the user specified that the operation drill from drillMachine service can be mapped to newdrill from newdrillMachine. These mappings are defined and stored in XML-based files that can be employed to determine how to execute a service translation. It is noticeably easier to update some parameters in a OWL-S file or define some service interface mappings through an intuitive GUI than reprogram a new device or reconfigure a process plan every time a device turns unavailable. This solution revealed to be quite useful and effective

Fig. 5.

Semantic matching of services GUI

when executing a process plan where some device or service involved is currently unavailable. Whenever it happens, the process plan executor will try to discover a device semantically similar hosting a compatible operation and follow a translation mapping. This mapping will allow the invocation of an equivalent service instead of the missing one while executing the current process plan. This decision can be mediated by the systems integrator or automated for the use-cases that do not involve critical resources or raise security concerns. 2) Semantic gateway: The previous use case assumed that the services were simply invoked by a process task and this last one was responsible for retrieving an appropriate semantically equivalent solution (if available). However, some other network elements might be dependent of that currently inexistent service to execute their own process. In this situation the deployment of a semantic gateway revealed to be an essential instrument on emulating an unavailable device and services interfaces. As depicted in Fig. 6, a semantic gateway will copy the interface of the missing device and its hosted services and translate any invocation that it receives to the semantically equivalent service interface available in the network. Regarding the device that was consuming the missing service, it will now discover the semantic gateway as if it were the original device and invoke its services again – the service interface and device metadata is the same.

Fig. 6.

Creation of a semantic gateway example

In the current application, using the Device Explorer GUI,

the systems integrator can detect or be informed when a device is currently unavailable and create a semantic gateway simply by choosing the according previously stored OWL-S definition and click the Start button. The Device Explorer will then launch a DPWS device which clones the device metadata and service interfaces of the inexistent one. Internally, this new device is able to handle incoming communications (following the original missing service interface), retrieve the available semantically equivalent by exploiting the Semantic Assistant services and execute the translation of interface and parameters in accordance with this new semantically equivalent service. In the generic example of Fig. 6, device A is now unavailable, so a clone device A’ is set and launched. This way the user will the employ A’ as if it was still using the original A, although in reality the user is consuming the service hosted by device B. Following this approach it was possible to run previously stored process plans that included now inexistent services but that were still available through these semantic gateways. From the point of view of the process plan execution, all required devices and services were available and ready to be used. Although this particular solution involves an extra communication cost both in terms of bandwidth and round-trip delay plus some other security concerns, it proved to ensure an immediate solution while a more definite one is being set. IV. C ONCLUSION The current infrastructure presents an innovative solution to ease reengineering interventions in a service-oriented industrial automation scenario. This work validates the feasibility and aptness of the approach previously presented in [18] in a educational shop floor cell test bench installation that can definitely be generalized to a bigger range of industrial automation deployments. By offering a replacement proposal for an inexistent or faulty device whenever there is a need to replace it, along with the ability of launching a clone device that emulates the replaced device and conveys its messages to its semantically equivalent, this approach promises to deliver a relevant impact to ease system integrator role along system lifecycle. The performed tests revealed that the tasks of discovering and identifying new devices, as well as providing assistance when a device is down or disconnected offered a valuable contribution and it can increase the agility of the overall system when dealing with operation disruptions or modifications at device level. Since it is supported by open web standards, this infrastructure leaves the door open for more Interned-based applications. Although most of the overall infrastructure has been already deployed and validated, more extensive validation is still required to fully assess the fitness of this approach to enable a more agile environment in terms of real-time performance, communications reliability and security of access to devices. ACKNOWLEDGMENT This work was partially supported by FCT – Fundac¸a˜ o para a Ciˆencia e Tecnologia under project grant Pest-

OE/EEI/UI0066/2011 and (http://www.imc-aesop.eu).

EU

FP7

IP

IMC–AESOP

R EFERENCES [1] IEEE, “Standard Glossary of Software Engineering Terminology,” IEEE Computer Society – Software Engineering Technical Committee, 1990. [2] J. Park and S. Ram, “Information systems interoperability: What lies beneath?” ACM Transactions on Information Systems (TOIS), vol. 22, no. 4, pp. 595–632, 2004. [3] S. Heiler, “Semantic interoperability,” ACM Computing Surveys (CSUR), vol. 27, no. 2, pp. 271–273, 1995. [4] C. Lin, H. Chiu, and P. Chu, “Agility index in the supply chain,” International Journal of Production Economics, vol. 100, no. 2, pp. 285–299, 2006. [5] R. Schulte and Y. Natis, “Service oriented architectures, part 1,” Gartner, SSA Research Note SPA-401-068, 1996. [6] M. Papazoglou and D. Georgakopoulos, “Service-oriented computing,” Communications of the ACM, vol. 46, no. 10, pp. 25–28, 2003. [7] T. Erl, Service-oriented architecture: concepts, technology, and design. Prentice Hall PTR Upper Saddle River, NJ, USA, 2005. [8] W3C, “Web Services Activity,” http://www.w3.org/2002/ws/, 2002. [9] N. Josuttis, SOA in practice: the art of distributed system design. O’Reilly Media, Inc., 2007. [10] F. Jammes and H. Smit, “Service-oriented paradigms in industrial automation,” IEEE Transactions on Industrial Informatics, vol. 1, no. 1, pp. 62–70, 2005. [11] J. Lastra and M. Delamer, “Semantic web services in factory automation: fundamental insights and research roadmap,” IEEE Transactions on Industrial Informatics, vol. 2, no. 1, pp. 1–11, 2006. [12] S. Karnouskos, O. Baecker, L. De Souza, and P. Spiess, “Integration of SOA-ready networked embedded devices in enterprise systems via a cross-layered web service infrastructure,” in 12th IEEE Conference on Emerging Technologies and Factory Automation, 2007, pp. 293–300. [13] A. Colombo and S. Karnouskos, “Towards the factory of the future: A service-oriented cross-layer infrastructure,” ICT Shaping the World: A Scientific View. European Telecommunications Standards Institute (ETSI), John Wiley and Sons, vol. 65, p. 81, 2009. [14] T. Cucinotta, A. Mancina, G. Anastasi, G. Lipari, L. Mangeruca, R. Checcozzo, and F. Rusina, “A real-time service-oriented architecture for industrial automation,” Industrial Informatics, IEEE Transactions on, vol. 5, no. 3, pp. 267–277, 2009. [15] M. Loskyll, J. Schlick, S. Hodek, L. Ollinger, T. Gerber, and B. Pirvu, “Semantic service discovery and orchestration for manufacturing processes,” in Emerging Technologies & Factory Automation (ETFA), 2011 IEEE 16th Conference on. IEEE, 2011, pp. 1–8. [16] N. Shadbolt, W. Hall, and T. Berners-Lee, “The semantic web revisited,” IEEE intelligent systems, vol. 21, no. 3, pp. 96–101, 2006. [17] S. McIlraith, T. Son, and H. Zeng, “Semantic web services,” IEEE Intelligent Systems, vol. 16, no. 2, pp. 46–53, 2001. [18] G. Cˆandido, A. Colombo, J. Barata, and F. Jammes, “Service-oriented infrastructure to support the deployment of evolvable production systems,” Industrial Informatics, IEEE Transactions on, vol. 7, no. 4, pp. 759–767, November 2011. [19] G. Cˆandido, F. Jammes, J. Barata, and A. Colombo, “Generic Management Services for DPWS-enabled devices,” in IEEE Industrial Electronics Society, Annual Conference of the. IEEE, 2010, pp. 3931–3936. [20] G. Cˆandido, F. Jammes, J. Barata, and A. W. Colombo, “SOA at device level in the industrial domain: Assessment of OPC UA and DPWS specifications,” in Industrial Informatics, International Conference on. IEEE, 2010, pp. 598–603. [21] J. Barata, L. Camarinha-Matos, and G. Cˆandido, “A multiagent-based control system applied to an educational shop floor,” Robotics and Computer-Integrated Manufacturing, vol. 24, no. 5, pp. 597–605, 2008. [22] OASIS, “Devices Profile for Web Services Version 1.1 Specification,” 2009, http://www.oasis-open.org/committees/ws-dd. [23] WS4D, “Web Services for Devices – WS4D-JMEDS stack,” http://ws4d.e-technik.uni-rostock.de/jmeds/, 2012. [24] OSIRIS Next, “OWL-S Java API,” http://on.cs.unibas.ch/owls-api/, 2012. [25] D. Martin, M. Burstein, J. Hobbs, O. Lassila, D. McDermott, S. McIlraith, S. Narayanan, M. Paolucci, B. Parsia, T. Payne et al., “OWL-S: Semantic markup for web services,” W3C Member Submission, 2004.