The manufacturing domain has to face different changes. According to [Wi05,Ny08] these changes can be (i) changes to existing products, (ii) introduction of new products, due to new customers, changed requirements, or a changing market structure, (iii) changes in order parameters, e.g. lot size or lead times, (iv) changed delivery requirements with respect to longer delivery distances, (v) changing national or foreign rules and standards, as well as (vi) increasing resource scarcity. In order to cope with such changes in the production systems' environment, [SS90] introduce the concept of flexible manufacturing systems. Flexibility is therein described as "the ability to respond effectively to changing circumstances" [SS90, P.292]. Furthermore, [SS90] distinguish different types of flexibility. Considering the manufacturing domain with a focus on the manufacturing system itself, three flexibility types are of particular relevance. First, routing flexibility, which permits manufacturing processes to be performed in alternate orders. Second, process flexibility, which is the range of different parts that can be produced without major setups referring to parameterization. Third, machine flexibility, which is the flexibility that is provided by a machine to adapt it to changing requirements without major changes to the software or hardware.

[SFJ15] defines variability based on [PBL05] as the flexibility that is integrated into a system and that is used to adapt a system during development as well as during runtime. This paper shows that during runtime, different variability categories, based on the flexibilities presented in [SS90], must be considered. From now on, the term variability will be used instead of flexibility. The paper is structured as follows. Section 2 provides an introduction into variability management as well as an overview of related work. Section 3 shows that variability should be classified into different categories. Furthermore, the opportunities of using variability management during runtime will be discussed. Section 4 outlines which industrial needs can be addressed by applying the proposed concept. Finally, Section 5 presents the challenges that will be addressed in our future research endeavours.

Variability management is a method, which belongs to the software product line (SPL) engineering concept, which is concerned with developing applications in a way that allows for systematic reuse of individual components. The SPL engineering concept is an opportunity to deal with mass customisation, while reducing the complexity of variant-rich product portfolios [PBL05]. Variability management is not limited to the software engineering domain, as has been shown with concepts focusing on variability management in the development of production plants, e.g. product series, modular approaches and platform design [SFJ15]. Most of these concepts are component-oriented and aim to increase the number of equal parts to reduce development and operating costs based on economies of scale. SPL, on the other hand, are customer-oriented in that they focus on functional and product-related aspects, i.e. meeting market changes are the main goals [CN09]. A core component of SPL engineering is the explicit modelling of variability by using dedicated models, which represent the common and the variable features of the product [Be13]. From these variability models (VMs) individual variants can be derived. Additionally, VMs can be enriched with constraints and dependencies. A differentiation between problem space VM and solution space VM is recommended [PBL05]. A problem space VM is domain-specific and contains stakeholder needs as well as desired features. A solution space VM, on the other hand, contains diverse reusable artefacts, which may be arbitrary engineering artefacts, e.g. requirements, specific components, or tests created during the engineering workflow. A mapping between problem space and solution space VMs is necessary since they provide different perspectives on the SPL and contain distinct knowledge for deriving variants [Sc12].

Each domain has different requirements, engineering processes and tools. Due to this reason, various approaches exist that apply the SPL concept to specific domains and their specific requirements. [SFJ15] and [Ma13] both adapted the SPL concept, including 92 Birte Caesar, Wolfram Klein, Constantin Hildebrandt, Sebastian Törsleff, Alexander Fay, Jan Christoph Wehrstedt New Opportunities using Variability Management during Runtime 17 the variability management, to the automation domain, though none of them focused on the specifics of the discrete manufacturing domain. [FLV15] and [Ko17] extended the SPL concept specifically to the manufacturing domain. Their concepts consider the typical plant engineering workflow by separating the solution space VM into three different models, the mechanical, the electrical and the software VM. This reflects the standard separation of trades in engineering of manufacturing systems and offers several advantages. First, a reduction of complexity is achieved by presenting only relevant and trade-specific information to engineers. Second, the different variability of the individual trades can be modelled separately, without affecting the model in its entirety. A mapping between the problem space and solution space VM is necessary to take into account the customer's requirements. The mapping matrix presented in [FLV15] describes a direct connection between a customer's choice and a technical realisation for each tradespecific VM. The mapping matrix is only a rough description of the real dependencies between the engineering artefacts. Both, [FLV15] and [Ko17] include the three views, however, a method for modelling all three views on a manufacturing system is not provided. An approach for addressing this shortcoming is described in [Hi17]. Here a system meta model is proposed including dependencies between functional, structural and behavioural models. The approach has not yet been applied to variability management and needs to be extended for that. Fortunately, the approach described in [Hi17] is not domain-specific, which is advantageous as the basis for a common use.

