Juhani Heilala

Reino Ruusu

Jari Montonen

Saija Vatanen

Carlos Kavka

Fabio Asnicar

Sebastian Scholze

Alberto Armiojo

Mario Insunza

Eco-Process Engineering System for Collaborative Product Process System Optimisation

Keywords: product service system, life-cycle optimisation, collaborative space

Eco-Process engineering system (EPES) means systematic collaborative eco-efficiency and eco-innovation aspects in product service system (PSS) development and management, and covers all life-cycle phases. It is an ICT tool and related application methodology. The development focus on PSS from functional and cost performance is currently enhanced with sustainability aspects. The goal is to create more value with less environmental impact. In the virtual factories, extended enterprises, the collaboration between different stakeholders, engineers, managers, users of the PSS is a must and all actors in the value chain need a common goal. EPES system provides a collaborative space, covering common data and functionalities for knowledge management, multi-objective decision making, simulation and optimisation. Coordinated evolution (co-evolution) of products, processes and services creates competitive advantage. This paper shows a prototype of EPES system. The software building blocks of EPES system are illustrated as well methodology steps in setting up system and using it.

Introduction

The focus of product, process or service design is currently rapidly widening to include additional goals related to sustainability, especially in the field of energy and energy-intensive industry [START_REF] Baños | Optimization methods applied to renewable and sustainable energy: A review[END_REF]. In addition to economic, functional performance, product, process and service quality and marketability issues, new social and environmental aspects are increasingly taken into account.

Examples of the drivers of this development are: Cost savings, resource efficiency, regulations set by society, directives, standards, also customer requirements and communication, business reputation and so on. The eco-constraints, e.g. resource efficiency, energy consumption, emission, hazardous waste, etc., need to become a part of the wider assessment of the overall Product, Process and Service (PPS) feasibility analysis, engineering development and management.

The nature of sustainability as a holistic viewpoint presents a need for complex multi-objective decision-making, in which compromises need to be made between mutually exclusive criteria. Additionally all the stages of the life cycle of a product service system need to be taken into account in the development stage. This greatly increases the quantity of good-quality data that needs to be presented to decisionmakers. This data is not only hard to collect but subject to continuous change, due to technological development [START_REF] Seung | Economic and environmental assessment of product life cycle design: volume and technology perspective[END_REF].

In order to address complex multi-objective decision-making in a distributed world of the extended enterprise, flexible tools that provide support for knowledge management, communication, co-operation and business process management are needed [START_REF] Kleindorfer | Sustainable Operations Management[END_REF]. Service-oriented ICT tools are one enabler for efficient networking. A need for efficient Business Process Management (BPM) arises to orchestrate the activities carried by the various actors that do not necessarily fit within a single productoriented organizational structure.

Selection of the best design among a set of alternatives is a very important task in the development stage of a PPS. Modelling and simulation techniques are necessary in order to account for future effects of design decisions.

In most engineering environments, designers need to be encouraged to integrate environmental aspects by increasing the availability of suitable tools and knowledge. Integration of sustainability aspects to various simulation models is still rare [START_REF] Thiede | Environmental aspects in manufacturing system modelling and simulation-State of the art and research perspectives[END_REF]. One example of development is shown in [START_REF] Heilala | Discrete Part Manufacturing Energy Efficiency Improvements with Modelling and Simulation[END_REF]. In short, the main requirements should include: A simple and easy to use method; Availability of appropriate data; Clear and easily communicable results; and Traceable conclusions.

Above all, any tools or information deployed as part of Design for Environment (DfE) should be fully integrated in an existing design process, procedures and manuals. Environment aspects should become a new key parameter to consider in decisionmaking, alongside technical performance, safety and cost [START_REF]Design for Environment, Airbus Corporate Answer to Disseminate integrated Environmental Management sYstem (ACADEMY)[END_REF].

In the EPES project, a software service platform is created for bridging the gap between design-oriented tools, such as CAD and CAE, operations and service planning tools and tools for managing the business decision-making. Partially this is the traditional domain of PLM systems, most of which are, however, quite costly and inflexible.

The idea of EPES is to provide the users with a product-process-service (PPS) development-oriented "collaborative space" that can be organized by its users without customization by a software vendor, but allowing a level of integration of tools and databases that is not available on general purpose collaboration platforms.

New way of working

The EPES project is developing a comprehensive software platform that allows engineering issues to be addressed from the multiple points-of-view of sustainability. The EPES system is an integrated Enterprise Content Management (ECM) and Business Process Management (BPM) platform that provides general advantages as an engineering and/or decision-making platform [START_REF] Sorli | EPES: Engineering System for Optimization of Product Lifecycle through Adapted Eco-services[END_REF][START_REF] Scholze | Eco Process Engineering System for highly customized industrial products, processes and services[END_REF][START_REF] Heilala | Product Concept Manufacturability and Sustainability Assessment with Eco Process Engineering System[END_REF][START_REF] Scholze | Context-sensitive decision support for improved sustainability of product lifecycle[END_REF]. Its focus is on efficient interdisciplinary co-operation, communication, data collection and management. It also serves as a tool for communication between the engineering community and the strategic decision-makers, allowing them to make informed decisions at the earliest stages of the PPS development and management.

The platform provides functionalities for:

 Knowledge Management, in the form of an enterprise content management system, which is augmented with a semantic context database for providing additional meta-data  Business Process Management, in the form of a BPM platform on which complex processes can be modelled using BPMN 2.0.  IT service automation that provides additional support for meta-data collection and processing and automating the execution of complex computational processes for producing the key performance indicators that are needed for decision-making.  Multi-objective simulation and optimization, in the form of an integrated state-of-the art solution.  Business Intelligence, in the form of a data integration and analytics platform.

In order to provide maximum accessibility in a distributed environment, the platform is built to be operated in a strictly browser-based user interface.

In the EPES project business cases, the core eco-efficiency objectives are: Increase product or service value, optimizing the use of resources, and reduce environmental impact. The business cases are diverse, and include electric grid design and operation, wind turbine maintenance operations and aircraft wing design from the point of view of manufacturability (see chapter 4).

The overall EPES reference architecture schema is illustrated in EPES is separated into a three-layered structure that complies in every layer to a service oriented approach. Three layers are: Data tier, Business Tier and Presentation tier (see Fig 1 .).

Based on the service-oriented development approach, that represents several different processes as services that are fully interoperable and allow further re-use for specific process reoccurrences. All layers of the EPES system concept are seen as a part of an overall service structure so that every component could interact with each other, but is additionally focused around specific transition services.

The EPES system is built upon the following core services, VCN, SGM, DMM and SM (see Fig 1 .).

Virtual Collaborative Network (VCN):

The VCN main functionality is to provide a main point of access for non-expert end-users through user interfaces, including capabilities for supporting the aggregated Graphical User Interfaces (GUI) provided by the Service Generator. It provides the technical infrastructure for the distribution of users into groups; content management and sharing mechanisms; workflow engine for contents production, consumption and transformation. In addition, the VCN provides a Knowledge Base, containing actual data, historical data, identified constraints and objectives from collaborative networks, KPIs and Life-Cycle Inventory data.

Service Generator (SG): The Service Generator's main functionality is creating, updating, and deploying configurations for application-specific services. It interacts with the Simulation Module and the Decision Making Module to compute parameters for updated configurations. The SG can also store / retrieve configurations in/from the Virtual Collaborative Network. Finally, the SG allows identification of contextual information about EPES solution operators as well as connected legacy systems.

