PILOT PRODUCTION ENVIRONMENTS DRIVEN BY DIGITAL TWINS

ing the outcomes of industrial case studies, combined with earlier research on, for example, shared decision-making [3, 4], synthetic environments [5, 6], process planning [7, 8], and information and knowledge management [9]. Both current and foreseen developments are taken into account, thus also interrelating operational, tactical, and strategic perspectives. 2 THE INTERACTION BETWEEN PRODUCT DESIGN AND THE PRODUCTION ENVIRONMENT Under increasing time pressure, with limited resources to invest in pre-testing production setups and making prototypes, companies struggle to align product design decisions with considerations on how to set up, adjust, and renew their production environments or parts thereof. It is not sheer technological considerations that are leading; different perspectives jointly influence what production strategy, layout, and equipment would be best suited for purposeful, profitable, sustainable, but also flexible and agile production. As is the case in product development, in the configuration of an optimised production environment, traditionally the dimensions ‘time’, ‘quality’, and ‘cost’ are the three main clusters of perspectives involved. However, the focal point of these dimensions depends on whether they are observed from the product domain or from the production domain (see Figure 1) [10]. For example, the difference in perceiving quality as either product quality or process quality might cause an incompatibility between design decisions and production decisions. Even a notion such as ‘first-time-right’ relates to that difference, addressing either that the first time a production step is executed the process is meeting specifications, or that the first product will pass quality control. Obviously, this does not have the same meaning, nor does it entail the same efforts in the development cycle.


INTRODUCTION
Over the years, the number of tools, techniques, and methods that industrial (design) engineers have available to them has increased significantly. Simultaneously, the engineering landscape has widened to well-nigh the entire life cycle of both products and production environments. This challenges engineers to work amid the multiple perspectives of the many stakeholders that, while either agreeing or contradicting, aim to allow the company to bring the optimal product portfolio to the appropriate markets, in a feasible and profitable manner. This requires excellent product designs that integrate the interests of all stakeholders in the context of quality, cost, lead-time, life-cycle, and techn(olog)ical potentialities. Moreover, it entails operational excellence in the product environment, tactical attention to asset monitoring and upgrade/overhaul/replacement approaches, and a strategic focus on technological developments and company goals.
Obtaining and maintaining an adequate overview of this entire realm of manufacturing in a way that actually strengthens the overall value network is a sheer impossibility for individual engineers or small teams in a large multi-disciplinary environment. This implies that the contextualisation of all decisions taken by individual engineers is not self-evidently complete, certain, unambiguous, or objective. Nevertheless, the aggregation of all those individual decisions renders the overall definition of the product and the production environment. This does put a heavy focus on the potential consequences of every distinct decision, which can indeed have significant repercussions 41 on the overall value network. Therefore engineers might feel stifled in reaching decisions because of the increasing impossibility of foreseeing relations to other decisions, perspectives, stakeholders, or phases of the life cycle. This is all the more true with the exploding amount of data and information that is becoming available to influence and underpin decisions, but simply cannot be processed in a timely manner. With this, engineering essentially loses some of its deterministic character, which calls for different paradigms in traditional process-and rule-driven engineering environments.
In this, especially, the interaction between the product design and the design of the production environment is relevant (e.g. [1,2]). After all, the precedence relation between design and production decisions is not causal. A company might reason from the envisaged product design, and develop the purchasing/production strategy and production environment accordingly. Alternatively, the company might shape its product portfolio according to the production environment, production strategy, and technological expertise available or foreseen. Many companies still focus on this apparent contradiction, and try to integrate product development and production by means of a wide variety of initiatives, processes, and arrangements. At the same time, industry faces a technological toolbox that can indeed change the existing paradigms by adopting a perspective in which the encounter between product development and production does not develop into a chasm, but rather becomes instrumental in driving the overall value network.
With the increasing availability of approaches and tools that are currently usually labelled 'Industry 4.0' or 'smart industry', companies can know more about their development trajectories, their products, their production and assembly assets, and their environments. This, however, does not self-evidently lead to quicker or better decision-making. On the contrary: many companies even turn capturing and managing the avalanche of data and information into a goal in itself, thus risking missing the essential contribution that the information content can provide. If a company sees the conglomerate of data and information as a way to improve its understanding of the manufacturing tasks by creating better and better-suited models, the decision-making capability can be significantly increased.
This publication, at the interface of product development and production environment, postulates a paradigm to co-develop products and production environments in a setting that does justice to the many stakeholders and perspectives involved. As scholarly literature on this topic is scarce, and appears to have only limited relevance, the paradigm emerges primarily from interpreting and abstracting the outcomes of industrial case studies, combined with earlier research on, for example, shared decision-making [3,4], synthetic environments [5,6], process planning [7,8], and information and knowledge management [9]. Both current and foreseen developments are taken into account, thus also interrelating operational, tactical, and strategic perspectives.