The previously discussed approaches are mainly focused on machine flexibility. Extending the variability management concept for the use at runtime, allows the utilisation of the variability information captured during the engineering process to support context-aware reconfiguration at runtime. A reconfiguration at runtime can be a functional, structural, or behavioural change, either supported by a worker or automatically. [FLV15] describes the evolution of manufacturing systems as one possibility to react to changing requirements. Delta Modelling is a concept to identify needed runtime changes of an existing system to meet changing requirements. The concept also allows to manage variability and evolution similarly. Its goal is to identify the gap between the actual system and the required system. Based on this analysis a solution for closing the gap should be derived [Ko16]. This approach is a solution for adapting to the changes mentioned above. However, to find a systematic method to react to the changes, both the process and routing flexibility have to be considered, too.

In the following section, a novel approach to integrate process flexibility and routing flexibility is described. Furthermore, the need for consistent and integrated VMs in all variability categories will be shown. The development of a domain-independent method for consistent variability modelling is one of the goals of the project CrESt (Collaborative Embedded Systems3 ), which started in February 2017.

In this section only the solution space variability is considered. The mapping to the problem space variability will be the subject of future contributions. The three identified variability categories (macro process, micro process and trade & component variability) are subsequently described and explained using the MPS500 demonstrator.

First, the demonstrator is introduced. The MPS500 is a modular manufacturing system, which consists of six individual modules and a conveyor belt (see figure 1). Each module consists of components, which together provide one or more manufacturing processes. The considered product is a pneumatic cylinder (see figure 2), which comprises of five components: a body (1), which is produced with the MPS500, a piston (2), a spring (3), a sealing ring (4), and a cap (5). The last four components are vendor parts, which is why only the body will be considered in this example.

Each product consists of features, some of which can be manufactured by single manufacturing process step, while others need to be manufactured by multiple manufacturing process steps. For some features, the order of the manufacturing process steps can vary as well. Taken together, these aspects present the first category of variability based on the routing flexibility by [SS90]. The MaPVM includes information about the available manufacturing process steps of a manufacturing system consisting of different modules. The MaPVM is an overall VM relevant within the field of manufacturing systems. This provokes the need for developing a meta model in order to integrate VMs from different manufacturing modules from different vendors into one overall VM.

94 Birte Caesar, Wolfram Klein, Constantin Hildebrandt, Sebastian Törsleff, Alexander Fay, Jan Christoph Wehrstedt New Opportunities using Variability Management during Runtime 19 Figure 2: Pneumatic cylinder Considering the MPS500, the body contains two holes: one for the piston and one for the vent. These are two features that have to be manufactured. Figure 1 shows that the MPS500 has a cutting drilling module as well as a laser drilling module, i.e. the MPS500 provides two different process steps to manufacture holes. The MaPVM should cover all process steps provided by MPS500, such that it can be automatically analysed if the needed process steps to manufacture the product feature 'hole' are provided. In order to determine the manufacturability, the required manufacturing process have to be analysed in detail, which can be accomplished based on the second variability category. Figure 3 shows an example how the VM of the Demonstrator MPS500 could be modelled. In the VM, only the modules of the MPS500 are represented. The mapping between the product features and the needed manufacturing process as well as the structure and the detailed information, which have to be modelled in the VM, will be the subject of future work.

