Architecture and Conceptual Design for IPS2 ... - CyberLeninka

Available online at www.sciencedirect.com

Procedia CIRP 7 (2013) 365 – 370

Forty Sixth CIRP Conference on Manufacturing Systems 2013

Architecture and Conceptual Design for IPS²-Execution Systems Horst Meiera, Thomas Dorkaa, Friedrich Morlocka* a

Ruhr-Universität Bochum, Chair of Production Systems, Universitätsstr. 150, 44801 Bochum, Germany

* Corresponding author. Tel.: +49-234-32-29890; fax: +49-234-32-09890. E-mail address: [email protected].

Abstract Industrial Product-Service Systems (IPS²) are a new way of providing customer value and therefore represent globally competitive manufacturing systems. Multiple networked partners are involved in the delivery of the IPS², i.e. the customer, the IPS² provider and suppliers. The information provided by the partners and the supplied resources need to be coordinated, controlled and managed by a software system. In this paper, an architecture and a conceptual design for such a system, called IPS²-Execuion System, is presented. For this architecture, the structure of the IPS² organization, among others, has to be taken into account. © 2013 The TheAuthors. Authors.Published Published Elsevier B.V. © 2013 byby Elsevier B.V. Selection and/or peer-review responsibility of Professor PedrodoFilipe Carmo Cunha Selection and peer-review underunder responsibility of Professor Pedro Filipe CarmodoCunha Keywords: Industrial Product-Service System (IPS²); Organization; Architecture; IPS²-Execution System; Software

1. Introduction In the manufacturing industry, competitors are continuously struggling to differentiate themselves from other companies on the market. Industrial ProductService Systems (IPS²) offer this differentiation by representing a paradigm shift from traditional product selling and service offering to providing customer value, as presented by [1-3]. [3] also gives the following definition of IPS² based on [4]: -Service System is characterized by the integrated and mutually determined planning, development, provision and use of product and service shares including its immanent software components in Business-to-Business applications and represents a knowledge-intensive socioAccording to [5], the IPS² lifecycle is divided into five phases: planning, development, implementation, delivery and use as well as closure. The research presented in this paper is focused on the delivery and use phase of IPS². During the phases proper tool and software support is required. [6] states that the tool and system support for the IPS² provision is not sufficient, yet. In order to overcome this issue and to support the IPS² provider during use phase an IPS²-Execution System (IPS²-ES) is needed for the planning, scheduling and organization of the required delivery processes and the

partner network (motivated for example in [7]), which are explained in detail in chapter 2. Based on a specification of requirements for IPS²-ES, as presented in [8], the architecture for the software system and a conceptual design can be developed. Among the requirements are several interfaces to external systems, the integration of an IPS² planning method, the measurement of the effect performance and web-based user interfaces consisting of multiple so-called WApps. 2. State of the Art To understand the complexity of IPS², the required organization structure and the special planning methods are described in the following chapters. Additionally, a brief introduction to software architecture and design is given. 2.1. Organization of IPS² Due to the aforementioned paradigm shift from offering products or services to an IPS² provision, an organization that is adapted to the requirements of IPS² is needed. An IPS² is a collaboration and cooperation platform and needs a partner network. This network consists of different roles. The network contains customer, IPS² provider, IPS² module suppliers, component suppliers

2212-8271 © 2013 The Authors. Published by Elsevier B.V. Selection and peer-review under responsibility of Professor Pedro Filipe do Carmo Cunha doi:10.1016/j.procir.2013.05.062

366

Horst Meier et al. / Procedia CIRP 7 (2013) 365 – 370