Simulation Module (SM):

The simulation module of the presented platform provides a capability for running numerical analyses related to the life-cycle assessment process. It provides simulation services through an abstract service interface that allows higher-level components of the platform to use simulation as an interchangeable service, according to the principles of the Service Oriented Architecture (SOA) design paradigm. It allows the other modules to present configuration options and numerical parameters of simulation modules without any prior knowledge of the internal structure of the model.

Decision Making Module (DMM):

DMM is an interactive system intended to help decision-makers to use data and models to identify and solve problems and to make decisions. On the one hand, there will be some traditional indicators for measuring the overall PSS performance, but on the other hand, there will be new KPIs established and defined in the DMM. These KPIs will be traced to the measured constraints, and the DMM will show, where the constraints are, and how to measure the performance of the organization, in order to take the best decision in a range of values proposed by the SM taking into account the localized constraint. The KPIs taken into consideration will mostly reflect eco constraints. Inputs from the SM will support the decision process, by simulating the potential evolution of relevant KPIs and allowing thus taking informed decisions.

EPES prototype

The existing EPES prototype platform makes use of many existing solutions as parts of its integrated comprehensive platform. These solutions include:  Alfresco: An Enterprise Content Management (ECM) system  Activiti: A business process modelling and execution framework  SOMO by ESTECO: An optimization and simulation integration platform  Pentaho: A business intelligence platform.

Additional software components have been developed in order to facilitate the integration of these existing solutions. The solution is cloud based and collaborative space user needs just a browser.

Fig. 2. EPES Methodology main steps

The main steps in the EPES methodology (see Fig. 2.)

Collaborative work environment definition, strategic level 2. Collaborative project planning, operative level 3. Business Process Management cycle, operative level

The main concept of organization of work in the EPES platform is the "collaborative space". This is a concept that is quite similar to the concept of workspaces on platforms like Microsoft SharePoint, including both data and business process (or workflow) models, but provides additional functionality in the sense of configured computational services e.g. simulation and optimisation, that can operate directly on structured data files on the underlying content management platform.

Each collaborative space can also contain a customized semantic database of contextual data, which is used for organizing and linking together a possibly complex set of data, users, services and business processes. This context data provides a structured view of the contents of the collaborative space simultaneously from multiple points of view.

Each collaborative space is typically built to manage activities related to a product or a family of products or services. It involves data that is shared between different organizational units, such as marketing, business analytics, design, engineering and use and service e.g. maintenance activities. The goal is to avoid any need to keep data on personal or group-accessible repositories.

A methodology has been developed for managing the collaborative space. It is advisable to establish the collaborative space right at the planning stages of a project, and to maintain it to the end. In the case of product development, the collaborative space can live and adapt to the needs of the organization throughout the stages of the product life-cycle.

All content in a collaborative space is version-controlled. A collaborative space, or parts thereof, can be easily branched by creating a copy. This eases the parallel development of product alternatives, of which the best one can be selected at a later stage. Some collaborative spaces are not used for projects, but for continuous activities, in which case the methodology proposes a business process management cycle of continuous improvement.

This work environment can be extended beyond the group of people who directly participate in the development processes. This enables, for example, a more direct form of feedback from the users to the engineers. It also connects varies engineering disciplines, group of engineers and managers.

Each of the actors in the defined Collaborative Spaces system has a role. The role could be, for example, an owner of the product, a user of the product, a service provider, a manufacturing or product-related engineer, a sales representative or a business decision-maker. Using the collaborative parts of the EPES system, any group of actors in the product service system community can distribute knowledge, collaborate, pin-point eco-constraints, bottlenecks and solve problems.

EPES Use Cases

The presented EPES approach is being applied in three industrial business cases (BC), to validate the proposed decision making solution within different application domains, as listed here. BC1: Engineering maintenance services for optimizing maintenance and increasing availability of wind turbines. The decision processes involved here deal with the best scheduling of maintenance tasks to be taken for optimal maintenance of multiple wind turbines. The decision making and optimisation constrains include, service and operation history, weather conditions and forecast, availability of service resources and so on.

BC2: Power grid control systems for improved identification of improved monitoring of grid load and safety limits. Smart cable has features for temperature detection and monitoring at any point of the cable. Decision support methods are supporting the user in detecting trends in the grid load, ensuring thus that good load balancing deci-sions will be taken. Also new cable design is supported, e.g. material saving has multiple impacts on manufacturing, logistics and installation of cable network.

BC3: Support for optimized design and manufacturing of aircraft wings. Here, the decision support system addresses the optimal layout of manufacturing facilities in the conceptual design phase. User can fix some of the parameters of the facility, i.e. work shifts, cycle times and capacity, and the optimization returns the numbers of required facility elements; resources, personnel etc. The production data is aggregated with sustainability data to enable optimization in environmental point of view.

Summary

Sustainability-related issues are important and they are adding heavily to the complexity of the design process. The amount of data that is needed for decision-making is growing and multiple parameters and constraints must be considered simultaneously. Because multiple engineering disciplines, multiple actors and multiple life cycle stages are involved in the goal of sustainability, multidisciplinary optimisation (MDO) and multi-objective optimisation (MOO) techniques can seldom be avoided. When these techniques and tools are provided as services, the transparency and traceability of the decision making processes can be improved. The EPES platform is a tool for managing both technically and organizationally complex tasks in a distributed organizational environment, such as virtual factory. The platform combines existing enterprise IT tools into a platform that is flexible and configurable and supports the simultaneous management of knowledge from multiple viewpoints.

Provision of engineering analyses and optimisation as services is one of the advantage of the EPES platform. When combined with knowledge management, communication and collaboration, business intelligence, and business process modelling and execution, a comprehensive platform is created. Instead of several desktop applications, engineering islands of analysis, the EPES system provides both integration and automation of the assessment methods that are necessary for tackling sustainability aspect.

Instead of directly addressing sustainability, the focus of the platform is on streamlining the processes and integrating the existing tools that are necessary for addressing it. In practice, by reducing the amount of required effort, the application of the solution also results in more sustainable outcomes, by allowing the enterprise to more efficiently use the available engineering resources, both human and computational.

The EPES approach is assessed in three companies from different sectors (wind farm maintenance, cable production and aeronautics), which represent typical examples of companies in need for such highly reconfigurable services to continuously optimize product performance and service delivery.

The maintenance and other services of industrial products, investment goods or design of complex, multi-disciplinary engineering products and collaborative product process service development are promising application areas for the EPES system.

EPES system is an enterprise application, thus it needs customization and integration to existing legacy and other engineering systems. First time service set-up, and integration requires high expertise. Exploitation plans of the development is ongoing Acknowledgements. The research presented in the paper has been carried out within the frames of the EPES, "Eco-Process Engineering System for Composition of Services to Optimize Product Life-Cycle" collaboration project, (www.epesproject.eu) co-funded by the European Commission under FoF-ICT-2011.7.3-285093 contract. The authors wish to express the acknowledgement to EC for the support and to all project partners for their contributions during the development presented in this paper. This document does not represent the opinion of the European Community, and the European Community is not responsible for any use that might be made of its content.

Fig. 1 .

 1 Fig. 1. EPES Architecture Schema.


Esmond Claire Palmer
email: c.palmer3@lboro.ac.uk