A manufacturing module can be described by its possible manufacturing process, which has certain process parameters that must be set for manufacturing a particular product feature. The range of each parameter is fixed and specified as per the components of the manufacturing module. A detailed description of how the parameter range can be identified is given in [Ho17]. The micro process variability category takes the set of valid parameter settings into account and relates to the process flexibility defined in [SS90]. The product feature 'piston hole' has a diameter of ten millimetres, which excludes the laser drilling module to manufacture this product feature. Contrariwise, the product feature 'vent hole' has a diameter of two millimetres, which can only be manufactured by the laser drilling module. Figure 4 shows an example of the MiPVM of the cutting drilling module. The final structure of the VM and the relation to the product features as well as the connection between the MaPVM and the MiPVM will be the subject of future work.

The TCVM can be used to derive a variant of a manufacturing system during its development. Its target application is within the engineering of manufacturing systems. Due to its use during the engineering process, it is necessary to take all relevant trades into account. Therefore, three viewpoints are used: the behaviour, structure and function viewpoint according to [Ko16] and [Hi17].

The TCVM contains all information about a product line and the variants that can be derived from it. This information, provided in a TCVM, already contains information which components must be changed to change the properties of the manufacturing process provided by a module. In terms of reconfiguration at runtime, this information is fundamental, because a reconfiguration's goal is to change the manufacturing process so that the changed requirements can be met. Therefore, the TCVM should be considered at runtime. To use the VM of a particular variant (which has been created during engineering) later during runtime, it has to be enriched with additional information. Inter alia, the information about the actual variant has to be saved within the VM. Furthermore, each feature that limits a parameter range has to be marked. The TCVM is an extension of the conventional VM used during the engineering process. Regarding the MPS500 demonstrator, the TCVM of the drilling module contains information about the incorporated components and, due to the extension for the runtime use, also the information which component influences which parameter range. For example, the drill bit is 60 millimetres long, but the drilling depth that can be provided is 96 Birte Caesar, Wolfram Klein, Constantin Hildebrandt, Sebastian Törsleff, Alexander Fay, Jan Christoph Wehrstedt New Opportunities using Variability Management during Runtime 21 only ten to 40 millimetres. In this case the drilling depth is limited by the distance between drill bit and table. Accordingly, the TCVM should contain the information that the linear axis is the component that limits the parameter range of the process parameter drilling depth. Based on this information, a reconfiguration plan is easier to develop. Figure 5 shows an example of the TCVM of the drilling module. Future work will deal with modelling the three views and the connection between the MiPVM and the TCVM.

To identify requirements concerning industrial needs, the introduced variability categories need to be merged into an overall concept. This concept supports the order acceptance process due to possible analysis based on MaPVM and MiPVM. Furthermore, analyses based on TCVM support creating reconfiguration plans. It enables managing the variability of a manufacturing system consisting of different manufacturing modules, which results in the name of manufacturing system variability management (MSVM).

This section will provide insights of industrial needs applied to the MSVM proposed in the previous section. The main goal when developing a VM should be its applicability to real world problems. Therefore, the applicability of the MSVM as mentioned before to manufacturing systems will be analysed. The changes explained in Section 1 show an urgent need for building new, innovative plants. Also they show the need for investments to redesign and retrofit the machinery and production lines of existing manufacturing systems. A very poor preparedness of factories especially regarding structural changes to its design according to business needs is observed in daily business. Therefore, the focus of this analysis of the applicability of the VMs is not to the design phase but its model extension to the operation phase and runtime of the manufacturing system as proposed here. The MSVM can be considered as a step towards a flexible and adaptable factory. However, several implications need to be taken into account, which are mapped to the three proposed variability categories. To gain even more insight, the VM will also be discussed with respect to a concrete use case at Siemens. A daily task for plant managers is the planning of the product mix. It is an optimization problem with respect to multiple variables, i.e. resources like machines, worker, material, energy costs and time as part of the context of the system. Here, an automated analysis based on the MSVM is desirable to check whether the required products can be manufactured using the given resources. This analysis could be validated by means of simulations for different scenarios.