and service suppliers. For each IPS², some of these partners are responsible for its delivery and therefore form the IPS² network. An IPS² delivery network for each delivery process is built from partners in the IPS² network. The connection between the networks is presented in Figure 1 [9, 10]. The customer pays for the value of the IPS² provided by the IPS² provider. The business model, which may focus on functionality, availability or result of the IPS², has an influence on this relationship. Depending on the IPS² delivery, the customer may have to contribute his resources for the delivery processes. As the coordinator of the IPS² network the IPS² provider offers solutions to the customer and also represents the face to the customer . The IPS² module suppliers in the network coordinate a specific part of the IPS² and take the risk for their processes. Last but not least component suppliers deliver parts or components while service supu pliers deliver services directly to the customer. [9, 11] IPS² Provider

IPS²

Delivery Process 02.10. 03.10. 04.10. 05.10. 06.10. 07.10. 08.10. 09.10. 10.10. 2009 2009 2009 2009 2009 2009 2009 2009 2009 2009

A

1

2

3

H

B

A G

C

D

4

E

F

Provider Network

1:n

C

1 E

H F

IPS² Network

1:n

A

1

H

IPS² Delivery Network

Fig. 1. IPS² Networks

Due to the IPS² requirements and the IPS² network, a high flexibility of the organizational structure is necessary. The hierarchical architecture of traditional organizational structures is inappropriate for dynamic IPS² because of its restricted flexibility [12]. [11] analyzes a huge variety of organizational approaches like selff configuration [13] or modularization [14, 15]. He concludes that virtual organization units are most suitable for IPS² networks. The suppliers in an IPS² network are existing companies with their own business and organizational structure. To participate in an IPS² network, they offer some of their resources to the IPS² provider. Each of them is free to decide which and how many resources they wish to offer. This is why a rather virtual organizational approach has to be chosen. Organizational units consist of an input and output and they are described by their designation, their resources and their processes. In an IPS², the virtual organization units (VOU) communicate with each other. This communication is supported by an IPS²-ES [11].

2.2. Capacity and Resource Planning for IPS² The IPS² resource planning has to consider two different planning horizons. The strategic capacity planning has a time horizon of weeks to months and is the basis of the operational resource planning. The operational resource planning covers hours to days. [16] The IPS² capacity planning provides the resources which are needed for the service delivery during the operation of IPS². The aim is to provide the delivery in the right quality and quantity at the correct time and place. The data for the planning is obtained by the IPS² product model. [12] Due to the time horizon, the strategic capacity planning determines the needed resources to deliver the IPS² in the future. There is a connection between the IPS² capacity planning and the IPS² organization. The required resource capacities have to be considered in the delivery network by the IPS² provider. The strategic planning is the basis for the initial delivery plan. To execute this plan, several resources have to be provided. These resources have to be available in the provider network. The operational resource planning changes the delivery plan if an unplanned demand arises on short notice. This changes the operation of the IPS² and therefore rescheduling for the delivery is needed [17]. Factors like the limited availability of workers or the travelling from one delivery location to another influence the operational resource planning. Planning for IPS² in general is very complex [18]. One solution to solve these planning challenges is a heuristic planning algorithm presented by [19]. This planning algorithm is especially designed to suit the IPS² requirements. The IPS²-ES is responsible for executing the strategic and operative planning. 2.3. Software Architecture and Design According to [20], the architectural design process is one of the two activities (in addition to the detailed design) between gathering the software requirements and developing the software. The architectural design describes the components of the software and connection between them. The detailed design specifies the components themselves. Several enabling principles can help to generate a software architecture. Among these are abstraction, coupling and cohesion, decomposition and modularization as well as encapsulation and information hiding. [20] There are several different system architectures known in computing science, like client/server models, object-oriented models, component-based models and service-oriented models. Service-oriented models are most widely known under the term -oriented