THE INTERACTION BETWEEN PRODUCT DESIGN AND THE PRODUCTION ENVIRONMENT
Under increasing time pressure, with limited resources to invest in pre-testing production setups and making prototypes, companies struggle to align product design decisions with considerations on how to set up, adjust, and renew their production environments or parts thereof. It is not sheer technological considerations that are leading; different perspectives jointly influence what production strategy, layout, and equipment would be best suited for purposeful, profitable, sustainable, but also flexible and agile production. As is the case in product development, in the configuration of an optimised production environment, traditionally the dimensions 'time', 'quality', and 'cost' are the three main clusters of perspectives involved. However, the focal point of these dimensions depends on whether they are observed from the product domain or from the production domain (see Figure 1) [10]. For example, the difference in perceiving quality as either product quality or process quality might cause an incompatibility between design decisions and production decisions. Even a notion such as 'first-time-right' relates to that difference, addressing either that the first time a production step is executed the process is meeting specifications, or that the first product will pass quality control. Obviously, this does not have the same meaning, nor does it entail the same efforts in the development cycle.

Figure 1: Different interpretations of dimensions in product development and production
Moreover, many production environments are envisaged to produce different products or different variants of products, whereas product developers include make-or-buy decisions in their process. This causes an m-to-n relation between products and production environments, which does not contribute to the clarity and unambiguity of the alignment between them. Accordingly, there is no prevailing consideration that can drive decision-making, as the decisions are mutually dependent, and dependent on the perspective of the stakeholders.

Smart products, production assets and processes
With current developments, not only are the traditional three dimensions relevant, but the dimension 'technological potentiality' also plays an increasingly significant role. With new technological solutions available at increasing speeds, the time over which the same product (variant) is sold decreases. For cyber-physical systems, new soft/firmware does not necessarily immediately influence the complexity of the production environment; but with different sensors, actuators, or new functional elements (for example) becoming available, product versions of smart products succeed each other with increasing speed. This entails increased complexity management, with long-term impacts on (for example) maintenance, repair, and end-of-life behaviour. This has repercussions on the production environment, because the required flexibility and agility increases accordingly. The underpinning of investments in production assets is more demanding, with higher uncertainties in the optimisation of the production environment.
At the same time, the capabilities, capacities, and employability of production assets are subject to significant and meaningful conversions. Whereas an asset may be ageing as far as the economic and technical aspects are concerned, more and more, industry uses technological aspects to decide on upgrading, renewal, or replacement. Irrespective of whether the asset is still 'making money' or 'working reliably', feature-rich new 'smart' assets that are regarded as making a greater contribution to the overall value network are seen to be justifiable replacements for existing components in the production environment. Again, this does not contribute to the consistency and controllability/manageability of the production environment. Whereas such developments contribute to the agility of the production environment, reliability and predictability may suffer. Also, many companies underestimate the impact of replacing any part of the production environment on both the primary process and the organisational aspects [11]. As an example: in a company that produces fast-moving consumer goods, all efforts involved in placing, setting-up, testing, and adjusting assets directly hamper normal production, with immediate profit loss as a consequence. Also, the impacts that any new asset has on logistics and planning, on the optimal balance in the product portfolio, but also on staff training, are often ill-understood or insufficiently taken into account [12].
Historically, engineers have been used to align product development and production based on processes that were reasonably reliable and reproducible. Admittedly, processes did change significantly and fast in respect of their capabilities and capacities; but these changes have predominantly been of an evolving nature. Over the last few years, however, research and development in production has resulted in new processes that are disruptive of the way in which 43 engineers interrelate product development and production processes. Examples of such processes include, but are definitely not limited to, additive manufacturing, hybrid production, collaborative robots, and processing of (thermoplastic) composites. All such processes change the production environment, but also have significant impacts on the design of products, product development, process planning, and production preparation and control.
Some of these processes allow or force product developers to rethink the types of geometry they use. After all, for years designers have been using design features that are implicitly related to the traditional production processes. Hybrid production, for example, in combining additive and subtractive processes, allows for shapes to be made in types of material that, until now, have not been possible. That calls for a different way of designing and thinking [13] about the combination of product definition, production asset(s), and processes.
For quite a number of these new processes, no complete, reliable, robust, and deterministic process models are available yet, creating a huge challenge for product developers and production engineers alike. After all, without having a firm understanding and control of a process, process planning is unsound, rendering both product development and asset development/selection nondescript. To create better process models, more experience in using the processes is needed, for which adequate production assets are required; however, building such assets requires better process models. In effect, an iterative approach needs simultaneously to drive the development of the process model and the production assets, stressing the dynamic character of both as they evolve. In many cases, the applicability of these processes can be validated under laboratory conditions or in small production runs. However, upscaling and industrialisation is far from trivial. This is not only a consequence of the investments involved; it also directly addresses the relation between product quality, process quality, and process reliability. As has already been substantiated for production environments, prototyping of new production processes on a real-life scale is often not feasible -if not impossible. This is partially related to the fact that testing or validating one separate process is immensely impactful, because the new process will be part of a chain or network of processes. This means that prototyping has to be done in-line, thus immediately again hampering the primary process. Additionally, production speeds under laboratory conditions cannot be translated to industrial speeds and reliability without huge efforts or assumptions that may render the results unreliable.