Neil Urwin
email: e.n.urwin@lboro.ac.uk

Jose Miguel Pinazo-Sánchez

Francisco Sánchez Cid
email: cid@iti.es

Sonja Pajkovska-Goceva
email: sonja.pajkovska-goceva@ipk.fraunhofer.de

Robert Ian Marr

Esmond Neil Urwin

Reference Ontologies to Support the Development of New Product-Service Lifecycle Systems

Keywords: product lifecycle management, global production networks, reference ontologies, interoperability, product service lifecycle systems

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

The nature of competition dictates rivalry and in the domain of manufacturing indu stry the act of competing for supremacy in the design, production and selling of products. The 21st century information age is forcing manufacturers to act differently to compete successfully and find different ways in which to not only source and manufacture products but also configure and then sell them to customers.

The servitisation of products i.e. 'the increased offering of fu ller market packages or 'bundles' of customer focused combinations of goods, services, support, selfservice and knowledge' [START_REF] Vandermerwe | Servitization of business: adding value by adding services[END_REF] is proving to be an enticing form of selling products via services to customers. Whilst the benefits can be seemingly apparent and instant, the actuality is that there are many additional components that are necessary.

The challenge for manufacturing industry which is servitising products is, what is the most effective way to design, produce and sell a product together with it associa ted service co mponents effectively, to form a Product-Serv ice System (PSS)? At the heart of this is how to align and integrate a tradit ional product lifecycle viewpoint with a more modern service lifecycle to develop a Product-Serv ice Lifecycle System (PSLS). Additional comp lexity is added to this approach when Global Production Networks (GPN) are to be configured and reconfigured and in the face of rapid ly changing product-service requirements. By employing a GPN, o rganisations can adopt technology at a faster pace, lower costs and be more open to change [START_REF] Pubs | Integration definition for function modelling (IDEF0)[END_REF]. But an important aspect must be considered carefully, that of informat ion interoperability between suppliers, manufacturers and service provision mechanisms. This becomes paramount when configuring sizeable and diverse GPN across potentially large geographical areas and between widely varying domains and contexts. It can introduce a wide and varied range of risks and perturbations fro m diverse system p rocesses and capabilit ies, to different legislation and laws. One such method that can mitigate these risks to information interoperability is the use and application of ontological reference models.

What can be derived fro m this is that organisations are tasked with providing p ro duct lifecycle management (PLM) approaches and solutions to enable the sharing, use and reuse of information and knowledge, the main objective of this being to achieve and maintain co mpetitive advantage for their Product-Serv ice Systems [START_REF] Young | Enabling interoperable manufacturing knowledge sharing in PLM[END_REF]. They must be able to react to change and understand the balance of possible options when ma king decisions on complex mu lti-faceted problems, GPN is one such domain in wh ich this applies.

Two interesting formal reference ontologies for interoperability have been put fo rward, those of the Interoperable Manufacturing Knowledge Systems (IMKS) p roject [START_REF] Chungoora | The configuration of design and manufacture knowledge models from a heavyweight ontological foundation[END_REF] and the Manufacturing Core Ontology (MCO) [START_REF] Chungoora | Towards the ontology -based consolidation of productioncentric standards[END_REF]. These concern the design, manufacturing and assembly of a product, as such they do not include or allow for PSLS nor GPN. What is highlighted by this is the need to develop formal reference ontologies to help develop, implement and ameliorate interoperability within PSLS when employing a GPN.

The premise of this paper is to put forward the notion that the application of formal reference ontologies to a domain and its related information requirements so as to enhance and accelerate the development of new PSLS with a view towards the seamless interchange of information or interoperability between systems and domains. This approach is being developed as part of the research being undertaken in the EU FP7 FLEXINET project. This paper is structured as follows. Section 2 discusses the FLEXINET p roject and its purpose. Section 3 sets out the methodological approach and development of reference ontologies for product-service lifecycle systems. Section 4 draws the paper to a close with conclusions and further work.

The FLEXINET View

FLEXINET aims to support decision-making in the early design of global production network configurations based on the implementation of new comp lex technologies. FLEXINET will apply advanced solution techniques to the provision of a set of Intelligent Production Network Configuration Serv ices that can support the design of high quality manufacturing networks, understanding the costs and risks involved in ne twork re -configuration, and then mitigating the impact of system incompatib ilit ies as networks change over time. These are fundamental requirements for high quality decision-making in the early design of intelligent manufacturing system networks. These innovative concepts will enable a fast and efficient response to market variations and be easily adaptable across industrial sectors. The FLEXINET concept is illustrated in Figure 1.

FLEXINET takes the view that new manufacturing business modelling methods are needed that can model business cases and identify the critical network relations that underlie the business operation. Such methods and models are essential to the ability to define both the production network knowledge that must be captured and the queries that must be made if new business configuration possibilit ies are to be evaluated. Product servitisation adds to the complexity of this problem as the relationships between product lifecycles and service lifecycles also need to be understood and their impact on production system networks specified within the resulting business models.

The main aims of the FLEXINET ontological research are the following, (i) doc ument key semantic concepts, knowledge constraints and inter-relationships in the context of g lobalised production networks, (ii) structure and formally model concepts, relationships, constraints and related facts to provide an underpinning environment against which specific network configuration designs can be evaluated and (iii) develop methods for ontology querying fro m wh ich to evaluate the co mpliance of potential production network configurations from both OEM and SME perspectives.

A Reference Ontology for Product-Service Lifecycle Systems

The starting point for the development of the FLEXINET fo rmal reference ontology for product-service lifecycle systems has been three industrial case studies which have provided a solid base for the elicitation and capture of informat ion and knowledge. In addition to this, the work fro m the Interoperable Manufacturing Knowledge Systems (IMKS) pro ject, the Manufacturing Service Ecosystem (MSEE) pro ject and the Manufacturing Informat ion ontological model set out by Hastilow [START_REF] Hastilow | An Ontological Approach to M anufacturing Systems Interoperability in Dynamic Change Environments[END_REF] is being assessed for applicability to the GPN and PSLS domains.

The FLEXINET approach focuses on the intelligent configuration of a network of products or product-service systems, to support interoperability between systems and domains the approach utilises a core foundation ontology. To enable ease of co nstruction and to facilitate re-use across domains the FLEXINET ontology is organised into five levels, as illustrated in Figure 2. Each level inherits concepts from and provides additional concepts to the level above, the ontology becoming mo re do main specific with each level. Five levels are needed to specialise the concepts from the foundation to the specific domains . Figure 2 shows examp le domains at each level, the scope of FLEXINET being indicated in white.

Figure 2. The FLEXINET ontology levels

Level 0 Core consists of foundation concepts applicable to all do mains, having nothing to do directly with Product-Service Lifecycle Systems. The foundation concepts include t ime, events, aggregation and lists and are derived fro m the Highfleet Upper Level Ontology (ULO) [7]. Level 1 contains the few key concepts necessary to model any system. A system transforms inputs into outputs and is defined as "a combination of interacting elements organized to achieve one or more stated purposes" [START_REF]Systems and Software Engineering -System lifecycle processes[END_REF]. Level 2 uses Banathy's classification [START_REF] Banathy | A systems view of education: Concepts and principles for effective practice[END_REF] to specialise systems into "Natural Systems" and "Designed Systems". Natural systems are liv ing systems of all kinds, the solar system and the Universe. Designed systems are man-made creat ions, including fabricated physical systems, conceptual knowledge and purposeful creations. FLEXINET will provide decision support for product lifecycle management and, as this requires human input (i.e. input fro m a living system), the scope of FLEXINET covers purposeful creations and overlaps into natural systems.