. Although service-oriented architectures (SOA) are often connected to web services, the technologies used to build a SOA are secondary. Services are the basic components that are used to build a SOA. They encapsulate functionality and data and offer an interface to access these. Through orchestration, complex service can be realized as compositions of other services. In contrast to that, a choreography of services allows for the combination of services into business processes. [21] To establish a common understanding of SOA, the Organization for the Advancement of Structured Information Standards (OASIS) developed a reference model for service-oriented architectures. It aims providing an ignificant entities and relationships between them within a serviceoriented environment, and for the development of consistent standards or specifications supporting that envi[23] elaborates on the area between business and IT when working together in an SOA ecosystem. 3. Architecture and Conceptual Design for IPS²Execution Systems To provide a common understanding of IPS²Execution Systems, the following can serve as a definition: An IPS²-Execution System is the essential software system for the IPS² operation phase that supports the IPS² provider in the provision of customer value by adaptive IPS² delivery planning, IPS² network management and an integrated performance measurement method. This is accomplished by interacting with other software systems for IPS² (e.g. the IPS²-Control Systems and the IPS²-Lifecycle Management System) as well as external software services, e.g. for ordering logistics or products and route planning provided by the network partners. The system is permanently and securely accessible from any location for each partner in the IPS² provider network, i.e. IPS² provider, IPS² customer and IPS² supplier, and connects the partners individual software systems to gather information for the IPS² delivery and provide necessary data to each partner. The partners are represented as VOU inside the IPS²-ES. To be able to handle this complex automated system and provide a high-level overview for the system users, an integrated performance measurement method provides execution data and ensures the intended effect of the IPS²-ES on the customer value delivery. Using the aforementioned as a basis, the architecture of an IPS²-ES has to support the special organization form of IPS², namely virtual organization units, provide the IPS² planning methods, including their required

software services, establish ways of communication for the network partners and enable the implementation of a performance measurement method. The influence of both parts is reflected in the architectural approach presented in this paper. One of the main challenges of the IPS²-ES is the integration of several software systems. Each of these software systems contains data for the planning algorithm that needs to be implemented in the IPS²-ES. The systems can be software tools from different areas like production (e.g. Manufacturing Execution Systems, MES), service (e.g. Service Management Systems, SMS) or management (e.g. Enterprise Resource Planning, ERP). They can also be owned by the IPS² provider, IPS² customer or one of the IPS² suppliers. Additionally, the set of suppliers and thus the set of software systems are changing during the runtime of the IPS²-ES. Hence, the architecture has to be able to handle these changes and to provide a consistent view of the data used in the IPS²ES. Therefore, each set of software systems of one participant of the provider network is realized by one component in the IPS²-ES representing the company as a VOU. Each VOU acts as an aggregating information and communication gateway to the corresponding partner. With this approach, each network of the IPS² organization (i.e. provider network, IPS² network and IPS² delivery network) can be digitally formed and information exchange is supported. Using the aforementioned data exchange, the information required for adaptive IPS² delivery planning can be acquired. The planning itself is integrated into the IPS²-ES as a service that uses the VOU to perform strategic capacity planning and operational resource planning. The advantages are the following: first and foremost, the planning method can be easily exchanged if alternative planning methods for IPS² arise. Second, the service can be reused for multiple IPS²-ES and can be moved to a high-performance computing environment (e.g. cloud-computing system), if required. For the IPS² delivery, a possibly large network of partners is needed, each providing multiple resources. Additionally, the configuration of the partner network is subject to change whenever partners enter or leave the network. The IPS²-Es has to ensure the quality of the partners, resources and processes as well as an optimal assignment of resources to processes. For this complex task, the IPS²-ES has to use even more complex methods to support the IPS² delivery. However, this complexity in turn makes it harder to see whether the intended effect of the IPS² delivery is realized and which factor of the IPS² delivery (e.g. planning method, network partner, resource, etc.) is responsible for any unwanted effects.

367

368