Process-oriented and information-driven development
Together, the observations on smarter products, production environments, and new processes result in a paradox: the more that adaptability, functionality, and flexibility become available in the constituent parts, the more difficult it is to bring them together in an overall manufacturing cycle. The more agile and adaptable that the constituent parts are, the more difficult it is to actualise the same overall level of agility and adaptability. Especially the lack of predictability and the risks connected to the consequences of many decisions involved reduce the agility of the overall solution. The abundance of available data and information does not directly improve the understanding of the product definition, the production assets and processes, as no deterministic models for that are (yet) available. At the same time, more and more opportunities arise to capture data in the production environment or in the through-life phase of products. In the context of purposeful and reliable models, forecasts and control mechanisms, this data would allow engineers to access information about the entire manufacturing cycle. However, currently the captured data is not yet sufficiently connected to multi-perspective interpretations of that manufacturing cycle [3]; and so it is definitely not used to its fullest extent (e.g. [14]). However, it is especially this information that holds the key to the effective and efficient development of manufacturing cycles, independent of whether products, production assets, or processes are addressed. After all, seen from this information perspective, all constituents of the manufacturing cycle -products, processes, and production environment -have their own development cycles. Consequently, production environments too can be seen as the result of a development cycle. Obviously, the same is true for the assets that are part of the production environment. Also, new processes are hardly the result of fortuitous discovery; irrespective of how ground-breaking their application may be, they often are rather the consequence of a thought-out development cycle -even if the resulting process is not yet fully understood or controllable. 44 Traditionally, development cycles are structured in terms of the 'design and engineering processes' that together would or could engender the foreseen end result. Given the ease with which processes can be defined, planned, structured, and checked-off, predictable process steps have inherently become the tangible constituents of development cycles [15], sometimes even being mistaken for being the development cycle itself [16]. However, design or management processes in themselves cannot guarantee adequate or reliable outcomes; to assess those outcomes, other processes are employed. Over the years, the process-hierarchies for product development and production environments have developed in parallel and quite independently, where they each yielded their own structures and language. Many companies now struggle to find a common denominator between them. This is troublesome, because processes may describe 'what' has to be done, but offer less support in understanding the 'how' -let alone in conveying the 'why' of what they entail. Moreover, 'process thinking' is embedded deeply in the structuring and control of development and production [17], thus offering a convenient but incomplete and indirect managerial perspective. After all, it is essential to appreciate that information is the carrier of all (added) value in, and of, any development cycle [18]. With that, activities in design and development cycles become mere tools that can further that information content -used at the discretion of the engineer. The information content connects different perspectives, stakeholders, and viewpoints, as it offers an objective backbone for different types of stakeholders to use different tools. The information content evolves over time, capturing the rationale and essence of decisions, while allowing one to revisit earlier or different information states. Reasoning from the information content allows different potential future states to be compared, where expertise, experience, measurements, simulations, strategies, requirements, and -most important -common sense can be applied to assess those future states and to choose between alternatives.

ISSUES IN PRODUCTION ENVIRONMENTS FOR AGILE MANUFACTURING
To allow engineers purposefully and adequately to address the manufacturing cycle in an integrated manner, while considering different perspectives, the joint information content of product development, production environment development, and process development can become the main driver. Primarily, this information content can represent the current state of affairs, which allows for objective, decisive, and goal-oriented decision-making. The impact of the evolvement of the information content can also be assessed, which allows for effective and efficient evaluation of the quality of the product, production environment, or process under development.
This starting point can be employed as a new way to address development questions related to the organisation of shop floors or factories. In a context where developers are surrounded by information and information-providing systems, the decisive underpinning of decisions is nevertheless often difficult. Although developers may have anything from Enterprise Resource Planning / Product Life Cycle Management / Product Data Management / Manufacturing Execution System via analysis and simulation tools to Virtual Reality / Augmented Reality visualisation available to them, bringing together a meaningful overview of different perspectives is no easy task. This certainly has to do with the so-called external stressors [19] that influence the development cycle. Even if they can be anticipated, they can be undefined in size, scope, and effect, which makes attempts to capture them in development models rather effectless. This explains why the scoping of many development models is quite strict, underexposing the actual interface with reality -the playing field that is most relevant for developers.
Examples of such external stressors that will act on a production environment give rise to many questions that can actually drive the development of the manufacturing cycle:  Does it make sense to replace machine A now already?  Is this layout suitable for our changing product portfolio?  Should we postpone maintenance on machine A?  Would having another machine A solve our bottleneck?  Can this production environment deal with a 20% increase in production volume?  How would the introduction of technology B change our shop floor?  What is the return-on-investment for machine A if we also produce product P?  Could process C be used to produce N products per hour?  How could product P be changed to optimise process Cd … Cm? The list is essentially dynamic, subjective, perspective-dependent, time-dependent, and incomplete, which immediately implies that no closed model can be assumed to become a tool for answering all such questions. Consequently, this renders the answers to many of these questions non-deterministic. Therefore, the naïve and unreflecting way to establish an optimal production environment, while setting aside any constraints and repercussions, would be simply to build it at the required scale, test it, improve it, and then commission it. In reality, simply 'testing in real time' is obviously almost not feasible -not for an entire production environment, but especially not for any sub-system in that environment. After all, as mentioned before, any alterations to or standstills of such a sub-system under development will immediately influence the primary production lines.
However, in postulating that a future production environment can be represented holistically and perspective-dependent, the ideal of configuring and testing a production environment without disturbing the current situation may be within reach. The pilot-plant concept aims to create such environments by being -in essence -a risk-avoiding, agile, and secluded 'playground' for engineers.