Level 3 further differentiates designed systems, FLEXINET being concerned with Manufacturing Business Systems which are specialised within Level 4. At this level FLEXINET considers Product-Service Lifecycle Systems, imp lemented as Global Production Networks. The lifecycle phases are denoted as design, produce, operate and end of life (including disposal, recycling and remanufacturing). The focus of FLEXINET is how to design a GPN to produce and operate a product -service. The main area FLEXINET considers within the Product-Service Lifecyc le is "Produce" (producing the product) but the scope also overlaps into "Design" (of the network) and "Operate" as the operation of the product and the service needs to be considered. Level 5 applies Level 4 to case studies creating enterprise specific do mains.

Figure 3 sets out the level 1 ontology. It applies the Un ified Modelling Language (UM L) [START_REF] Om G | OMG unified modeling language (OM G UM L), superstructure and infrastructure version 2[END_REF] technique to describe the details about the concepts and relations necessary to specify a system. Th is ontology level utilises the concept TimeSpan (inherited fro m Level 0) and contains two parent concepts: Basic and Ro le. A TimeSpan includes the first and last instants of a date and all the instances in between [7]. A Basic concept [START_REF] Kozaki | Ontological analyses of roles[END_REF] is independent of the system or context, its defin ition does not depend on another concept and an instance of a Basic always retains its identity as such. Examples of Basic are information and material. A Basic can be co mprised of Basics, e.g. "bottled water" is comprised of the materials "bottle", "cap" and "mineral water". A System is subtype of Basic and provides a context for the Roles it cont ains (shown via the "depends on" relation and the composition filled diamond in the figure).

The defin ition of a Ro le depends on a context, an instance of a Role cannot exist without a context and the playsRole relation is transitory. For examp le, a person Joe has a Role as a lecturer (context "university") and changes Role to a consultant (context "enterprise"), whereas the Basic "bottle" is always a "bottle". It can be seen that a lecturer Ro le cannot exist without the university context, if the univ ersity closes the lecturer role ceases to exist. Roles may be co mp rised of Ro les (e.g. a lecturer Ro le may be comprised of administration, teaching and staff Roles). A Basic can play mo re than one Role at the same time (e.g. a person could be a le cturer and a parent). A Role can be played by more than one Basic, e.g. the role of a laundry would require a washer and a drier. There is no requirement for a Basic to play a Role (shown by the 0..* multip licity next to the Role concept in the figure). Role and Basic concepts exist separately and have separate identities. There is also no requirement for a Ro le to be played by a Basic, enabling empty Roles to be modelled (e.g. if a person Joe left his Role as a lecturer the Ro le would still exist as a lecturer vacancy).

A Basic may affect the state of a ro le, e.g. the size of a Basic "bottled water" playing the Role of a product could influence the d imensions required for a packing resource Role. Additionally a Role may affect the state of a Ro le, e.g. within the lectu rer Role more duties allotted to the administration Role would cause duties to be removed from the teaching Role).

The four key Ro les which describe a system are input, output, resource and control. An input represents what is brought into and is transformed or consumed by the system to produce outputs. An output represents what is brought out from or is produced by the system. A resource is used by or supports the execution of the system. A control is a condition required to produce correct system output [START_REF] Pubs | Integration definition for function modelling (IDEF0)[END_REF]139].

Conclusions and Furtherwork

This paper has illustrated a lightweight reference ontology for Product-Service Lifecycle Systems co mprised of a higher level core or foundation ontology that can act as a base for the generation and building of formal reference ontologies, not only for global production networks but other domains that are related and have potential for interoperation. The research approach and ideas put forward are actively being developed against a set of formalised FLEXINET industrial end user requirements and needs. Moreover the FLEXINET ontological research objective of 'define reference ontologies from which to base the flexible re-configuration of globalised production networks' is helping guide and focus the approach.

Further development of the reference ontology is needed against the FLEXINET industrial end user requirements, together with the IMKS [START_REF] Chungoora | The configuration of design and manufacture knowledge models from a heavyweight ontological foundation[END_REF], MSEE and MCO [START_REF] Hastilow | An Ontological Approach to M anufacturing Systems Interoperability in Dynamic Change Environments[END_REF] ontologies to expand, refine and advance the research. When this has been achieved it will then be necessary to test the FLEXINET reference ontology utilising industrial informat ion and knowledge to verify the approach and validate it against the end user requirements, this will provide valuable feedback to further enhance the approach.

Figure 1 .

 1 Figure 1. The FLEXINET Concept: Intelligent Production Network Configuration Services.

Figure 3 :

 3 Figure 3: FLEXINET Level 1 Systems Ontology A Basic p lays a Ro le for certain TimeSpans, modelled in the ternary relation "playsRole". For examp le in the context of a manufacturing organization system, the Basic "bottled water" can play the Role of a Product during the TimeSpan of the sy stem. With in a University a person could play the Role of a lecturer for a TimeSpan of five years, beco me unemp loyed and then play the Role of a lecturer again for a further TimeSpan.A Basic can play mo re than one Role at the same time (e.g. a person could be a le cturer and a parent). A Role can be played by more than one Basic, e.g. the role of a

Acknowledgements

We wish to acknowledge the FLEXINET consortium and especially the financial support fro m the Eu ropean Union Seventh Framework Programme FP7-2013-NMP-ICT-FOF (RTD) under grant agreement no 688627.


Serm Kulvatunyou

Evan Wallace
email: ewallace@nist.gov

Nenad Ivezic
email: nivezic@nist.gov

Yunsu Lee
email: yun-su.lee@nist.gov

Toward Manufacturing System Composability Analysis: A Use Case Scenario

Keywords: computer integrated manufacturing, service-oriented manufacturing systems, industrial automation, smart manufacturing, functional ontology

Smart manufacturing system will be able to quickly adapt to new and changing requirements, implying that software and hardware components of the manufacturing system need to be easily recomposed. In addition, provision of software applications and components is trending toward distributed, heterogeneous, and cloud-based. However, engineers who need to compose a software system will have difficulty finding and using software components with the right functionality and compatibility without a standard to describe these software components. This paper identifies the need for a reference functional ontology to provide a common way to describe a software component functionality. Such an ontology would lead towards the needed standard to describe the software components. The objective of this paper is to discuss high-level requirements for such a functional ontology and provide an initial use case to illustrate how the functional ontology may enable composability analysis.

Introduction

Smart manufacturing (SM) systems are characterized by the ability to quickly adapt to new and changing requirements induced by disruptions and disturbances [START_REF] Smlc | Implementing 21st century smart manufacturing[END_REF]. For this reason, SM systems are expected to be dynamically composed from networkconnected devices and software components. This would allow SM systems to gather and analyze data from these devices and software components and adapt themselves to respond to disruptions and disturbances [START_REF] Pellet | Lessons learned from chief executive's manufacturing summit[END_REF][START_REF] Floerkemeier | Preface to the IOT Conference 2008[END_REF]. The ability to dynamically compose software components is complicated by the proliferation of network-connected devices (also known as Internet of Things) and the increasingly available software in cloud marketplaces such as Oracle Marketplace, SAP HANA Marketplace, and Nimbis Marketplace 1 . With such marketplaces, virtually any individual can develop and provision software components. Such an open market environment will create heterogeneous, yet overlapping offerings of software components in terms of their functionalities (the things components can do) and compatibility (the technical and pragmatic aspects of components that affect how they can work together). To effectively deal with such heterogeneity we propose to develop a reference functional ontology that leads to a standard that will facilitate common understanding of software component offerings. The objective of this paper is to outline requirements and methodology to develop such a reference functional ontology. Through a use case illustration, the paper demonstrates the application of the ontology to composability analyses and identifies future research direction.