To solve this dilemma, the IPS²-ES integrates the performance measurement method (PMM). The PMM monitors three aspects connected to the IPS²-ES. The first aspect refers to the IT system itself. The Response time of services, error messages and the availability of parts of the system are some of the figures that have to be considered. Measuring these internal figures gives information about the internal operation of the system. Countermeasures can mainly be taken inside the system, for example by integrating services with response time or improving the overall software quality. The second aspect is the monitoring of the planning service. Here, the length of a planning run is observed and the resulting delivery plan can be analyzed according to the three planning objectives: cost, punctuality and balanced work load. The planning is an internal factor of the IPS²-ES, however, it relies on the external environment (i.e. available resources, possibility for process replacements, etc.) determined by the IPS² development. Therefore, countermeasures can mainly be taken from outside the system, for example by changing the partner network or designing new processes. The third aspect is the evaluation of the network partners, their resources and overall service processes. Therefore, the quality of the resources during an IPS² delivery can be tracked. Network partners are rated according to their disposition to provide flexible resources. Processes are, for example, rated along to their first time fix rate. These are external factors of the IPS²-ES, which are influenced externally. To support the abovementioned functionality, several external services and systems have to be integrated in or connected with the IPS²-ES. Internet-based route planning services are available for use by the IPS² planning algorithm to estimate the travelling times of human resources. Also, logistics services can be ordered and scheduled automatically (e.g. for spare part delivery) by the IPS²-ES after a delivery plan is generated. Information about logistic costs and delivery times provided by the services may be taken into account during the planning run. These services are ideally supplied by partners in the IPS² network, for example transport, freight and logistics service providers or rental car providers. Apart from the external services, external systems can provide required data or have to be informed about delivery plan changes. IPS²-Control Systems (IPS²-CS) monitor each IPS² with a software agent system including condition monitoring agents and report unplanned demands (e.g. repairs) to the IPS²-ES. The IPS²-ES has then to execute operational resource planning to include the required process in the delivery plan. The IPS²Lifecycle Management System (IPS²-LMS) can be used to provide necessary data about delivery processes that

can be provided to network partners involved in the execution of the process. As the delivery plan is also considered important data for the IPS², it can be stored in the IPS²-LMS for access by other systems or actors. A knowledge management system for IPS² can derive knowledge from delivery plans and their changes. A schematic overview of the IPS²-ES and the required components, services and external systems is presented in Figure 2. All participants of the provider network have their own software systems, shown here as ERP, SMS and MES. The data required from these softf ware systems is aggregated in VOU. The planning service uses the aggregated data and several services for the planning procedure. External systems provide data or trigger actions, while the PMM service indicates whether the targeted performance of the IPS² delivery is achieved. IPS² customer HLB-Kunde HLB-Kunde ERP

IPS² provider HLB-Anbieter

MES

IPS -ES IPS² ES

IPS² supplier HLBHLBZulieferer 1 Zulieferer ERP 1

VOU

ERP

Planning Service

SMS MES

External Services

VOU Performance Measurement Method

IPS²-CS

SMS VOU VOE VOE

MES

IPS²-LMS IPS² software systems

Fig. 2. IPS²-Execution System

Schematic Overview

The intended architecture of the IPS²-ES is a layered, component-based and service-oriented architecture. The uppermost layer is the graphical user interface (GUI), which is web-based. Here, the functionality is presented to the different users of the IPS²-ES in so-called WApps [8]. Each WApp covers a different part of the IPS²-ES and each user only has access to a restricted set of the WApps. WApps may have overlapping functionalities, each presenting the functionality and data in a different form. However, usability aspects are commonly taken into account throughout the WApps. Therefore, each user can select the WApps he is most comfortable with in performing his task, while he is still able to use all WApps available to him. The selection of WApps for each user is stored, so that each time the user logs in, his WApps are directly available for him. The users gain access to the different services available in the system by the GUI layer. Most importantly, these are the IPS²-specific high-level services like the planning mechanism and the PMM. These services use, combine and orchestrate lower level services to perform


their task. VOU services, located in the lower level service layer can use a middleware layer to communicate with the external software systems of the IPS² network partners. Other services in the lower service layer may wrap external services for access by IPS²-ES-internal services. A vertical plug-in layer provides the mechanism for service communication as well as the functionality to add and remove services during runtime. Both the higher and the lower level services can benefit from this functionality. Depending on the hardware system used to host the IPS²-ES, another layer may have to be used. For a cloud computing environment, as assumed in Figure 3, a cloud system layer might be present. The hardware layer is mostly irrelevant for the platform-independent IPS²-ES. IPS²-Execution System Software Layer