PILOT PRODUCTION ENVIRONMENTS
A pilot plant is a facility that allows a company to develop, test, improve, and upscale (parts of) a production environment while not hampering primary processes and avoiding investments where possible. This is done by making the pilot plant virtual where possible, and physical where required. Moreover, there is no prerequisite that physical components in a pilot plant are at a single location.
In the context of this research and the underlying industrial case studies, the scope of a pilot plant is the manufacturing of discrete physical products, from small-batch production to dedicated line production. The pilot plant is not focused on producing products, so the flow of products through the pilot plant does not need to be continuous, uninterrupted, or reliable. What is more, where virtual components of the plant may only render simulated outcomes, the physical components may use semi-finished products that have followed a different route than envisaged in the production environment. With that, the 'pilot plant as a whole' merely exists by virtue of the platform that represents the separate physical components and virtual components as well as their mutual interactions. Both types of components, and the interactions, can be represented according to the perspectives of the stakeholders involved. Therefore, a virtual component is not 'just' a model of a machine or sub-system in the pilot plant; it consists, rather, of a set of coherent, matching, and aligned simulations and models. This is especially relevant for the many situations where new production processes, resources, machine tools, materials, or product designs are innovative beyond currently available expertise and experience. Each of these simulations or models covers a subset of all the perspectives involved, addressing (for example) logistics, sustainability, mechanical process simulation, or ergonomics.
The pilot plant concept is recursive, implying that any sub-system in the pilot plant is in effect a pilot plant on its own. With that, the same approach applies to system components at different levels of aggregation. In other words, a component (either physical or virtual) can consist of multiple components (again, either virtual or physical). Therefore, a pilot plant can be build from only a very small number of typifications, even though these can have a multitude of manifestations and instantiations. This facilitates establishing a pilot plant, but also makes the pilot plant easier to maintain and more transparent to understand. Given this independence of levels of aggregation, some perspectives involved may see a different system hierarchy than other perspectives. Whereas from a traditional process-oriented viewpoint this can be extremely confusing, from an informationoriented viewpoint it merely implies that all components in the pilot plant are interrelated in an overall network, where the relations imply different denotations for different perspectives.
Depending on the perspective, the overall network manifests itself accordingly. The network is an autorarchy: each perspective can recognise or see its 'own' prevailing hierarchy in the network [3]. 46 From the essential components and the possibility to interrelate them within a certain perspective, an overall pilot plant (or any sub-system thereof) can be tailored according to the needs. This is where both the effectiveness and the efficiency of the pilot plant are clearly visible. To elaborate on this, section 4.1 depicts a scenario that is based on a generalisation of a number of research observations from projects in industrial practice.

Use case scenario
Any company will have extensive knowledge, expertise, and experience on their existing production line. Often, for example, logistic consequences of stressors, temporary stock-outs and disturbances, as well as impacts of product portfolio proportions and change-over times, are known. Also, the technical behaviour of assets and processes will hardly cause surprises that cannot be related to a clear cause. However, in adopting a new technology or in changing production speeds to numbers outside the scope of the current solution, some of the established self-evident givens can no longer be taken for granted. With that, the company can establish a pilot plant that first captures the current situation to allow simulations to represent the behaviour of the physical assets. In some cases a robust model is available; often more elaborate simulations are available or can be made; but very often, only typifications of components are required. For example, if the same component is expected to be re-used in the renewed environment, the logistic perspective may require only a quantification of the component's output; how that output is actualised is hardly relevant.

Existing assets
With that, many components in an envisaged new production line can reliably be treated as having deterministic, reproducible, and predictable behaviour. Moreover, if the component currently is unlikely to be a technical or logistic bottleneck, there is actually no need to invest early in such an asset. After all, there is no immediate reason to test or optimise the asset. Such an asset can remain a virtual component of the pilot plant until the plant is nearly finished, although already providing the pilot plant with modelled/simulated input on its reliable behaviour. This saves space and time, while allowing engineers to focus on the components that (are expected to) show less consistent behaviour.

4.1.2
New technology/process For the new technology, it can be that laboratory-scale proofs-of-concept have already demonstrated the technical validity of the process. Under industry conditions, the ultimate production line will probably require much faster and more reliable behaviour. This industrialisation step is often quintessential in investment decisions, as the technical bottleneck should not be in the use of the new technology. However, it might be that even the production asset related to the new technology still has to be developed. With that, the pilot plant offers a contextualised opportunity to build the physical component, immediately considering the future surroundings and relations of that component. Moreover, when working on, adjusting, and optimising the physical component, its future behaviour in the overall production network can already be assessed, allowing for immediate feedback into the development process of the asset. The development of any new type of asset will not only be faster and more robust: it can also be done under the influence of the (modelled) behaviour of the entire production environment without influencing that environment itself.
So assets that will be technically critical in the new production environment will probably be physically realised and optimised in the pilot plant, until they can become a robust part of the ultimate production line.