Composability analysis supports the finding and evaluation of components that can be functionally and technically combined to perform a desired task. We envision that tools and methods for composability analysis will be developed to assist system and software engineers in composing SM systems. This analysis may also provide additional information, such as identification of additional components necessary for their interoperation.

For the purpose of clarity, we introduce a few working definitions of essential concepts that will be used in the rest of the paper. Components can be either software or hardware; however, for this initial investigation, this paper focuses only on software components. In this research, service orientation [START_REF]OASIS Reference Model for Service Oriented Architecture 1[END_REF] is adopted as a predominant paradigm for manufacturing system composition. That is, software components expose their functionalities through services. For this reason, service is the focal point in the rest of the paper (rather than component).

Fig. 1. A service-oriented concept diagram

Fig. 1 illustrates the concepts related to service that will be used in the rest of the paper. A service provides functionalities. Functionality is the ability to do things that is described by a functional description. Functional description (e.g., validate engineering change order) is typically included in the service description that also includes other technical details and constraints (e.g., message exchange pattern, communication and security protocols) about how to access the service through an interface. We label these technical details non-functional description. Functional and nonfunctional descriptions are described with a set of characteristics that are essentially a set of properties. In this paper, we stress the importance of the functional description part that is much less developed than the non-functional description part (although both should be formalized). Therefore a reference functional ontology should be developed that provides characteristics or properties for the functional description.

In the following sections, we briefly introduce the service-orientation. Then, highlevel requirements for the ontology are provided in the form of competency questions. We outline the vision of how the ontology should be developed and maintained. Finally, an integration use case which illustrates the usage of a reference functional ontology is provided before giving the conclusion and describing future work.

Service Orientation

For software components to work together, the trend is to allow access to functions provided by these software components as services (hence a service can be viewed as a wrapper of a function or functions). This trend has accelerated recently with the arrival of cloud computing, which virtualizes computing and communication resources. That is, service consumers do not need to know how service providers offer their servicesfrom where, by which, or by how many software components. The service-oriented paradigm is essential to enable SM systems as it emphasizes visibility and semantics that enable (1) matching between needs and functionalities, and (2) composition of service functionalities to address those needs. The visibility and semantics are enabled by service descriptions and service contracts that capture the essential information the service consumers and providers need to be aware of and agree upon [START_REF]OASIS Reference Model for Service Oriented Architecture 1[END_REF].

Functional Requirements for Functional Ontology

This section discusses high-level functional requirements for a reference functional ontology. For practicality, we divide the requirements for semantically rich functional description via the reference functional ontology into three increasingly-capable classes: composability analysis, change management, and automated composition.

Change Management is the ability to use a functional description to automatically reconfigure an existing composition as a result of some changes in the participants. While some of the related works described earlier such as OWL-S aimed at automated composition, our goal is first set upon the composability analysis. For that specific goal, requirements for a reference functional ontology can be expressed with the following competency questions [START_REF] Gruninger | The role of competency questions in enterprise engineering[END_REF].

1. Does a provider's service functionality semantically match, at least partially, the functionality desired by the service consumer's goal? 2. Are the service's non-functional characteristics desired by the service consumer compatible with those of a provider's service, and if not what are the incompatibilities? (The non-functional characteristics include communication protocols, security constraints, pre-conditions, processing capacity, etc.)

Vision for Functional Ontology Development

Manufacturing is a large domain, even when considering only software functionalities and not hardware functionalities. In the ISA-95 manufacturing system control archi-tecture [START_REF]IEC 62264) Enterprise-Control System Integration -Part 1[END_REF], functionalities can range from process, sensor, equipment, cell, plant to enterprise levels. They can also vary by industries, types of processes, and products. Top-down, closed-effort ontology development has not prevailed; in the past decade, bottom-up, collaborative ontology development has garnered increased interest. This trend is notable from the following efforts. Linked Data (also known as Linked Open Data or LOD) [START_REF] Bizer | Linked Data-The Story So Far[END_REF] allows Web documents, Web data, and Web ontology to be linked, annotated, and queried in a structured way. FreeBase is a Web-based open platform that allows the publication of a Web ontology 2 . One of the most popular Web ontology development environments 3 has recently developed the Web version of the tool for collaborative ontology development.

Ontology development should be moving to include a significant bottom-up component [8]. Work in other industries have started to address this need, as reference models are developed to be tailored and/or extended for use by stakeholders [10]. In one of our past works [START_REF] Lee | A Framework for Developing Manufacturing Service Capability Information Model[END_REF], a framework is outlined for evolving a reference model for manufacturing capability information by applying structural canonicalization and semantic gap analysis methods using design patterns and inputs from proprietary models. Such a framework needs to be adapted for the reference functional ontology development.

Use Case Illustration of Composability Analysis

This section presents an integration use case as an initial illustration of the composability analysis idea using the envisioned functional ontology (the elements of the functional ontology are shown in italics throughout the tables in this section). The intention is to inspire further research rather than to provide a solution here. The use case sets the stage for gathering, analysis, and validation of requirements for the functional ontology. Ultimately, we will be harvesting this and other use cases to identify the requirements. In the paper, we focus on showing the use of the envisioned functional ontology. The intended use of ontology terms are shown in the relationships and constraints supporting composability analysis (see tables in this section). To enable ontology-based composability analysis, these relationships and constraints will be formalized as ontology axioms in future work, supported by an analysis of required representation and reasoning framework [START_REF] Fiorentini | An Analysis of Description Logic Augmented with Domain Rules for the Development of Product Models[END_REF].

The industry use case is based on the need to streamline the engineering change management (ECM) process which may be composed as part of other larger processes such as a regular design update process and product fault monitoring process. It is also driven by the change in a company's applications landscape. Let's assume that a company initially only had a manufacturing application, namely MA, to manage product data for design and manufacturing. At this point, the ECM process is streamlined within MA. Later on, the company purchased a new application to manage the whole product life cycle information, namely PLMA. PLMA expanded product data management functionality to track not only as-designed and as-manufactured product data but also as-maintained data. The company decided to use PLMA as the master application for product data management. Therefore, PLMA needs to be integrated with MA in order for the ECM process to be streamlined again.

In the first step of the integration, a high-level integration process is captured as part of the requirement documentation. Part of the process is illustrated through the UML sequence diagram in Fig. 2.

It should be noted that because this is an existing process, all the relevant functionalities and associated logic are known, i.e., there is no composition to create a new functionality in this case. Therefore, only the information necessary to invoke services with those functionalities on the MA side and the information necessary to inform PLMA of the result need to be identified (as opposed to the case when the integration involves building a new functionality wherein information necessary to achieve the new functionality is also necessary to be identified). It is determined that the Engineering Change Order (ECO) entity/object supports all the information necessary to both invoke the functionality on the MA and PLMA systems. For a composability analysis, details of required services from each application are derived from the integration process requirement. Examples of service requirements are summarized in the last column on the right of Table 2 andTable 3 4 (the first column indicates the characteristics of the service). The functional ontology should support representation of this service requirement. It should be noted that only few characteristics of the services are illustrated here. Additional characteristics will need to be modeled such as supported transmission protocol and other essential functional characteristics. Essential characteristics are artifacts that are expected to evolve over time as demanded by the users of services and the technological evolution.