Externall Systems

Web-base Web based d Grap Graphica hicall User Int Interfa erface ce ((GUI) GUI) WApp2

WApp1

WApp3

WAppN

ERP, MES,

Plugg-In In Syste Syste y m

IPS²-spec IPS² p ifi ific Ser Service i Lay Layer ((Hi High h Lev Level) l)

Planning Service

Route Planning Services

PMM Service Serviice Layer (Low Level) l)

Virtual Organization Unit VOE-Dienste Service

External Unabh. Service Dienste

Service Unabh. Wrapper Dienste

Logistic Services IPS²-Control System

Middlewa Midd leware lewa re Layer Layer y Cloud Clou Cl d-SSyst y tem em--LLaye aye y r Physiicall Laye Phys Ph Layer (Hardw d are))

Fig. 3. Layered Architecture of an IPS²-ES in a Cloud Environment

4. Conclusion In this paper, a new architecture and a conceptual design for IPS²-Execution Systems are presented. The functional specification described in [8] can be realized by this approach. Using a software equivalent of virtual organization units in combination with a plug-in system provides a strong basis for the development of a selff configuring system connecting multiple partners. The service-oriented architecture is a highly useful approach to realize the requirements given by the multitude of services used in the IPS²-ES. Internal as well as external service can be combined and choreographed for the ultimate aim of IPS² customer value delivery. The next step of research is to develop a prototype of an IPS²-ES to test and advance the developed approaches.

Acknowledgements The authors would like to thank the German Research Foundation (Deutsche Forschungsgemeinschaft, DFG, www.dfg.de) for funding their research within the pro-

References [1] Aurich JC, Clement MH, editors. Produkt-Service Systeme: Gestaltung und Realisierung. Berlin: Springer; 2010. [2] Durugbo C, Bankole OO, Erkoyuncu JA, Tiwari A, Alcock JR, Roy R, Shehab E. Product-Service Systems across Industry Sectors: Future Research Needs and Ch Industrial Product-Service Systems (IPS²): Proceedings of the 2nd CIRP IPS² Conference . In: Sakao T, Larsson T, Lindahl M, editors. Linköping: Linköping University; 2010, p. 535 542. [3] Meier H, Roy R, Seliger G. Industrial Product-Service Systems IPS2. CIRP Annals - Manufacturing Technology 2010; 59:607 627. [4] Meier, H, Kortmann, D, Uhlmann, E. Hybride Leistungsbündel: Nutzenorientiertes Produktverständnis durch interferierende Sach- und Dienstleistungen. wt Werkstattstechnik online 2005; 95:528 532. [5] Rese M, Meier H, Gesing J, Boßlau M. HLB-Geschäftsmodelle: Partialmodellierung zur Systematisierung von Geschäftsmodellen "Hybrider Leistungsbündel" (HLB). wt Werkstattstechnik online 2011; 101:498 504. [6] Sakao T, Berggren C, Björkman M, Kowalkowski C, Lindahl M, Olhager J, Sandin J, Sundin E, Tang O, Thollander P, Witell L. Research on Services in the Manufacturing Industry based on a Holistic Viewpoint and Interdisciplinary Approach Functional Thinking for Value Creation: Proceedings of the 3rd CIRP International Conference on Industrial Product Service Systems . In: Hesselbach J, Herrmann C, editors. Berlin, Heidelberg: Springer; 2011, p. 27 32. [7] Becker J, Knackstedt R, Pfeiffer D, editors. Wertschöpfungsnetzwerke: Konzepte für das Netzwerkmanagement und Potenziale aktueller Informationstechnologien. Heidelberg: Physica; 2008. [8] Meier H, Morlock F, Dorka T. Functional Specification for IPS²Execution Systems, in: Product-Service Integration for Sustainable Solutions: Proceedings of the 5th CIRP International Conference on Industrial Product-Service Systems . In: Meier H, editor. Berlin: Springer; 2013, p. 107-119. [9] Meier H, Völker O. Industrial Product-Service-Systems - Typology of Service Supply Chain for IPS2 Providing Manufacturing systems and technologies for the new frontier: The 41st CIRP Conference on Manufacturing Systems . In: Mitsuishi M, Ueda K, Kimura F, editors London: Springer; 2008, p. 485 488. [10] Völker O. Erbringungsorganisation hybrider Leistungsbündel. Aachen: Shaker; 2012. [11] Meier H, Völker O. Aufbau- und Ablauforganisation zur Erbringung hybrider Leistungsbündel Integrierte Industrielle Sachund Dienstleistungen: Vermarktung, Entwicklung und Erbringung hybrider Leistungsbündel . In: Meier H, Uhlmann E, editors. Berlin, Heidelberg: Springer; 2012, p. 137 161. [12] Meier H, Völker O, Funke B. Industrial product-service systems (IPS²). Paradigm shift by mutually determined products and services. The International Journal of Advanced Manufacturing Technology 2011; 52:1175 1191. [13] Scholz-Reiter B, Freitag M. Autonomous Processes in Assembly Systems. CIRP Annals - Manufacturing Technology 2007; 56:712 729. [14] Sanchez R, Mahoney Joseph T. Modularity, Flexibility, and Knowledge Management in Product and Organization Design. Strategic Management Journal 1996; 17:63 76.