4.1.3
Selection of alternatives Sometimes alternative machine tools or assets are available to execute steps in the process (e.g., a new version of an asset, different vendors, or different specifications). Installing the different alternatives physically and comparing them is not only not feasible because of the investments involved; more relevant could be the lead/delivery time after ordering an asset, especially if it is complex or custom-built. Here, being able already to simulate the different alternatives as part of the production environment gives insights into both the technical and the logistic behaviour of the asset. Vendors can often provide models or simulations of their assets or their processes. Even comparable existing assets can serve as inputs for decisions, as dedicated measurements can be fed remotely into the pilot plant. Such testing can quickly show whether the asset or process can become an effective and efficient part of the environment; rudimentary simulations may already be instrumental in avoiding substantial errors or even plain stupidities that would heavily impact later 47 developments. Even simulating how an asset will be physically placed in the envisaged environment may uncover issues related to accessibility and collisions, or permitted floor load, for example.

4.1.4
Capacity of assets A different type of benefit is available in assessing components that will have multiple instantiations in the ultimate production environment. For example, a production environment may host multiple automated guided vehicles, pick-and-place robots, or duplicates of the same production machine or transportation devices. In these cases, any testing and/or optimisation that requires the physical presence of the component can generally be done on only one of its instantiations. This instantiation can assume the different roles its counterparts will play, thus reducing early and potentially unfounded investments. Also, premature decision-making is avoided so that the adaptability and flexibility of the production environment under development is not limited by potential solutions that have been converted into constraints.

Transferral of pilot plants
The life span of a pilot plant can range from weeks to more than a year. When the pilot plant has reached the required level of completeness and maturity, it consists of physical components that are located at one or more shop floors, and of virtual components that represent well-understood or duplicate assets. Additionally, optimised models of technical and logistic processes (ranging from physical/mathematical via simulations to heuristics) connect the components. Subsequently, the company can instantiate the entire pilot plant in their primary production environment. Most physical components are then moved to the new location, where new assets are also delivered justin-time. As preparations take place externally, adding/replacing sub-systems can be as quick and unobtrusive as possible.

Constitution of pilot plants
From the use case scenario, a pilot plant can be defined as a networked set of entities that jointly represent an anticipated production environment, purposefully and feasibly integrating technical, logistic, and business viewpoints. The pilot plant is the backbone for the development process of that production environment. It is not only able to capture, align, and integrate information, but also to simulate possibilities, variants, and alternatives based on that information, simultaneously providing indications of (for example) performance indicators. Figure 2 shows the developed overview of the elementary building blocks in a pilot plant; any asset (virtual or physical) is related to other assets by one or more relations that bear meaning for different perspectives. One of the most relevant types of relations is the 'consist of' relations, allowing sub-systems to be built in the system, and enabling a pilot plant to consist of pilot plants. Any component exposes behaviour, again differing for different perspectives. Where the component is physical, behaviour can be measured or derived from models or simulations. For virtual components, behaviour is based on models or simulations. Even for virtual components, the models can be based on real-life conditions -for example, from previously stored information or from measurements at comparable assets at different locations.

Figure 2: Elementary building blocks in a pilot plant, and their relations
With that, a number of characteristics of pilot plants emerge:  Modular: Any component in a pilot plant is defined as an entity with explicit interfaces with other entities. Therefore any entity or sub-system is a module that can be replaced by another module with (largely) the same functionality. The pilot plant can therefore be composed of pre-defined modules or black-box modules that are still under development.


Evolving: There is no need to establish the entire pilot plant; given the considerations on premature or unnecessary investments, actualisation can closely follow development decisions. At the same time, pilot plants can run ahead of those decisions by exploring variants and possibilities. Therefore, the pilot plant not only captures the decisions and their rationale, but it also is a 'sparring partner' for engineers to test and probe ideas and compare alternativesespecially in addressing novel processes for which no mature production equipment is yet available.  Timely/temporary: Any pilot plant exists only temporarily. It aims to be dismantled and instantiated as part of the primary production environment of the client. Because only relevant assets are present or are being developed in the pilot plant, the efficiency of transferring the pilot plant to the client can be really high.  Reconfigurable: Because many of the components in the pilot plant are virtual, their configuration, location, and behaviour can be changed almost in real-time. Even for physical components, individually replacing or repositioning them is relatively easy, due to the modularity of the pilot plant. With this, different layouts can be simulated or tested, leading to both technical and logistic optimisation.  Scalable: In many cases, especially for batch manufacturing, a production environment will host assets that are identical or comparable. A pilot plant can physically contain one of these assets, extrapolating its functionality, capability, capacity, and behaviour to the envisaged production environment. If the performance of one of the components (either physical or virtual) becomes critical or precarious, this might give rise to even more dedicated research of added assets in the pilot plant.
Overall, a pilot plant exploits these characteristics to bring together current practice, ongoing research, and future manufacturing environments. Research and industrial practice concur, for the benefit of both. Not only can research in the pilot plant further industrial applicability by offering robust optimisation and application of new processes, but research also benefits substantially from immediate and realistic feedback from sub-systems, improving not only simulations and models, but also their input. The constitution of the pilot plant allows for effective and efficient trials, thus focusing the research and development initiatives on those sub-systems that have the most added value for the overall production environment.

