CC BY-NC-ND
0Available online at www.sciencedirect.com
SciVerse ScienceDirect
Procedia CIRP 7 (2013) 365 - 370
www. elsevier. com/locate/procedia
Forty Sixth CIRP Conference on Manufacturing Systems 2013
Architecture and Conceptual Design for IPS2-Execution Systems
Horst Meiera, Thomas Dorkaa, Friedrich Morlocka*
aRuhr-Universitat Bochum, Chair of Production Systems, Universitatsstr. 150, 44801 Bochum, Germany
* Corresponding author. Tel.: +49-234-32-29890; fax: +49-234-32-09890. E-mail address: morlock@lps.rub.de._
Abstract
Industrial Product-Service Systems (IPS2) 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 IPS2, i.e. the customer, the IPS2 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 IPS2-Execuion System, is presented. For this architecture, the structure of the IPS2 organization, among others, has to be taken into account.
© 2013 The Authors. Published by El sevier B.V.
Selection and peer-review under responsibility of Pro fes sor Pedso Filipe do Carmo Cunha
Keywords: Industrial Product-Service System (IPS2); Organization; Architecture; IPS2-Execution System; Software
1. Introduction
In the manufacturing industry, competitors are continuously struggling to differentiate themselves from other companies on the market. Industrial Product-Service Systems (IPS2) 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 IPS2 based on [4]:
"An Industrial Product-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 socio-technical system. "
According to [5], the IPS2 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 IPS2. During the phases proper tool and software support is required. [6] states that the tool and system support for the IPS2 provision is not sufficient, yet. In order to overcome this issue and to support the IPS2 provider during use phase an IPS2-Execution System (IPS2-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 IPS2-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 IPS2 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 IPS2, 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 IPS2
Due to the aforementioned paradigm shift from offering products or services to an IPS2 provision, an organization that is adapted to the requirements of IPS2 is needed. An IPS2 is a collaboration and cooperation platform and needs a partner network. This network consists of different roles. The network contains customer, IPS2 provider, IPS2 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
and service suppliers. For each IPS2, some of these partners are responsible for its delivery and therefore form the IPS2 network. An IPS2 delivery network for each delivery process is built from partners in the IPS2 network. The connection between the networks is presented in Figure 1 [9, 10].
The customer pays for the value of the IPS2 provided by the IPS2 provider. The business model, which may focus on functionality, availability or result of the IPS2, has an influence on this relationship. Depending on the IPS2 delivery, the customer may have to contribute his resources for the delivery processes. As the coordinator of the IPS2 network the IPS2 provider offers solutions to the customer and also represents the principle of "one face to the customer" The IPS2 module suppliers in the network coordinate a specific part of the IPS2 and take the risk for their processes. Last but not least component suppliers deliver parts or components while service suppliers deliver services directly to the customer. [9, 11]
Due to the IPS2 requirements and the IPS2 network, a high flexibility of the organizational structure is necessary. The hierarchical architecture of traditional organizational structures is inappropriate for dynamic IPS2 because of its restricted flexibility [12]. [11] analyzes a huge variety of organizational approaches like self-configuration [13] or modularization [14, 15]. He concludes that virtual organization units are most suitable for IPS2 networks. The suppliers in an IPS2 network are existing companies with their own business and organizational structure. To participate in an IPS2 network, they offer some of their resources to the IPS2 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 IPS2, the virtual organization units (VOU) communicate with each other. This communication is supported by an IPS2-ES [11].
2.2. Capacity and Resource Planning for IPS2
The IPS2 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 IPS2 capacity planning provides the resources which are needed for the service delivery during the operation of IPS2. 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 IPS2 product model. [12]
Due to the time horizon, the strategic capacity planning determines the needed resources to deliver the IPS2 in the future. There is a connection between the IPS2 capacity planning and the IPS2 organization. The required resource capacities have to be considered in the delivery network by the IPS2 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 IPS2 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 IPS2 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 IPS2 requirements. The IPS2-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 "service-oriented
Delivery Process
Provider Network
IPS2 Delivery Network
Fig. 1. IPS2 Networks
architecture". 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 "abstract framework for understanding significant entities and relationships between them within a service-oriented environment, and for the development of consistent standards or specifications supporting that environment." [22]. On top of that, [23] elaborates on the area between business and IT when working together in an SOA ecosystem.
3. Architecture and Conceptual Design for IPS2-Execution Systems
To provide a common understanding of IPS2-Execution Systems, the following can serve as a definition:
An IPS2-Execution System is the essential software system for the IPS2 operation phase that supports the IPS2 provider in the provision of customer value by adaptive IPS2 delivery planning, IPS2 network management and an integrated performance measurement method.
This is accomplished by interacting with other software systems for IPS2 (e.g. the IPS2-Control Systems and the IPS2-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 IPS2 provider network, i.e. IPS2 provider, IPS2 customer and IPS2 supplier, and connects the partners individual software systems to gather information for the IPS2 delivery and provide necessary data to each partner. The partners are represented as VOU inside the IPS2-ES. To be able to handle this complex automated system and provide a high-level overview for the systems users, an integrated performance measurement method provides execution data and ensures the intended effect of the IPS2-ES on the customer value delivery.
Using the aforementioned as a basis, the architecture of an IPS2-ES has to support the special organization form of IPS2, namely virtual organization units, provide the IPS2 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 IPS2-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 IPS2-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 IPS2 provider, IPS2 customer or one of the IPS2 suppliers. Additionally, the set of suppliers and thus the set of software systems are changing during the runtime of the IPS2-ES. Hence, the architecture has to be able to handle these changes and to provide a consistent view of the data used in the IPS2-ES. Therefore, each set of software systems of one participant of the provider network is realized by one component in the IPS2-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 IPS2 organization (i.e. provider network, IPS2 network and IPS2 delivery network) can be digitally formed and information exchange is supported.
Using the aforementioned data exchange, the information required for adaptive IPS2 delivery planning can be acquired. The planning itself is integrated into the IPS2-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 IPS2 arise. Second, the service can be reused for multiple IPS2-ES and can be moved to a high-performance computing environment (e.g. cloud-computing system), if required.
For the IPS2 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 IPS2-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 IPS2-ES has to use even more complex methods to support the IPS2 delivery. However, this complexity in turn makes it harder to see whether the intended effect of the IPS2 delivery is realized and which factor of the IPS2 delivery (e.g. planning method, network partner, resource, etc.) is responsible for any unwanted effects.
To solve this dilemma, the IPS2-ES integrates the performance measurement method (PMM).
The PMM monitors three aspects connected to the IPS2-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 IPS2-ES, however, it relies on the external environment (i.e. available resources, possibility for process replacements, etc.) determined by the IPS2 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 IPS2 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 IPS2-ES, which are influenced externally.
To support the abovementioned functionality, several external services and systems have to be integrated in or connected with the IPS2-ES. Internet-based route planning services are available for use by the IPS2 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 IPS2-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 IPS2 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. IPS2-Control Systems (IPS2-CS) monitor each IPS2 with a software agent system including condition monitoring agents and report unplanned demands (e.g. repairs) to the IPS2-ES. The IPS2-ES has then to execute operational resource planning to include the required process in the delivery plan. The IPS2-Lifecycle Management System (IPS2-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 IPS2, it can be stored in the IPS2-LMS for access by other systems or actors. A knowledge management system for IPS2 can derive knowledge from delivery plans and their changes.
A schematic overview of the IPS2-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 software 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 IPS2 delivery is achieved.
IPS2 customer
_ Jerp MES^) [
Fig. 2. IPS2-Execution System — Schematic Overview
The intended architecture of the IPS2-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 IPS2-ES in so-called WApps [8]. Each WApp covers a different part of the IPS2-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 IPS2-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 IPS2 network partners. Other services in the lower service layer may wrap external services for access by IPS2-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 IPS2-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 IPS2-ES.
IPS2-Execution System-Software Layer
Web-based Graphical User Interface (GUI)
IPS2-specific Service Layer (High LeveJL
Planning Service 1 PMM Service ■ -
Service Layer (Low Level)
MiddlewareLayer
Cloud-System-Layer
External Systems
ERP, MES, SMS,...
Route Planning Services
Logistic Services
IPS2-Control System
Physical Layer (Hardware)
Fig. 3. Layered Architecture of an IPS2-ES in a Cloud Environment
4. Conclusion
In this paper, a new architecture and a conceptual design for IPS2-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 self-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 IPS2-ES. Internal as well as external service can be combined and choreographed for the ultimate aim of IPS2 customer value delivery.
The next step of research is to develop a prototype of an IPS2-ES to test and advance the developed approach-
Acknowledgements
The authors would like to thank the German Research Foundation (Deutsche Forschungsgemeinschaft, DFG, www.dfg.de) for funding their research within the project Transregio 29 "Engineering of Industrial Product-Service Systems" (www.tr29.de).
References
[1] Aurich JC, Clement MH, editors. Produkt-Service Systeme: Gestal-
tung 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^lOTges, in: "Industrial Product-Service Systems (IPS2): Proceedings of the 2nd CIRP IPS2 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:607627.
[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, in: "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öpfungsnetz-
werke: Konzepte für das Netzwerkmanagement und Potenziale aktueller Informationstechnologien. Heidelberg: Physica; 2008.
[8] Meier H, Morlock F, Dorka T. Functional Specification for IPS2-
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 in: "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. Aa-
chen: Shaker; 2012.
[11] Meier H, Völker O. Aufbau- und Ablauforganisation zur Erbringung hybrider Leistungsbündel, in: "Integrierte Industrielle Sach-und 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 (IPS2). 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.
[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, in: "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 Product-Service Systems (IPS2) by a Heuristic Resource Planning Approach, m: "Industrial Product-Service Systems (IPS2): Proceedings of the 2nd CIRP IPS2 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 and Planning, in "Industrial Product-Service Systems (IPS2): Proceedings of the 2nd CIRP IPS2 Conference'. In: Sakao T, Lars-son 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.
