Manufacturing service bus: an implementation

Available online at www.sciencedirect.com

ScienceDirect Procedia CIRP 00 (2017) 000–000 www.elsevier.com/locate/procedia

11th CIRP Conference on Intelligent Computation in Manufacturing Engineering - CIRP ICME '17

Manufacturing service bus: an implementation Daniel Schela, Christian Henkela, *, Daniel Stocka, Olga Meyera, Greg Rauhöfta, Peter Einbergera, Matthias Stöhra, Marc Andre Daxera, Joachim Seidelmanna a

Fraunhofer Institute for Manufacturing Engineering and Automation IPA, Nobelstrasse 12, 70569 Stuttgart, Germany

* Corresponding author. Tel.: +49 711 970 1331; fax: +49 711 970 1028. E-mail address: [email protected]

Abstract We present the concept and implementation of a Manufacturing Service Bus (MSB, an application and adaptation of the service bus principle of the general IT domain to meet the more specific communication and integration requirements of manufacturing industry scenarios. The Manufacturing Service Bus is the communication middleware component of the Virtual Fort Knox (VFK), a federative cloud platform for manufacturing companies. Key requirement of VFK is the security of the component which is realized through security by design including encryption, authentication and authorization. The flexibility of the system is reached by providing numerous interfaces to existing communication protocols and the expandability with additional interfaces to upcoming communication protocols. © 2017 The Authors. Published by Elsevier B.V. Selection and peer-review under responsibility of the International Scientific Committee of “11th CIRP ICME Conference". Keywords: Integration; Service-oriented architecture; Industrie 4.0; Manufacturing service bus

1. Motivation During the operational phase of a production plant all information regarding the (quality) condition of the manufacturing equipment as well as its performance monitoring is distributed throughout many information systems and interfaces. These information systems can be allocated to different layers or levels of a production company respectively: Manufacturing Execution Systems (MES) for manufacturing process control and systems for management tasks like enterprise resource planning (ERP), warehouse management (WMS) or product lifecycle management (PLM) and others depending on the area of application and the planning horizon [1, 2]. Large companies usually utilize a much larger number of complex IT-supported tools for the optimization of their products and processes than small and medium sized enterprises (SMEs). Such behavior has direct implications on the availability of digital information, which can be used to optimize the planning of processes and additional measures. Especially SMEs often face challenges in making this data and information available, which leads to substantial waste of potential [3, 2]. One of the main reasons for this is a lack in

integration of the big number of diverse IT-Systems, digital tools and equipment. Another cause for this is the use of „historically grown” complex monolithic systems, which are nowadays often used in manufacturing. These systems are either very limited in their functionality or far too complex but only a subset of their functionality is actually used based on the specific requirements of the respective company which is utilizing them. Because of this the trend is towards the use of applications, which are based on modern service-oriented architectures (SOA). One the benefits of this architectural approach is that applications can be provided on premise by the companies themselves, as well as a service based remote solution over the internet in the form of a Software-as-a-Service (SaaS) applications from the cloud. This architectural paradigm builds the premise that a system’s components are separated into selfcontained services. These services can be flexibly connected and orchestrated while they are communicating through their well-defined interfaces which can be loosely coupled and used to exchange messages with each other [24]. Next to the virtualization aspects SOA and web services therefore can be seen as the fundamental building blocks of cloud computing.

2212-8271 © 2016 The Authors. Published by Elsevier B.V. Selection and peer-review under responsibility of the International Scientific Committee of “11th CIRP ICME Conference".

D Schel et al. /Procedia CIRP 00 (2017) 000-000

One closely related and very important topic is the so called Internet of Things (IoT). This term has generally two meanings: The IoT-paradigm and the IoT-Network. The first meaning encapsulates the vision of the merging of the digital and physical world into an indiscernible unit. The second meaning refers to the to a global Network, which is an physical extension of the internet as it’s known to us and which encompasses new types of smart respectively intelligent devices [4]. These smart devices, often called smart objects, are capable to identify themselves and offer some sort of selfdescription. Moreover they have profound sensory and actuatorial capabilities [5]. The various fields of application of Machine-to-Machine (M2M) applications are experiencing a strong growth which is expected to accelerate over the next few years. The reason for this is not only the utilization of IoT in consumer electronics, health care, smart homes and buildings, smart cities, but especially the „smartification“ of production equipment in large industries like the automotive industry [6]. To enable companies to harness the potentials regarding increased flexibility of the IT-systems landscape and consistent availability of data, which have been mentioned in the previous section, a communications platform is required, which encompasses all the listed developments and provides a common technological basis. A platform like this should enable fast, inexpensive and low-risk provision of secure, agile and customer-specific IT-solutions by means of highly automated integration functionality. Independent service vendors (ISVs) have to be put in a position to create novel services and business models in the area of production IT, both in regards to functionality and accounting models. For this the platform has to support ISVs in all phases of a service life cycle with business process development, consulting, frameworks and basic functionality in the form of base services. This will lead to ISVs being able to provide more and more specialized microservices, which fulfill specific tasks. Customers and end users can pick and choose the best fitting services respectively functionality and combine them flexibly with each other, to combine them into the optimal solution for their requirements. This solution can then be provided from the platform inexpensively, fast and without any major risk, because it can be based on a flexible subscription or pay per use model. An approach like this vastly reduces the cost for implementation, integration and operating of such IT solutions. New software functionality for end customers can be provided quicker and at lower cost [7]. The usual high investment cost can be transformed into variable cost which is directly dependent on the actual demand and consumption of the service. Moreover customers need to be able to integrate their production equipment with the platform to provide the data from their systems to the data-driven services of the platform to generate information and value from them. Integration is still one of the biggest challenge for production IT because of the lack of interoperability. To provide a possible solution for this challenge a problem solving approach for interoperability and interface compatibility between such a platform and shop floor systems and equipment is needed.

2. State of the art Software systems, whose main purpose it is to integrate other software systems and components with each other, are generally referred to as middleware, sometimes also integration middleware [8]. These systems often offer services for communication, integration application execution, monitoring and operation. The main intent of middleware is it to make development of applications easier by offering common abstractions which add an abstraction layer to hide the heterogeneity of the available interfaces [9]. Normally middleware can be classified by its domain or area of application, which is cloud integration, business process integration, application integration and data integration. Cloud integration middleware is used to integrate cloud services, cloud applications and mobile applications, cloud infrastructures and other cloud resources [10]. Middleware for integration of business processes aims at the integration of applications of customers, providers and business partners, which offer various interfaces but need to be used in common business processes and exchange data and information between each other [11]. Application middleware is often used to integrate the on-premise software solutions in companies as they are nowadays still broadly used with each other, or, as the trend has been showing for some time now, with applications in private or public cloud infrastructures [12]. Data integration middleware mainly integrates a number of data sources and sinks, which in enterprises can be databases or information systems [13]. As examples for applications classic database systems, Distributed Computing Environments (DCE) and Remote Procedure Call Systems (RPC), an industry standard which has been widely established since the 90s [14], can be named. The use of so called Enterprise Service Bus Systems (ESB) in companies mainly serves the integration of distributed systems in the application environment of a company [15]. The arrival of Internet of Things technologies in production as part of Industrie 4.0 [16] has opened up new possibilities, but also has led to new challenges. Newer machines have been equipped with communication technology, which allows them to provide data and information comparably easy and transfer it via standardized protocols like OPC UA. Older machines and legacy systems rarely have the ability to either directly communicate or make their data available. Often the integration of production equipment isn’t a matter of feasibility, but a question of practicability and profitability. The point of an actual non existing Industrie 4.0 standard (the fourth stage of industrialization) suggests that the complexity of the integration with the increasing number of smart objects continues or increases. Another challenge is the increasing complexity of managing the increasing number of networked smart objects. Here the concept of a Manufacturing Service Bus (MSB) can offer a solution.


Fig. 1. MSB and five layers of integration [23].

3. Concept The Manufacturing Service Bus (MSB) is an integration platform, which is based on a service-oriented architecture and allows flexible linking of different production-based IT services. The MSB transmits the well-known concept of an Enterprise Service Bus (ESB) to the production and extends it by additional functions based on the specific requirements in the production [22]. The initial concept describes four principles the MSB applies to, which are still valid [23]:    

Ease of reconfiguration Loose coupling Asynchronous communication Standards-based integration

It also introduces the five layers of integration, which are depicted in Fig. 1. The MSB represents one of the five different levels of abstraction, which can be summarized as follows. The Data Source Layer is containing all manufacturing systems and digital factory information systems, which comprises a number of heterogeneous data sources, diverse data models and a various use of different communication protocols. The Data Service Layer enables manufacturing systems and applications to provide data as services, with help of service adapters. These are interfaces which can be connected to the MSB. The Integration Layer is the MSB itself and includes an ESB enhance by content-based routing of events and mediation services, e.g. for message transformation or BPEL processes. The Integration Service Layer contains integration services and manufacturing applications, which are typically the enddestination of the event notifications processed by the mediation services. The Business Process Layer contains all business processes in a manufacturing environment that are relevant for the execution of production processes [23]. This approach of the MSB introduces some changes and improvements to the original concept by addressing additional requirements and challenges. The main challenge in the

realignment of the MSB is to design it as an open, secure and user-friendly integration platform. The MSB is intended to enable the flexible linking and dissolving of dedicated and protected virtual connections in a multi-tenant environment, managing the interoperability smart objects and software services. In the context of Industrie 4.0 this is intended to ensure not only the vertical integration of the shop floor into the cloud, but also the horizontal integration between several locations, companies and clients. To meet this requirement, the MSB is conceived as a cloud-based integration platform. Therefore, a reduction of complexity in cloud connection and the intelligent networking of smart objects must be achieved. In addition to usability aspects the confidentiality, integrity, availability, authenticity and authority must be guaranteed. Furthermore, the scope of the connectable and integratable physical devices has been extended to smart objects, which includes all network-capable and self-possessing devices, from the sensor to the production machine. In order to ensure the flexible deployment, support of several communication standards is required as well. The ability to connect to proprietary interfaces of already existing software or systems must also be considered. The data provided will be used by different services of different independent software vendors. When implementing their services, they should be abstracted from the specific underlying hardware (smart objects), which causes new challenges for the MSB in providing interoperability and interface compatibility. With reference to the five layers of integration, major improvements in the Data Service Layer can be realized. Services do not explicitly need a data service in the Data Service Layer, except for special cases like proprietary databases. This results in the opposite of the initial approach. The Integration Service Layer is also an optional layer, because this functionality is part of MSB itself and external integration services are not required. The manufacturing applications are still present, but not in this layer, because differentiation in handling data sources and data destinations is not contrastive enough. A smart object or application can represent a data source, a data destination as well as a manufacturing IT service. Therefore, the Data Source Layer can be renamed to Smart Service Layer. The MSB itself utilizes and adapts the wellknown components like the ESB, workflow engine and content-based routing service to address challenges of the production it. The following tables summarize the requirements faced by the MSB implementation approach. Table 1. Functional requirements Requirement

Description

Management of connected services

The MSB needs to provide management functionality for the connected sensors, actors and legacy ITSystems, so called smart objects and applications. These are either capable to communicate directly or they are integrated via smart adaptors. All incoming and outgoing information which is required for this integration has to be managed.

Service-to-Service communication

The MSB has to reduce integration effort between smart objects and applications while reducing expenditure of time for integration. Furthermore

D Schel et al. /Procedia CIRP 00 (2017) 000-000 integration concepts like publish-subscribe, workflow based integration and event driven communication have to be supported. Harmonized information model

Services which provide differing information models have to be integrated with each other, which requires merging and/or translation of data models between them. Therefore an overarching respectively generalized information model, which enables translation of information between the connected subsystems is required.

Integration via multiple communication standards

The MSB has to support multiple communication standards (e.g. RESTful API, WebSocket API, …) and communication protocols like OPC UA and MQTT.

Table 2. Nonfunctional requirements Requirement

Description

Multi-tenancy capability

The MSB has to provide separated management of multiple users.

Generic Interfaces

The interfaces have to be as generic as possible, to prevent the need of specific data models for different use cases.

Ease of use

The MSB needs to provide high usability to enable users to configure an integration even if they are not IT experts.

High flexibility and reconfigurability

The MSB has to eliminate the dependencies between shop floor components and IT functionality and allow for a continuous adaptation of interconnection between these systems.

Increased security

The MSB has to increase data and information security between the shop floor and the cloud level.

Cloud-capability

The MSB has to be deployable in a Cloud-based infrastructure respectively platform.

4. Implementation This section will describe the implementation of the reoriented approach of the Manufacturing Service Bus. 4.1. Architecture The MSB is based on a modular and service-oriented architecture, as shown at Fig. 2. This architecture enables a number of advantages. All components of the system follow the Self-contained System (SCS) approach [24] and communicate over defined interfaces and therefore can be replaced or extended with relatively low effort. Each component communicates through web technology based interfaces, which abstract the underlying technology and for instance remove the dependency on a runtime environment, like an operating system, or the chosen implementation language. Components performing a logical function are decoupled from databases, respectively the persistence layer, and thereby enable flexible horizontal scalability. The interfaces towards external applications are implemented as interface-components that offer endpoints for specific protocols. Because of their service oriented nature, they can be extended for any kind of protocol. The system can be deployed

and executed centrally locally, distributed in a cloud environment or in a hybrid fashion as a combination of both.

Fig. 2. MSB components.

To support connectivity for various communication protocols and standards common interfaces are provided by the MSB, currently including interface implementations of a RESTful API, WebSocket API, OPC-UA Server and Client and a MQTT broker. The abstraction layer called Broker allows an easy extension of these interfaces by interfaces for further protocols, standards or proprietary services. The user data as well as permissions of users, organizations and services are managed by the Identity & Permission Management. It is built on top of openLDAP, an open source implementation of the Lightweight Directory Access Protocol, and comes with a stand-alone LDAP server [25]. The LDAP standard enables the integration of directories of common enterprise infrastructures like Active Directory Server. Another component of the MSB is the Connected Service Management, a kind of repository for registered applications and machines respectively smart objects, which are summarized as smart services. The Connected Service Management represents a rudimentary variant of a digital twin [19] since it only offers a selfdescription of a machine in its current state. This information is used in the Frontend module, a web-based user interface that enables a user to configure integrations between smart services by using a graphical designer. The designed integrations are called integration flows and are later managed and processed by the Message Processing module. The integration of applications, equipment and smart objects is facilitated by supporting client libraries, which are provided for various programming languages and protocols. This way an IT specialist can integrate production equipment with low effort to the MSB via OPC UA [21], while non-IT specialists can intuitively configure data and information flows, which makes the concept especially suitable for production environments. 4.2. Communication pattern All the interfaces and clients of the MSB interoperate in a common way, which can be termed as an asynchronous communication pattern. Initially a client registers itself at the provided interface. In this initial step, the client sends the selfdescription of its service as part of the first message to the MSB. The corresponding interface validates the selfdescription, extends it and sends it to the Connected Service


Management, where the information gets stored. In the second step, the connected smart service can publish events to the MSB or receive operation callbacks from the MSB. For this reason, applications that build on the MSB as a communication layer work in a combination of the two architectural styles, service-oriented architecture (SOA) and event-driven architecture (EDA) [23, 26]. 4.3. Self-description The self-description summarizes information including the human readable self-description of the machine or application, its identity and the capabilities of the machine, representing a rudimentary variant of an administration shell [18]. Other information like state or process data is currently not persisted, but it can be provided by integrating a separate service through a platform offering this functionality [20]. The capabilities of a machine encompass its operations, which provide control functionality and its events, which provide data and information including a description of their data structure. These events and operations are essential for the concept of the MSB, since it is operating in an event-driven fashion. A minimal self-description, required to integrate a smart service with other services via the MSB, is illustrated at Fig. 3. The property uuid is the unique identifier of the smart service, which can protect against manipulation by a certificate. To enable the usage of one instance of the MSB for multiple organization, the property token is required as part of the selfdescription. It represents a secret to identify a smart service and its owner, which is required during the verification step. This step has to be passed before a user can use a smart service. Properties like name and description at smart service, event and operation class are used as a textual description for a developer or service integrator during the integration configuration. The set of events and operations specifies the capabilities of a smart service. The property eventId at the event class and operationId at the operation class are unique identifiers in combination with the smart service. The dataFormat property at these two classes describes the data set that can be part of an event or the parameter used to call an operation. The format to describe such data is based on the OpenAPI Specification. It is originally used to describe RESTful APIs in a standardized, language-agnostic way [27], but the schema object description is a common way to describe simple and complex data structures and it is based on the JSON Schema vocabulary [28]. Operations are also defined like events, with the difference that an operation can have multiple results consisting of response events. The generalization to smart objects and smart applications is only used for differentiation of a physical and a purely virtual smart service.

Fig. 3. Smart service self-description.

Fig. 4. MSB component utilization at message processing.

4.4. Message processing The routing and transformation of data is controlled and executed by so called integration flows, which are configured in the web-based integration flow designer. The message processing utilizes concepts like a message queue (MQ), an enterprise service bus (ESB) as well as a workflow engine (WE), see Fig. 4. The functionalities of routing, queuing and message transformation can be mapped to the components MQ and ESB. The workflow engine is required for service orchestration, to allow the building of business processes on top of this operations. During the deployment of an integration flow to the underlining WE, it is divided into basic elements, the transitions. Furthermore, these transitions are divided in routing elements, which are deployed to the MQ, and the message transformation elements, which are deployed to the ESB. Incoming data is forwarded to the system in form of complex messages called event notifications, passing the interface endpoints. The broker provides a common interface mapping into several queues to the MQ. The communication with the MQ is based on AMQP, so several message queues supporting this open standard can be used [29]. All event notifications of a smart service are published to an “in” exchange. The bindings between these “in” exchange and multiple “out” queues are used to extract and distribute the message information of the event notifications from its publishers to its subscribers. These bindings are based on routing keys which are the event ids. For transformation as well as aggregation of the messages during a transition, a flow, which is deployed to the ESB, is listening to one “out” queue.


After the transformation part is done, the transformed message is send back to an “in” queue for the subscribed smart service. The MSB interface is listening for the “in” queue of its connected smart service and sends the message as an operation callback to the smart service. On top of the execution of these transitions the WE observes the state of integration flow which can consist of a set of smart services (events and operation calls) and the transitions between them. In the notation of a workflow a service operation call is a task which can have a result, called event. The identification of an event as a result of a specific operation call is handled by the WE. This event can be the trigger for the next transition, which ends in an operation call of a smart service. The WE performs the verification of the current status and checks if the event is permitted to execute the task. One step of this check can be defined condition, which can be configured for a transition. If the condition is true, WE executes the next transition which end in the next task. An integration flow, which is triggered by an event, can be also started in parallel. Therefore, the WE must also verify if it is allowed for the specific integration flow or not, and possibly preventing the event from being processed. The WE also checks if an event is too old for executing a task, else the transition is not allowed and the event is thrown away too. 5. Conclusion This approach simplifies, improves and updates the initial concept, which brings the MSB closer to the goal of a universal integration middleware or platform and closer to an application in the production field. It can also be seen in the area of Industrie 4.0 as a universal communication layer, which enables the vertical integration, from shop floor to the cloud, as well as the horizontal integration, for communication over the supply chain or M2M. The standardized, language-agnostic description of the data format is the main key for the transformation capability of the MSB. Furthermore, the way of self-registration of the smart services at the MSB allows to build a communication network between the participation and to change it flexibly. The MSB opens also new possibilities for integration. On the one hand to deliver integration as a service and in the future to enable a new level of automatic integration e.g. by machine learning. References [1] Wilmes R. OPC UA als Kommunikationsbasis in der Industrie 4.0. WEKA FACHMEDIEN 2013. [Accesed: 13.11.2015]. Available: http://www.elektroniknet.de/automation/steuerungstechnik/artikel/100624 /1/. [2] Kowaleski S, Braune A, Dernehl C, Greiner T, Koziolek H, Loskyll M, Niggemann O, Paiz Gatica C, Reißig G. Statusreport: Industrie 4.0 CPSbasierte Automation - Forschungsbedarf anhand konkreter Fallbeispiele. VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik (GMA) 2014. [3] ACATECH (HRSG.). Umsetzungsempfehlungen für das ZukunftsprojektIndustrie 4.0 - Abschlussbericht des Arbeitskreises Industrie 4.0. 2013. [4] OPC FOUNDATION. OPC UA in the Reference Architecture Model RAMI 4.0. 2015 [Accesed: 25.11.2015]. Available: http://opcfoundation.org/opc-connect/2015/06/opc-ua-in-the-referencearchitecture-model-rami-4-0/.

[5] OPC FOUNDATION. OPC Unified Architecture: Wegbereiter der 4. industriellen (R)Evolution. 2013. [6] Knoll A. Produktionsmaschinen werden zu Datenzwitscherern MTConnect als neuer Datenübertragungs-Standard. 2014. [Accessed: 23.11.2015] Available: http://www.elektroniknet.de/automation/m2m/ artikel/112702/. [7] OPEN SOURCE ROBOTICS FOUNDATION. Robot Operating System (ROS) Tutorial, ExaminingPublisherSubscriber 2012. [Accessed: 03.04.2017] Available: http://wiki.ros.org/ROS/Tutorials/ ExaminingPublisherSubscriber. [8] Ruh W, Maginnis F, Brown W. Enterprise Application Integration: A Wiley Tech Brief. New York: John Wiley & Sons, 2001. [9] Defining Technology; What is Middleware?, 2008. [Accessed: 03.04. 2017] Available: http://www.middleware.org/whatis.html [10] Sain M. The future of cloud integration: Cloud Middleware?. 15th International Conference on Advanced Communication Technology (ICACT) 2013. [11] Caseau Y. Self-adaptive middleware: Supporting business process priorities and service level agreements. Advanced Engineering Informatics 2005; Volume 19, 199–211. [12] Batra U, Mukharjee S. Enterprise Application Integration (Middleware): Integrating stovepipe applications of varied enterprises in distributed middleware with Service Oriented Architecture. 3rd International Conference on Electronics Computer Technology (ICECT) 2011. [13] Conrad S. Föderierte Datenbanksysteme. Konzepte der Datenintegration. Springer 1997. [14] Khandker A. Honeyman P, Teorey T, et al. Performance of DCE RPC. Second International Workshop on Services in Distributed and Networked Environments 1995. [15] Morand D. Garcia I. Lalanda P. Autonomic Enterprise Service Bus. IEEE 16th Conference on Emerging Technologies & Factory Automation (ETFA) 2011. [16] VDI/VDE Statusreport – Referenzarchitekturmodell Industrie 4.0 (RAMI4.0). 2015. [18] VDI/VDE Statusreport – Industrie 4.0 – Technical Assets: Basic terminology concepts, life cycles and administration models. 2016. [19] Alam K, Saddik A. C2PS: A Digital Twin Architecture Reference Model for the Cloud-Based Cyber-Physical Systems. IEEE Access 2017; Volume 5. [20] Stock D, Stöhr M, Rauschecker U, Bauernhansl, T. Cloud-based platform to facilitate access to manufacturing IT. 8th International Conference on Digital Enterprise Technology Amsterdam 2014. [21] Hoffmann M, Thomas P, Schütz D, et al. Semantic integration of multiagent systems using an OPC UA information modeling approach. IEEE 14th International Conference on Industrial Informatics (INDIN) 2016. [22] Minguez J. Der Manufacturing Service Bus. Digitale Produktion. Heidelberg: Springer-Verlag; 2013. [23] Minguez J. A Service-oriented Integration Platform for Flexible Information Provisioning in the Real-time Factory. 2012. [24] innoQ: Self-Contained Systems - Assembling Software from Independent Systems. 2017. [Accessed: 03.04.2017]. Available: http://scsarchitecture.org/ [25] OpenLDAP. 2017. [Accessed: 03.04.2017]. Available: https://www.openldap.org/. [26] Wieland M, Martin D, Kopp O, Leymann F. SOEDA: A Methodology for Specification and Implementation of Applications on a Service-Oriented Event-Driven Architecture. Proceedings of the 12th International Conference on Business Information Systems 2009. [27] 'OpenAPI-Specification', 2017. [Accessed: 03.04.2017]. Available: https://github.com/ OAI/OpenAPISpecification/blob/master/versions/2.0.md. [28] 'JSON Schema', 2017. [Accessed: 03.04.2017]. Available: http://jsonschema.org/. [29] 'Advanced Message Queuing Protocol', 2017. [Accessed: 03.04.2017]. Available: http://www.amqp.org/.