Learning in pilot plants
One specific aspect of pilot plants that significantly changes how companies can adopt new production environments or effectuate changes to an environment is related to learning. Existing production environments only have limited opportunities for learning -and especially for making mistakes. This implies that (re)training employees often relies on artificial approaches or even on dedicated standstills for educational purposes. Pilot plants represent a fully working (sub-system of a) production environment, making them excellent training environments or learning factories [12]. This is substantiated by the fact that trainees do not endanger or disturb the actual production environment. Trainees can repeat, vary, and discuss their activities while simultaneously being able to see the repercussions of their actions on the different perspectives involved. This implies that, if the pilot plant is mature enough to be converted into an actual production environment, the staff are already trained and employable. Also, manuals and instruction materials can be ready and can have been tested. This significantly increases the efficiencies of the start-up phase of the new production environment.
However, what is -at least -equally important is that the pilot plant acts as a learning factory in a different way: as a factory that learns from being used. If, during the development and realisation of the pilot plant, staff are simultaneously trained, the behaviour of that staff can be immediately used to improve the development of the plant. If the staff encounter any impossibilities, inconveniences, or unsafe situations, the development cycle can immediately take that into account, without a posteriori adaptations, changes, or investments. Even more, technical staff can be assumed to be a valid sparring partner for discussion possibilities or variants; often operators and line managers are quite effective in making sure that development engineers live in the real world. Also, any quickly developing habits that are observed in the pilot plant can lead to purposeful and quick alterations to the development cycle. With that, the actual usage of the pilot plant is a valuable contribution to its development, from a technical, logistic, and ergonomic perspective. 49

SIMULATION, SENSORING, AND INFORMATION AQUISITION
The pilot plant as depicted in section 4 seems to have unlimited access to any data or information that might be available in the production environment to fuel decision-making. Moreover, the information appears to be complete, reliable, certain, and timely, and even a historic base is required for extrapolations and comparisons. Besides, as regards the perspective-dependent relations between the components, the network-based approach claims to be able to capture, structure, and maintain the entire overview of the information landscape in the pilot plant. Obviously, reality is unruly. One of the main reasons to work with a pilot plant is, after all, that not all information is available in an unequivocal and transparent manner. So, the effectiveness and efficiency of a pilot plant is heavily related to its ability to maintain the information overview of the entire plant and its ability to obtain the appropriate data/information of sub-systems at any level in the pilot plant quickly, purposefully, and decisively. The latter implies, for example, that the pilot plant must be capable of determining the temperature of a forming tool on a press brake with the same approach and ease as when determining the overall logistic impact of exchanging a machine tool in the packaging line for a new one. Moreover, the plant must be capable of conveying such information to the appropriate stakeholders. Therefore the pilot plant requires a structured, robust, and agile backbone, and an astute way to obtain data and combine that into meaningful information. For the backbone, the digital twin concept is employed (see section 6); acquiring the appropriate information is based on combining measurements, models, and simulations.

Making information available and fit for decision-making
As can be deduced from the depiction of pilot plants in section 4, there are two main ways in which information drives the pilot plant. Firstly, processes (either physical or virtual) that are running need monitoring and diagnostics for the main purpose of process optimisation. Secondary purposes are, for example, predictive maintenance and quality/ reliability validation. Secondly, parts of the pilot plants that have not yet reached adequate maturity require dedicated input to guide the development of the asset or the process.
The latter situation focuses on obtaining data to improve the understanding of the behaviour of the pilot plant component in the context of its function and environment (see also Figure 2). For example, in implementing a new process for processing thermoplastic composites, the behaviour of the process step will probably depend on (variations in) the material or the semi-finished product that is the input, on process parameters (such as pressure, temperature, and speed), and on environmental characteristics (such as air pressure, temperature, humidity, and even light). Beforehand, it is well-nigh impossible to model all these influences adequately in a theoretical model that addresses all the variables in the right way with the appropriate priority. Moreover, theoretical models are often fragile with respect to the emergence of new influencing variables or the introduction of new parameters. At the heart of the pilot plant is the ability efficiently to build sufficient understanding of such processes or assets to make them a reliable part of the production environment.
In many cases, at least partial models, theories, best-practices, or laboratory experience are available as a starting point to describe adequately the behaviour of a process or an asset. However, such models do not capture the entire asset for all perspectives. Moreover, sufficient data is usually not available to feed these models with realistic input. For that reason, pilot plants use the approach shown in Figure 3.