Table 1 illustrates PLMA's and MA's native services. These are existing services on the two applications that need to be adapted to the service requirements. In a (service-oriented) smart manufacturing system environment, the service descriptions of these native services should be registered in a commonly accessible registry using the reference functional ontology to describe their functionalities. This is illustrated in the second column of Table 2 andTable 3 5 . These tables contain a row for each of the services needed from the components in focus for the ECM process in our example. Below each service row are 3 more rows that describe characteristics of the interface provided by the component to support the service. The first of these rows indicates whether the service supports or requires list operations (List Oper). The second row indicates the kind of message exchange pattern (MEP) supported or needed. The final interface row describes the type of message (Msg) supported by the service. The second column of each of these tables is used to describe native services provided by the components. The description in this column identifies the particular service variant used, the message used to carry information for the service; and then maps these to descriptions created from elements of a reference functional ontology.

The elements of the ontology are italicized for clarity. A  indicates that the native component element provides a superset of (i.e., subsumes) the content or functionality required. The fourth column contains a description of the required service as defined in the ECM process. The  (third) column shows the relationships between the description of the registered native service in column 2 and that of the required service for each characteristic (in column 4). Two symbols are used to indicate the relationship. A '√' indicates that the native service or interface element can satisfy the required service or interface element. A '' indicates that the native component has greater capability than needed but can be made to match the element.

Taking the service registration in Table 2 as an example, the first two columns indicate that the Export ECO outbound native service functionally subsumes the Validate ECO request outbound service; it is a list operation (List Oper), it supports the Request Only MEP; and its message definition (Msg), plmaECO, subsumes several messages including Validate ECO, Validate ECO Response, Create ECO, etc. In the  column, the '√' relationship on the Service row indicates that the Export ECO outbound native service and the Validate ECO request outbound matches; the '' in the List Oper row indicates that the native service is more capable than the required service; the '√' in the MEP row indicates that the native service matches with the required service and no adaptation is necessary; and the '' in the Msg row indicates that the message definition of the native service is more capable than that of the required service.

With these relationships established, the composability can be assessed. Firstly, the relationships between the Services and between the MEPs indicate that the native service can be directly piped into the required service without adaptation. Secondly, the required service does not need the list operation capability which means that there is no chunking or de-chunking required (in the mediator component that connects the PLMA with the MA service). Lastly, the fact that plmaECO subsumes the Validate ECO indicates that there will be adaptation neededdata transformation.

With the native service registration described in terms of the reference ontology, we expect that the relationship can be automatically determined. Determination of the relationship of some service characteristics will be more involved than others. For example, evaluating the relationship between messages of two services will generally require detailed semantic mapping analysis or semantic distance measurements.

The composability analysis should also be automatable. The algorithm will be specific to each service characteristic because of the differences in their underlying semantics. To enable such automation, additional semantics associated with expressing the integration requirement (e.g., required services) will need to be modeled. For example, although the List Oper row of the last service in Table 3 has the same information as that in the service in Table 2, de-chunking in the mediator may be necessary in the former case, while it may not be necessary in the latter. This is because, in the former case, it may not be controllable at MA to send the notification for a single ECO at a time as this is an existing automated process, while in the latter case it may be the integration behavior that the design engineer will send a single ECO at a time for validation purposes.

Conclusion and Future Work

This paper proposes development of a reference functional ontology. The hypothesis is that the availability of such an ontology will allow for more efficient and effective manufacturing system composition. The ontology is expected to be evolving; and hence, new development mechanisms have to also be developed. The purpose of the reference functional ontology is to allow for expressive descriptions of service's functionalities. The reference functional ontology along with other reference ontologies for non-functional characteristics will enable composability analysis of services as illustrated in a use case scenario of engineering change management integration. The use case provides an initial substantiation of the composability analysis idea. In terms of future work, we plan to develop more use cases, especially those that involve lower level manufacturing control functions (in the ISA-95 layers) and those that involve hardware equipment. High-level concepts in the reference functional ontology are being developed; and encoding of ISA-95 and the SIMA reference activities into the ontology is also being experimented with. In order to precisely encode the ontology, we will formally define key concepts, such as composition, and develop measurement methods and metrics for the composability analysis.

Disclaimer

Any mention of commercial products is for information only; it does not imply recommendation or endorsement by NIST.

Fig. 2 .

 2 Fig. 2. UML sequence diagram of the integration requirement

Table 1 .

 1 PLMA and MA native services

Table 2 .

 2 Composability analysis of PLMA services

	Service	PLMA's native service registration		PLMA Required service
	Characteristic
	Service	Export ECO outbound  Validate ECO request outbound	√	Validate ECO request outbound
	List Oper	Y		N
	MEP	Request Only	√	Request Only
	Msg	plmaECO  (Validate ECO  Validate ECO		Validate ECO
		Response  Create ECO  Create ECO Re-	
		sponse  Engineering Change Notice)

Table 3 .

 3 Composability analysis of MA services

	Service Character-	MA's native service registration		MA Required service
	istics
	Service	Process ECO inbound [@action = 'simulate'] = Validate ECO request inbound	√	Validate ECO request inbound
	List Oper	Y		N
	MEP	Request Only	√	Request Only
	Msg	maECO  (Validate ECO  Validate ECO		Validate ECO
		Response  Create ECO  Create ECO Re-	
		sponse  Engineering Change Notice)
	Service	Process ECO response outbound [@action = 'notify'] = Notify ECO outbound	√	Notify ECO outbound
	List Oper	Y		N
	MEP	Async Request Response || Request Only		Request Only
	Msg	maECO  (Validate ECO  Validate ECO		Create ECO
		Response  Create ECO  Create ECO Re-	
		sponse  Engineering Change Notice)

https://cloud.oracle.com/marketplace;http://marketplace.saphana.com/; https://www.nimbisservices.com/marketplace/

See http://www.freebase.org

See http://protegewiki.stanford.edu/wiki/WebProtege

Note that only application to application interactions are accounted for. Also, we assume the following mapping from Fig.2terminology to the last column of Table2and Table3terminology: Release  Create and Update  Notify. This mapping reflects presumed different terminologies used in integration and service requirements identification stages.

In this paper, we do not attempt to formalize any semantics of relationships between services and characteristics including the relationships in the  column.


V T Nguyen

A F Sommer

K Steger-Jensen

H H Hvolby

Hospital planning environment variables applied in practice: A multiple Danish case study

Keywords: Hospital environment variables, hospital planning, case study

The issue of hospital planning has taken a central position in increasing hospital performance. Applied hospital planning methods are found to be misaligned with hospital environments in existing research. Thus, it is relevant to increase the understanding of hospital environment variables in order to improve applied hospital planning methods. In this paper, we identify and describe the hospital environment and applied planning methods from an environment variables perspective through an in-depth case study of three Danish hospital environments and their corresponding adaptive planning frameworks. The results include suggestions for further research on improving the match between identified environment variables and the corresponding planning methods.

Introduction