369

370


[15] Wiendahl HP, Nofen D, Klußmann JH, Breitenbach F, editors. Planung modularer Fabriken: Vorgehen und Beispiele aus der Praxis. München, Wien: Hanser; 2005. [16] Meier H, Funke B. Planungsmethoden für den Betrieb hybrider Leistungsbündel Integrierte Industrielle Sach- und Dienstleistungen: Vermarktung, Entwicklung und Erbringung hybrider Leistungsbündel . In: Meier H, Uhlmann E, editors. Berlin, Heidelberg: Springer; 2012, p. 163 190. [17] Meier H, Funke B. Resource Planning of Industrial ProductService Systems (IPS²) by a Heuristic Resource Planning Approach Industrial Product-Service Systems (IPS²): Proceedings of the 2nd CIRP IPS² Conference . In: Sakao T, Larsson T, Lindahl M, editors. Linköping: Linköping University; 2010. [18] Schuh G, Hübbers M, Gudergan G. Structural Model of Resources in Product Service Systems - A Prerequisite to Portfolio Design Industrial Product-Service Systems (IPS²): Proceedings of the 2nd CIRP IPS² Conference . In: Sakao T, Larsson T, Lindahl M, editors. Linköping: Linköping University; 2010, p. 317 322. [19] Funke B. Adaptive Planungsmethode zur Terminierung der Erbringungsprozesse hybrider Leistungsbündel. Aachen: Shaker; 2012. [20] Abran A, Moore JW, Bourque P, Dupuis R, editors. Guide to the Software Engineering Body of Knowledge. Los Alamitos, Calif: IEEE Computer Society; 2004. [21] Schill A, Springer T. Verteilte Systeme: Grundlagen und Basistechnologien. 2nd edition. Berlin: Springer; 2012. [22] MacKenzie M, Laskey K, McCabe F, Brown P, Metz R. Reference Model for Service Oriented Architecture 1.0: OASIS Standard, Organization for the Advancement of Structured Information Standards (OASIS); 2006. [23] Brown P, Estefan JA, Laskey K, McCabe F, Thornton D. Reference Architecture Foundation for Service Oriented Architecture Version 1.0: OASIS Committee Specification Draft 03, Organization for the Advancement of Structured Information Standards (OASIS); 2011.