Figure 3: Modelling approach in pilot plants
Here, the main goal is, by means of a closed description in a clear scope, to foresee asset behaviour based on known conditions. Whereas many existing approaches start from the available data or 50 information and try to convert that in a feed-forward predictive model, the pilot plant reverses that approach. Once it is established what result is required, and with what accuracy and awareness of sensitivity, then available knowledge, theory, and existing models are used to determine a rudimentary structure to capture process parameters and machine tool settings, as well as their known or projected relations. Based on sensitivity analysis, relations are clustered according to anticipated impact. This leads to an overview of the data/information that should be available to render a meaningful outcome. Describing the mechanisms that drive this process is beyond the scope of this publication; but the main underlying assumption is that a deterministic relation between input parameters and behaviour will exist, although that relation may not (yet) be known, understood, or expressible.
This results in a modelling effort in which the model is constructed and the input for that model needs to be established. Simultaneously, the accuracy and variability of that input is assessed, leading to an immediate sensitivity analysis of the model under development. Finding the input can be done in three major ways: by means of models, simulations, or measurements. If adequate models are available, they are obviously a reliable step in the process. However, in many cases, process simulations (such as Finite Element Method based approximations) or heuristics are a better way to relate parameters to behaviour. However, both models and simulations in essence rely on adequate information from the actual process. Hence, pilot plants are instrumental in using sensors on the physical assets, such as those integrated in IoT approaches. In a flexible and reconfigurable manner, measuring instruments can be connected to the assets to establish the required input -the aim being only to establish the model, or for later in-line process control as well. In the pilot plant concept, it is also possible to place virtual sensors on virtual components of the pilot plant, providing modelled input if no actual asset is present. Sensors can also be used on external resources to provide meaningful data as the basis for process model development.
The more information is available, the better that the simulations, parameters, models, and variables can be interrelated to describe the process or asset behaviour. For example, outcomes of simulations, theories, and existing models can be compared; simulations can provide models with varying input for sensitivity analysis (or the other way around); measurements can be used to feed simulations and models; and they can also be used to determine their reliability, sensitivity, drift, and stability. Quite relevant in this respect is the observation that, in many cases, adequate simulations might be available (such as finite element analyses), but their complexity -and with that, calculation times -prevents them from being used integrally in industrial situations in real time. In these cases, pilot plants use an approach in which a simplified model is used in real-time actual production. This model is driven by existing models and on-line simulations, bur mainly by off-line simulations. In such cases, extensive off-line simulations are used to approximate the relations between input parameters and process or asset behaviour, based on many discrete simulations of conditions. With that, a low-order mathematical model emerges that can be used both on-line and in-line, whereas the background calculations can continuously improve the mathematical model. Because measurements in the relevant sub-system of the pilot plant serve as the input to the off-line simulations, the simplified mathematical model converges to an adequate behaviour model of that sub-system. With this, real-time adaptation of, for example, process parameters is available, based on robust optimisation driven by off-line simulations.

DIGITAL TWIN AS THE ENGINE FOR PILOT PLANTS
The pilot plant requires a structured, robust, and agile backbone to represent all the relevant information for all the stakeholders involved. With that, the information can drive the pilot plant and its development. In other words, to provide engineers with a sound basis for making the right decisions in the right way, a combination of development models, simulations, and real-life data is required. The digital twin concept integrates these aspects, thus coherently and consistently replicating the current state of the product or the production environment [20], while simultaneously being able to represent envisaged future states. The digital twin evolves with the development cycle through the entire value chain, providing structure while giving meaningful access to tools, methods, and captured data.
The digital twin concept embraces much more than the sheer replication of existing assets. The concept combines the notions of digital twin, digital master, and digital prototype. The digital twin itself, as currently adopted as a de facto label, focuses on mimicking actual assets under different 51 conditions. However, any such asset is an instantiation of the product or asset type that is the result of product development. For example, product developers establish the product definition or model that is expected to have a certain behaviour in a certain environment under certain conditions. This product definition is captured in the digital master, where the digital twins accompany the actual physical products that are produced according to that product definition. As an example: if a production environment has two production assets of the same type, they both relate to the same digital master; but because of their specific individual characteristics (maintenance and repair record, wear, usage, planning, and history), they have different digital twins. It goes without saying that the digital twins can feed and drive the further development of the product definition in the digital master. To explore whether planned improvements and adaptations of the product definition are indeed purposeful, effective, and efficient, any such changes can be explicitly evaluated by means of digital prototypes, each representing (variants of) expected evolvement of the digital master. These prototypes can be tested as part of the pilot plant, challenging their functionality and behaviour both virtually and physically.
With that, the digital twins concept addresses various system levels in the value chain, from components and products, via machines and production lines, to factories, companies, and beyond. By traversing these different levels, digital twins interrelate the design, production, and throughlife aspects of products and production environments alike, allowing for connected decision-making and understanding the impacts of those decisions in a versatile manner. They bring together, for example, product requirements and definition, developer insight, model-based simulations, behaviour and control mechanisms, and data from IoT applications. At the same time, this allows for dedicated and tailored understanding, visualisation, and decision-making for specific perspectives in the development cycle. Digital twins can be questioned, adjusted, varied, and probed while providing simulations that are independent of, but always represent, the tangible pilot plant components. They aggregate findings and measurements from individual products or machines into insights that underpin and drive development cycles, leading to the robust development and optimisation of products, processes, and production environments.