During the previous decade, public healthcare expenditures in Western European countries have increased drastically, especially in secondary healthcare providers, i.e. hospitals. Due to this large share of total expenditures the issue of hospital planning and control has taken a central position in increasing hospital performance. Existing hospital planning frameworks have been inspired by manufacturing planning and control [START_REF] Roth | Hospital Resource Planning: Concepts, Feasibility, and Framework[END_REF] [2] [START_REF] Hans | A framework for health care planning and control[END_REF]. In hospital industry, the patient flow is important and is not the same as the material flow [START_REF] Nguyen | The misalignment between hospital planning frameworks and their planning environment -A conceptual matching approach[END_REF]. Hence, the planning and control of the two environments will be different. Thus, it is relevant to conduct empirical evaluations of hospital planning and control approaches in the relation to the planning environment of a hospital. This papers objective is to describe the current planning processes based on case studies with the purpose of identifying and understanding the hospitals planning environmental variables in relation to planning and control. From previous research, we have identified planning environmental variables for the hospital industry, which can be grouped into three category, namely: patient, resources, and process [START_REF] Nguyen | The misalignment between hospital planning frameworks and their planning environment -A conceptual matching approach[END_REF]. Thus, this paper will identify the hospital environment and applied planning methods from an environment variables perspective through an in-depth case study of three Danish hospital environments and their corresponding adaptive planning frameworks.

Method

An in-depth multiple case study approach has been conducted comprising a total of three case studies [START_REF] Roth | Hospital Resource Planning: Concepts, Feasibility, and Framework[END_REF] from different departments in two Danish Hospitals:

1. The department of Heart-Lung Surgery (case 1), 2. The department of ear and throat cancer treatment (case 2), 3. The emergency department (case 3). Both hospitals are large hospitals with a bed capacity of 929 beds and 482 beds respectively. The cases were chosen from different hospital processes to identify the variety in the processes of the operations within similar applied planning frameworks, but within the same country and regional setting to avoid cultural environmental effects [START_REF] Arbnor | Methodology for creating business knowledge[END_REF]. Data on environmental variables was derived primarily through interviews, conducted using a semi-structured interview guide. The environmental variables were identified through previous research study [START_REF] Nguyen | The misalignment between hospital planning frameworks and their planning environment -A conceptual matching approach[END_REF]. Furthermore, the applied planning framework was identified through a triangulation between results from the interview study, the formal planning framework of the case, and the requirements of the planning forecasting software applied in each case respectively. The total amount of interviews was 72 divided among the three cases, which is presented in Table 1. Each interview lasted approximately one hour and, in addition, a total of 10 1-hour observation studies were conducted to observe the hospital processes in practice. All interviews were recorded, whenever possible, and notes were made during each session, followed by development of extensive summaries of each interview. Afterwards, recordings were transcribed and compared to the notes, and then analyzed using pattern matching and grouping of variables in a conceptually ordered display according to the procedures outlined by Yin [START_REF] Arbnor | Methodology for creating business knowledge[END_REF], [START_REF] Yin | Case study research: Design and methods[END_REF], [START_REF] Auerbach | Qualitative data: An introduction to coding and analysis[END_REF].

Hospital Environment Planning Variables

The 3 case descriptions are structured according to the identified hospital environmental variable groups, explaining firstly the patients, secondly the resources, and thirdly the hospital process. The variables will be described in relation to their involvement in applied planning methods.

Case 1 -Surgery

Case 1 mainly performs surgical interventions after the treatment therapy of the patient has been determined. The department collaborates with other departments of the Clinical Center of Heart and Lung in determining a pathway of diagnosis and treatment of patients with heart and lung problems. Whenever, surgical intervention is needed to heart or lungs, the patient becomes the department's responsibility. In order manage and plan facilities and resources to job task, the patients are categorized based on their medical profile, where weekly surgery plans are made for only elective patients. The department has seven medical profile groups; four medical groups with heart specialty and three medical groups with lung specialty. However, prioritizing patients in the sequence of surgeries, the medical urgency is classified into emergent, urgent, and elective patients. Table 2 presents the classification of the patients; The hospital resources are classified for execution purposes, except for doctors, who are classified in order to match patients' medical profile and patient urgency to the right competences in the planning activity. Doctors are classified as either clinical or research doctors, and according to level of experience. Operating theatre nurses are divided into assistance nurses, direct nurses, and a coordinator nurse. The coordination nurse along with doctors are responsible for coordinating and changing plans of the operations activity, informing the patient's condition for preparation and share and align the information with anesthesia staff and other staff from different parts of the hospital. All activities are coordinated through frequent meetings during the day due to regular changes and disruptions. The process in the department mainly focus on the therapy phase, where there exist three entries for a patient to enter the department based on several gatekeepers or tiers in the hospital, which are Ambulatory of heart and lung, the Emergency Department, Cardiology, and Lung Medical department (in the clinical center). The elective patient can either come from the bed division or come from home before the surgery. A preoperative process is organized to prepare the patient for the surgery by operating nurses, where the patient will be checked to make sure that their condition is as expected and medical supply will be prepared and checked before for the surgery. The surgical doctor, anesthesia doctor, and perfusionists will be involved during the surgical intervention until the end at postoperative care. After surgery the patient is transported to the intensive care unit for observation, thereafter the patient will return to the bed division for recovery. The process is depicted in Figure 1.

Case 2 -Diagnostic of Cancer

Case 2 is the Ear-, Nose-and Throat-department, treating ear and throat cancer particularly in the diagnostic phase. The department has classified the patient into three groups as depicted in Table 3. Emergency patients are the most critical and are categorized as a highly complex medical profile. These patients are treated as fast as possible, whereas the volume of these patients are lowest, which is called a rush order in manufacturing terminology. The routine patients have a less critical medical profile, which gives the department a longer planning time frame. The volume of the routine patients is approximately 90% of the patients entering the department. The cancer patients are critical with complex medical profile due to time frame and high uncertainty in the diagnostic process.

The resources are managed by a department manager responsible for a leading chief doctor, a leading nurse, and a coordinator. Within the doctors group subspecialties are present meaning that the doctors have different capabilities, divided into ear, nose and throat. However, the only planning resource, which is incorporated within the activity plan, is the doctors' work schedule, even though high interdependency with the personnel and supportive resources such as x-ray and pathology occurs.

The process of the cancer treatment is divided into a diagnostic phase and the treatment phase by the legislation of Minister of Health in Denmark, however the focus is narrowed to the diagnostic process flow The treatment begins when the department receives referrals from the general practitioner, the specialist doctors, or other departments, and a first consultation is required within 72 hours. Once the path coordinator books the first patient appointment, all the following consultations and therapy processes are booked in advance to make sure that they meet the service goal from legislation. Even though, forecasts are essential, they are based solely on subjective opinions and historical views of the calendar. Thus, in order to ensure available times, the path coordinator reserves time slots for patients in advance, approximately two months beforehand and then they reschedule continuously. During the first consultation, biopsies are taken in order to diagnose the type kind of cancer the patient might have. Based on the medical profile and examination, the doctors will design the treatment plan in the diagnostic phase for the patient. The biopsies are sent to the pathological department for analysis and they have a permitted analysis time of five days. Most patients have to get scanned, MRI, CT or PET-CT scanner, which have an analysis frame of no more than two days. As the pathological deadline is the longest, the patient must wait for this result and come back five days later for a second consultation to be informed of the results. If a complex biopsy is required at the first consultation, the patient has a slightly different flow. The patient is put in full anesthesia and transported to the operation theatre of the department, where the biopsy is taken. After wake-up, the patient is sent home with an appointment for the second consultation. A generic view of the process is presented in Figure 2.