The MaPVM combines variability information from different manufacturing systems. Enterprise cooperation and strategies for a cross-company cooperation improve the production diversity and help to interconnect different manufacturing systems. Variable strategies for a cross-company product mix using external resources e.g. production sites, workers etc. for larger quantities, reduced costs, or specialized expertise will result New Opportunities using Variability Management in the Manufacturing Domain during Runtime 97 in a higher flexibility. Additionally, cooperating companies are needed as extended workbenches, which leads to the need of a common and standardized purchasing of services, especially in the construction but also from an operation and maintenance point of view. Based on a MaPVM, the combination, the flexible exchange, and possibly the restructuring of different manufacturing modules with respect to the actual situation can be analysed more easily. Even the decision of buying a new manufacturing module itself can be supported on a high level based on the information about the available manufacturing processes summarised in the MaPVM. From an industry point of view, the following requirements regarding a MaPVM can be stated. First, the MaPVM should be applicable for cross-company application (R1). Second, the MaPVM should comprise all information required for simulating different strategies within this category (R2). An MaPVM can support multiple business processes: production planning, work planning, and order planning. The expected benefits for these business processes are quick feasibility checks. This can accelerate production and work planning, as well as order planning. Table 1 shows an overview of the variability categories, their goals, and their related business processes as well as the affected IT-systems based on the automation pyramid. In the next step, variations in process parameters for set-up times of systems and the reusability of installations have to be analysed to come to an optimised production. The concrete outcome of an analysis of the MiPVM as well as the acceptance criteria and operation instructions of a valid system configuration ("buy a new machine" vs. "accept certain production delay") are clearly dependent on the individual optimisation problem. Potential changes of machine functionalities based on parameter settings should be possible in a quick and well structured way. From an industry point of view, two requirements regarding an MiPVM can be stated. First, the extension of the parameter range has to be accomplishable within a reasonable time window (R3). Second, a MiPVM has to consider set up times so that they can be minimised (R4). A MiPVM can support three business processes: product planning, planning for new machines, and order control. Expected benefits with respect to these business processes are detailed information about the manufacturability of a certain product based on the actual parameter range, respectively the available parameter range. Furthermore, better order control is expected based on faster and easier match between product and manufacturing module.

98 Birte Caesar, Wolfram Klein, Constantin Hildebrandt, Sebastian Törsleff, Alexander Fay, Jan Christoph Wehrstedt New Opportunities using Variability Management during Runtime 23

The reconfiguration of a plant based on functional, structural, or behavioural changes was proposed as the third variability category. For this purpose, a production design of a modular manufacturing system consisting of differentiated (type-bound) manufacturing modules and even decoupled modules is required. Furthermore, the production must consist of flexible cells, modular systems, and test engineering work places. From an industry point of view, a TCVM has to allow for modular manufacturing systems (R5). Furthermore, a TCVM should support extendable systems (R6). The following business processes are covered by this variability category: resource planning, work planning, and production scheduling. Expected benefits for these business processes are improved production planning, an adapted production schedule due to actual situation, better order control, as well as shorter lead times.

Due to the changes described in Section 1, manufacturing systems are required which are able to adapt to these changes. An approach from the software engineering domain is considered, because the variability modelling is explicitly demanded. The SPL engineering focuses on the development of systems and does not consider all aspects relevant for an approach of flexible manufacturing systems during runtime. The presented variability categories summarised in MSVM integrate the additional aspects during runtime. The relevancy of the approach has been shown for both, concrete industrial requirements and a demonstrator.

In this paper, we outlined that different kinds of variability are relevant in manufacturing systems, especially during runtime. The various industrial requirements taken into account demand new variability modelling methods. Furthermore, different open challenges have to be analysed and handled. First, each variability category needs a coherent modelling concept, based on commonly used semantics and industrial standards. These concepts have to take into account the dependencies between each variability category. Additionally, economical aspects have to be integrated. The problem space variability has to be considered as well as the requirements analysis. This results in the second challenge: How can dependencies be modelled such that changes in each category are reflected in the other categories and can be traced back? This challenge is already being worked on in the software engineering domain and some aspects will be considered in the ongoing CrESt project. The third challenge is to integrate the modelling method into the engineering workflow, such that the developed models can be used and maintained at runtime and also be re-used in other engineering projects. The integration into the engineering workflow has been investigated in various research projects. However, the defined methods do not consider using these models at runtime.