What-if analyses
The digital twin concept allows underpinned 'what-if' analyses on proposed alterations or assessed deviations in the system to be done. This allows for effective decision-making, but also enables the digital twins to learn and evolve from the development cycle and from simulations and amassed feedback from product instantiations. They simultaneously follow, predict, and drive the development processes of products and the production environments that engender them. Therefore the digital twin concept acts as the intelligent digital counterpart of reality, whether that is current, anticipated, or designed.
In pilot plants, the evolvement of knowledge, models, and behaviour actually thrives on observed variations in both physical and virtual processes and assets. Such variations can be both intentional (to understand better, for example, accuracy, variability, and sensitivity), and unexpected or inexplicable. In both cases, the pilot plant should be able to respond adequately to such stressors. For that reason, the digital twin concept in the pilot plant inherently includes an approach for the 'what-if' analysis of imposed or occurring stressors. The pilot plant (or any sub-system thereof) is presented with hypothetical, yet realistic, situations, from which the underlying models and simulations are used to explain or improve the performance of the plant. With that, the responsiveness, robustness, and adaptability of the planned pilot is assessed and purposefully improved where possible. Obviously, this starts with having a feasible solution that is strengthened by and because of its employment. With that, the pilot plant focuses on the components and relations that are indeed critical for its overall functioning in the different perspectives (see section 4). Ideally, the pilot plant can 'learn' the most from what-if analyses that have an impact on the most sensitive or critical components of the plant. Essentially, the converging way in which models, simulations, knowledge, and immediate feedback from both physical and virtual components are combined to improve the pilot plants, its constituents, and their behaviour, should make the pilot plant an antifragile system [19] because of the what-if analyses employed. 52

VIRTUAL DASHBOARD
For the engineers involved, any pilot plant, its digital twin(s), and all the perspectives involved will present themselves as an overwhelming arsenal of data, tools, methods, and techniques. There are also many differences in the fields of expertise, language/jargon, system level, cultures, and opinions that complicate multi-stakeholder decision-making. Even if unequivocal information and/or digital masters/prototypes/twins are available, a shared and unambiguous understanding in decision-making is not obvious. Additionally, decision-making easily becomes less effective and less efficient because of excess information that is irrelevant to the current situation and perspective. Significant amounts of effort and time are lost in merely preparing the required information content, simultaneously addressing the impact of incomplete, uncertain, and missing information. Here too, a shared appreciation of the information content is often lacking. To address this, so-called 'virtual dashboards' can be used to support multi-criterion and multi-stakeholder decision-making and control by providing tailored yet adaptable and flexible insight into the information that underlies decisions. Virtual dashboards build on the realm of information, models, scenarios, simulations, tools, and techniques available, allowing stakeholders to address specific subjects or aspects of a production environment, for example. For the data that underlies the information content, interfaces to different systems (like Enterprise Resource Planning or Product Data Management) are built; also cloud solutions such as Fraunhofer's Virtual Fort Knox are adequate interfaces to the information content.
Virtual dashboards allow stakeholders to identify with any subset of the perspectives involved, because the insight in the information is presented in an autorarchic manner (see also section 4). This implies that the information content is filtered and presented according to the perspective(s) of the specific stakeholders involved -for example, in a synthetic environment in a virtual reality laboratory [5]. This has the added advantage that there is no prevailing dimension or view on the system. With this, the stakeholders can choose, for example, to 'travel with a product through the production line', to 'observe process conditions on an asset that show signs of wear', to 'focus on the overall production throughput', to 'relate production bottlenecks to product features', or to 'compare defects between machines and between product types'. Approaches to making virtual dashboards instrumental range from smart information sets, via simulations, infographics, 3D models, and visualisations to full-blown virtual reality or augmented reality applications. Depending on the way in which the information is accessed, virtual dashboards are especially appropriate to connect to and control remote locations. Moreover, a virtual dashboard can ostensibly integrate multiple environments into one coherent whole, presenting the pilot plant as one integrated production environment, although some of the physical components may not (yet) be located at the same facility. In addition, a virtual dashboard -for example, by means of augmented reality -can render virtual components as observable constituents of the production environments [21] that can also be controlled and interacted with. Therefore, a virtual dashboard gives meaningful access to a pilot plant that represents a production environment that is evolving and currently is a conglomerate of models, physical and virtual components, experience, data, information, simulations, expertise, and knowledge.

CONCLUDING REMARKS
Pilot plants provide a new paradigm for establishing production environments without the customary disadvantages and disruptions. Moreover, they provide a means to use research and development investments effectively by focusing on the aspects that are most relevant from the different perspectives involved, while providing a smooth transition to industrial implementation. Not all approaches and tools used in the pilot plant concept are new or disruptive. It is rather the amalgamation of existing approaches and the information-based paradigm that make the digital twin concept the enabler of a purposeful and efficient way of thinking about production environments under development. Pilot plants do not need to start from an empty shop floor dedicated to facilitating the process. Currently, the Fraunhofer Project Center at the University of Twente carries out a number of industrial projects that, at different scales and levels of aggregation, employ the pilot plant concept. Sometimes the focus is on individual assets, sometimes on overall factorylayout, and sometimes on processes that are new -at least to the company. But in all cases, the digital twin concept is used to structure the information content and, with that, the development of the pilot plant into a mature solution that can be seamlessly integrated into the planned production environment. Based on the experience gained so far, establishing a more formal facility 53 for pilot plants at the University of Twente is planned and is currently under development. Here, together with researchers, clients will use the location and employ the digital twin concept, measurement, IoT solutions, and modelling/simulation efforts. Virtual dashboards ensure that all stakeholders can be represented and can have sufficient influence on the development from all the perspectives involved. This will create effective and efficient -but also flexible and maintainable -new production environments.