Case 3 -Emergency

Case 3 is the Emergency Department (ED) responsible for accident and emergent patients. The ED is a medical treatment facility specializing in acute care of patients without prior appointments, who come in either by their own means or by ambulance. Moreover, ED manages almost all hospital incoming patients and creates the opportunity to discharge patients more efficiently. The length of stay at the ED is maximum 48 hours, where other departments in the hospital need to take the patient into care afterwards otherwise a discharge will occur. This enhances the incentives to collaborate among departments of the hospital, integrate their plans with each other, and speeding the diagnostics process within the emergency department. In order to accommodate the variety of incoming patients the department has categorized the patients based on the triage-categorization as illustrated in Table 4. The triagecategorization is based on the planning time frame of medical urgency. If the patient is the triage color red then they are treated immediately in the trauma section. If the patient is orange or yellow and have to wait they are referred to the waiting section. The same is present with the green and blue triage colors. The department chief fore-casts the volume of incoming patient types, which is used to estimate the peak of incoming patients every day and create an overlap between morning shift and day shift in order to accommodate the volume of patients. The chief of the department, the nurse coordinator, and the administration manager manage the department's resources. Each of these is responsible for doctors, nurses and secretaries respectively. From the resource capability perspective, the emergency department differs from other special departments as all doctors can provide the same job task, as well as for the nurses. They are trained to have the same capability within the emergency specialty, which means that manage and plan the resources become less complex. Daily planning consists of frequent meetings with all involved stakeholders to allocate resources and facilities most efficiently. However, the planned activity only takes doctors into account even though there is high interdependency with supportive resources such as x-ray and laboratory. Figure 3 shows the process, which begins when patients are referred to the ED by practitioners in the office hours and by doctor from the emergency services outside office hours. The patient is then placed in a triage category (red, orange, yellow, green and blue) by a visitation nurse based on the information from practitioner's referral and examination of the patient. If, the ED can provide therapy treatment, the patient can go home afterwards. If, on the other hand, observation of the patient is necessary, the patient will be transferred to the emergency bed division. During the process the ED interacts with different supporting resources such as X-ray, laboratories, and other special departments. Therefore, a need for close collaboration and integration with plans with others unity is necessary to provide efficient health care service in the ED.

Discussion

The analysis indicates several challenges regarding planning and control of incoming patients and resources. The cases are different in patient requirement, resource availability, and process flow. It indicates that there does not exist a silver bullet approach for hospital planning and control. Thus, a more patient oriented approach such as differentiated planning and control is needed. The process flow of case 1 shows, the focus should be predicting the lead time, since this is the most critical element. Time is also critical in case 2. Hence, the process flow shows that it is important to be within the estimated lead time otherwise postponement will occur for other planned surgeries in line. The process in case 3 is very different from the other two cases, since it has the least linear process flow. Therefore, the focus here relies on short timeframe, patient predictability, and fast determination of resource requirement for incoming patients. Thus, Case 3 planning environment requires flexibility and agility in the planning in order to accommodate the different type of patients. All three cases deal with the high complexity, high variability, and high uncertainty, especially within patient variables. The high uncertainty increases the risk of induced changes and disruptions in the process affecting other patients negatively [START_REF] Adan | Patient mix optimisation in hospital admission planning: a case study[END_REF], unless appropriate approaches of dealing with uncertainty occur. To accommodate for the uncertainty, all three cases use large time slots, slack time, and frequent meetings for both information sharing, coordination, and re-scheduling. Furthermore, all three cases use simple planning methods, which only include elective patients, even though historical data is stored for use in more reliable planning methods. Thus, we suggest that 'applied hospital planning can be significantly improved through incorporation of existing patient variables and historic data in hospital planning methods'.

Resource constraints are one of the cornerstones in hospital planning [START_REF] Blake | A goal programming approach to strategic resource allocation in acute care hospitals[END_REF]. Despite interdependencies between limited resources, none of the three cases' planning approaches acknowledge the diversity of involved resource types beyond doctors, which frequently stresses the system and involved staff with overload of job tasks. Thus, we propose that 'undercapacity of limited resource types is enhanced or even generated by lack of incorporation of relevant resources in hospital planning.' Based on this proposition, we call for further research on incorporation of all necessary interdependent resource types into hospital planning methods.

Finally, the process variables are neglected in similar ways in planning at all three cases, predicting and planning only on simple process flows and without iterations due to emergent changes regarding patient conditions or interdependencies to support processes. To compensate there active planning approach, there occur several coordination meetings during the day. This approach, however, leads to frequently replanning and re-scheduling which is time consuming for multiple resources. Thus, we propose that 'deterministic processes are unsuitable for adapted hospital planning due to the degree of emergent changes and continuous iterations related to dynamic patient variables.' Thus, we recommend further research clarifying the appropriateness of process design and performance measures in different planning environments in hospitals.

Conclusion

The aim of this paper is to increase understanding of hospital environment variables in order to improve applied hospital planning methods. We have identified and described the hospital environment and applied planning methods from an environment variables perspective through an in-depth case study of three Danish hospital environments and their corresponding adaptive planning frameworks. It indicates that several challenges regarding planning and control of incoming patients and resource, where further suggestion might be in a direction of a more patient oriented approach such as differentiated planning and control. All three cases use simple planning methods, which only include elective patients, even though historical data is stored for use in more reliable planning methods. Thus, large time slots, slack time, and frequent meetings for information sharing, coordination, and re-scheduling are necessary in order to overcome the uncertainty of patient planning. The results include suggestions for further research on improving the match between identified environment variables and the corresponding planning methods and framework.

Fig. 1 .

 1 Fig. 1. Process flow in case 1

Fig. 2 .

 2 Fig. 2. Process flow in case 2

Fig. 3 .

 3 Fig. 3. Process flow in case 3

Table 1 .

 1 Overview of conducted interviews during the multiple case study.

	Interviewees/Case	Case 1	Case 2	Case 3
	Patients	7	3	13
	Lab staff		3	2
	Nurses	7	2	4
	Administration/secretary	5	3	2
	Special Doctors	2	4	12
	General Practitioner			2
	Ambulance assistants			1

Table 2 .

 2 Patient group variables in case 1.

	Patient groups		Medical profile complexity	Planning time frame	Patient volume
	Heart	Emergent	High	Short	Low
	patients	Urgent	High	Medium	Low
		Elective	High	Long	Medium
	Lung	Emergent	High	Short	Low
	patients	Urgent	High	Medium	Medium
		Elective	High	Long	Medium

Table 3 .

 3 Patient group variables in case 2.

	Patient groups	Medical profile complexity	Planning time frame	Patient volume
	Emergency patient	High	Short	Low
	Cancer patient	High	Short	Medium
	Routine patients	Low	Long	High

Table 4 .

 4 Patient group variables in case 3.

	Triage-Patient	Medical profile complexity	Planning time frame	Patient volume (% of total)
	Red	High	Zero	1 %
	Orange	High	15 min	10 %
	Yellow	Medium	60 min	13 %
	Green	Low	120 min	26 %
	Blue	Low	N/A	50 %