Integrating Organizational and Technological Aspects of Digital Twin Engineering Benjamin Nast1, Achim Reiz1, Kurt Sandkuhl1 and Janis Stirna² 1 University of Rostock, Albert-Einstein-Str. 22, 18059 Rostock, Germany 2 Stockholm University, Borgarfjordsgatan 12, 164 55 Kista, Sweden Abstract Digital Twin (DT) is a concept that has attracted much scientific research and industrial development during the last years. The basic idea is to connect (physical) facilities or devices with digital representations to facilitate real-time monitoring, manipulation and prediction of behavior. The focus of this paper is on the integration of organizational aspects of digital twin engineering (DTE), such as business processes, organization structures and capability development, with technological aspects, such as architecture design, technology selection and system implementation. The paper proposes to use a model-based approach anchored in experiences from enterprise modeling and capability management. An industrial case study is used to demonstrate the different steps of the approach. The industrial case shows feasibility of the approach and relevance of digital twin development for digital transformation. Keywords Digital transformation, digital twin, enterprise modeling, capability management, energy efficiency 1. Introduction Digital transformation of enterprises and engineering of digital twins both are topics that have been attracting substantial scientific research in computer science and business information systems. Digital transformation, in general, denotes the adoption of innovative digital technologies, such as big data, artificial intelligence, blockchains or digital twins, in the digitalization of an organization’s business model and its operations [1]. Digital twin (DT) can be defined as “a dynamic virtual representation of a physical object or system across its lifecycle, using real-time data to enable understanding, learning and reasoning” [2]. However, although DTs can be an element of digital transformation and digital transformation can be a driver for DT development, the intersection of both topics has not received much attention in research, which was confirmed by a literature study published in [3]. This study also revealed that digital twin research predominantly focuses on technological questions of DT design and operations and that so far, the aspects related to the fit of the DT in the organizational design and integration with the business model are covered in research only sparsely. To address this gap, our previous research proposed to use enterprise modeling and capability-driven design for supporting the development and management of DTs from an organizational perspective. Enterprise Modeling (EM) is an approach that can be applied for various organizational design problems by means of multi-perspective conceptual modeling. EM captures organizational knowledge about the motivation and business requirements for designing information systems (IS) [4]. Hence it has the potential of capturing and representing the organizational motivation and integration of DTs. An important aspect of operating and managing DTs is the possibility to configure their functionality when required by situational changes in operations. Capability management, and in particular Capability Driven Development (CDD), has been proven applicable for managing IS in changing context [5]. The result of our previous work was a conceptual approach for DT design integrating enterprise modeling and capability-driven design and development. Although some elements of this approach (see section 4) were evaluated in a feasibility check, a thorough evaluation in practice is still PoEM’2022 Workshops and Models at Work Papers, November 23-25, 2022, London, UK EMAIL: benjamin.nast@uni-rostock.de (B. Nast) achim.reiz@uni-rostock.de (A. Reiz) kurt.sandkuhl@uni-rostock.de (K. Sandkuhl) js@dsv.su.se (J. Stirna) ORCID: 0000-0003-4659-9840 (B. Nast), 0000-0003-1446-9670 (A. Reiz), 0000-0002-7431-8412 (K. Sandkuhl), 0000-0002-3669-832x (J. Stirna), © 2022 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). CEUR Workshop Proceedings (CEUR-WS.org) needed. Hence, the objective of this paper is to perform this evaluation in an industrial case to identify improvement potential and collect experiences of integrating organizational and technical aspects of DT engineering. The main contributions of this paper are (a) a case study for DT development encompassing all steps from identifying organizational goals to the implemented solution, and (b) the evaluation of the DT design approach in a naturalistic setting. The rest of the paper is structured as follows. Section 2 gives background to digital transformation, digital twin engineering, EM and CDD. Section 3 describes our research approach. Section 4 presents the previously developed approach for DT design integrating enterprise modeling and capability-driven design and development. Section 5 shows the application of the DT design approach in an industrial cases study. Section 6 discusses the results of evaluating the approach and the experiences gained. Section 7 provides concluding remarks. 2. Background and Related Work Industry 4.0 [6] offers a vision of industrial production and management based on big data, artificial intelligence and cyber-physical systems. At its core lies the concept of digital transformation, which essentially drives the process of organizational change towards technologies that can drastically improve company’s business model [7]. In many cases this includes the transformation of existing products or services that are enhanced with digital components or into purely digital variants that offer advantages over traditional, solely physical, products [8]. The focus here is on the disruptive potential of digital technologies and the resulting substantial change in markets and social and economic consequences [9]. A key area of development of Industry 4.0 as well as of its envisioned successor Industry 5.0 [10], is that of digital twin. The reminder of this section will outline the main aspects of digital twin development as well as give a brief background to EM and CDD. 2.1. Digital Twin Engineering DTs are usually designed and operated in the context of Industry 4.0. In the field of production systems, there is a substantial amount of work on DTs. The purpose of many DTs is to offer a virtual copy of a physical entity. This is however only one way of developing and managing digital twins. They also offer the possibility to change the business strategy of how existing products or services are developed, sold, and operated. This is the focus of this paper. More specifically, the congruence of business strategy, digital transformation, and DT. With respect to the state of the art in DT development there are a number of relevant contributions. For example, Mittal et al. [11] investigated what manufacturing small and medium-sized enterprises (SME) need to successfully adopt Industry 4.0 and identify 16 specific requirements for SMEs addressing smart manufacturing solutions for specialized products including DTs. Schumacher et al.[12] proposed a maturity model for assessing Industry 4.0 readiness and identify nine dimensions of maturity and 62 maturity items in their Industry 4.0 Maturity Model. The maturity items include technology and product related aspects, like digitalization of products, product integration into other systems, and DTs. Considering the objective of this research our primary focus is on supporting the fit of the DT to the organization’s needs in the Industry 4.0 program, which requires a methodological approach to capturing, analysis, and documentation, which can be supported by conceptual modeling. There have been several investigations of the needs for modeling support for Industry 4.0. Hermann et al. [8] present four main principles of industry 4.0, namely:  Interconnection between various actor types, such as human and machine.  Information transparency supporting linking various data types and sources.  Decentralized decisions based on the combination of local and global information.  Technical assistance by IS for the purpose of aggregation and visualization of content. Wortmann et al. [13] report on a systematic literature review and discusses following the expected benefits for modeling for Industry 4.0: reducing time (development time, time-to-market), reducing costs (of development, integration, configuration), improving sustainability, and improving international competitiveness. In conclusion, the current state on DT engineering is such that the most of the focus has been given to approaches to information system design and development, but without a sufficiently holistic consideration to how the DT design is integrated the organization’s business and human aspects. 2.2. Enterprise Modeling and Capability‐Driven Design Enterprise Modeling (EM) is a versatile approach and is able to tackle various organizational design problems by means of multi-perspective conceptual modeling. EM captures organizational knowledge about the motivation and business requirements for designing IS [4]. EM has been proven to be able to deal with various kinds of organizational problems, including wicked problems, that require discovery, analysis, and consolidation of multiple stakeholder views and preferences. Hence, it has the potential of capturing and representing the organizational motivation for DT design. A key aspect of operating and managing DTs is to configure and adjust them according to the situational changes in operations. Capability Management, and in particular Capability Driven Development (CDD), has been proven applicable for managing information systems (IS) in changing context [5]. More specifically, CDD supports generation of monitoring dashboards from models that include context elements, measurable properties, KPIs as well as rule-based based adjustments based on context data, which makes it, together with EM, suitable for DT design and continuous management. 3. Research Approach This study is part of a research program aiming to provide methodical and tool support for integrating organizational and technical aspects of DT engineering. Specific focus of the methodical and tool support is on suitability for small and medium-sized enterprises (SME). The overall research program follows the five stages of Design Science research [14], namely, problem explication, requirements definition, design and development of the design artifact, demonstration, as well as evaluation. This study concerns the steps of demonstration and evaluation of the design artifact, which is the methodical and technical tool support for DT design. The part of our research presented in this paper started from the following research question which is based on the motivation presented in section 1: RQ: How effective is the DT design approach in a real-world situation for integrating organizational and technical aspects, and what is its improvement potential? The research method used for working on this research question is a descriptive case study in combination with an evaluation strategy. Based on the research question, we identified an industrial case suitable for studying the organizational and technical aspects of DT design. Qualitative case study is an approach to research that facilitates exploration of a phenomenon within its context using a variety of data sources. Within the case studies, we used three different perspectives, which at the same time represent sources of data: we analyzed documents about business objectives and work processes; we performed workshops addressing required functionality and technology of DTs; we interviewed domain experts; and we developed the DT design (action research). Yin [15] differentiates case studies explanatory, exploratory and descriptive. The case study in section 5 is considered descriptive, as it describes the phenomenon of DT development and the real-life context in which it occurs. Details of the evaluation strategy are explained in section 4.2. 4. Capability‐Driven Management of Digital Twins This section briefly presents the previously developed approach for DT design (section 4.1) and the strategy for evaluating this approach (section 4.2) in an industrial case study section 5. 4.1. DT Design Approach The approach for DT design was developed with the main idea to support the core tasks of development and management of efficient DTs. The approach consists of the three main activities, namely, capturing the business motivation and integration into the business model, design of the DT, and delivery and operation of the DT (Figure 1). From an organizational perspective, these three core tasks are neither independent and isolated from each other nor strictly sequential processes performed only once. For example, the business motivation for a DT may change over time, which would have effects on the design of the DT; or observations during operations of the DT might imply changes in the DT design or indicate new business opportunities that affect the business motivation. Thus, the three core tasks should rather be seen as continuously ongoing interconnected sub-cycles and as part of the lifecycle of a DT. Figure 1 shows our approach for a DT development and management lifecycle that incorporates three sub-cycles. These sub-cycles can in practice be realized by Enterprise Modelling, Capability and context design for the DT, and deploying the DT in the execution environment. Enterprise Modelling includes business motivation, but also issues such as organisation, processes, and integration with the IS architecture. Figure 1: An overview of the envisioned capability‐driven cycle of management digital twins The internal steps and tasks in the sub-cycles follow the established procedures in [4] for EM and in [5] for Design and Operation. The following artifacts support the transition between the sub-cycles (grey arrows in fig.1): - EM provides explicated knowledge about the business motivation for the DT and the business context the DT has to be integrated in in the form of multi-perspective enterprise models. They have to be linked with the DT design models representing the technical details of the DT, for example by linking business processes with the functionality of the DT to support them. - Capability design allows for (1) capability based digital twin design that explicates what information is available via what service or interface from the physical twins and captures this in a context model, and (2) generates the monitoring applications for digital twin management from the context model. Context models show the dependence on local and global data in the environment as well as to adjustments of the DTs and their dashboards. - The delivery and operation sub-cycle provides data types of available data used at runtime of the digital twin. This allows extending the existing designs as well as selecting existing and obtainable data in new designs. The design provides best practices and reusable components on which the EM sub-cycle can base new business developments. The capability design models and the enterprise models need to be linked to establish the business motivation and fit of the DT. Capability designs and context models should be used for generating dashboards for DT management. 4.2. Evaluation Strategy For the evaluation of the DT design approach, we use the Framework for Evaluation in DSR (FEDS) by Venable et al. [16]. The framework distinguishes between two orthogonal dimensions of evaluation. First, with regard to its functional purpose, an evaluation can be formative or summative, i.e., aiming at improvement potential for preliminary versions or evaluating the final version of an artifact. Second, the framework identifies the underlying paradigm of an evaluation to be either artificial or naturalistic, i.e., in a lab setting or in real-world. According to Venable et al. [16], a thorough DSR evaluation originates from a state of formative and artificial evaluation methods to a more fully and realistic evaluation scenario using summative and naturalistic methods. In our case, the DT design approach already has been subject to a formative evaluation in an artificial setting (see [3]). The objective of this work is to find improvement potential (formative evaluation) by using the approach in a real-world case (naturalistic setting). The main goal of this evaluation episode was to evaluate the approach’s effectiveness, i.e., that it works in a real situation of DT design. To evaluate effectiveness, this episode focuses on requirements to DT design approaches. The development of the DT design approach presented in section 4.1 was based on industrial requirements (IR) and requirements extracted from scientific literature (SR). Both sets of requirements are relevant for the evaluation of the approach and summarized below. IR1: DTs have to support the goals and business models of the company. DT development activities usually are motivated by business needs that emerge from, e.g., digital transformation, process or product innovation, or changes in the market. The primary goal is not to implement DT per se but to provide services or create a platform which can be facilitated by DTs. IR2: DTs have to be part of operations in an enterprise. DTs either have to support operations in the own or the client’s production, or to facilitate value-added services on the customer side, like, e.g. predictive/preventive maintenance. IR3: What aspect of reality has to be represented in a DT and (IR4) what features and parameters have to be visible in the DT depend on the organizational integration and the intended business model of the company. IR1 states that DTs must be supporting a company’s business model. When implementing business models, this means that the digital twin has to provide the information about status or operations of the product required for the value creation underlying the business model. Identification of features and parameters that have to be visible in the DT can be supported by developing business model prototypes and investigating organizational integration. IR5: Component developers request a better methodical and technical integration of DTs (platform) development and component development. Components in this case are sub-systems of the physical system that is subject of DT development, i.e., supposed to get a DT. Component developers request technical agreements (interfaces and platforms) and methodical agreements with the digital twin provider to allow for a smooth integration of their components into the DT. IR6: DT design approaches must support continuous engineering. Business models and organizational processes are subject to continuous improvement and so are DT features and parameters. SR1: Modelling and model management have to be supported. The different disciplines involved in DT design (e.g., business actors, IT service management, system engineers) use various types of models. It calls for multi-perspective views to integrate various aspects and artefacts of the organizational design and align them with the DT design. SR2: Adaptation and adjustment have to be supported. DTs need to be operated continuously, in various situations, and according to various business models. It can also be expected that these change under the lifetime of a DT. Automatic adjustments during runtime or reconfigurations of the solutions upon business changes may be required. This calls for continuous development and operation similar to the DevOps principle. SR3: Continuous lifecycle management pertains to two key aspects. First, visualization of operational and contextual data at runtime and then using this data and information to create new business models and DT designs as well as to change the existing ones. 5. Industrial Case Study This section describes the industrial case study used for evaluation of the DT design approach. The case study company is a medium-sized enterprise from the North of Germany that plans, designs and installs air conditioning and cleanroom facilities in larger buildings. Furthermore, they offer repair, inspection and maintenance services. Most of the air conditioning technology (ACT) used in these facilities is procured from suppliers; only a few specialized components are developed and manufactured by the company itself. Starting point for the study was the plan of the case study company to offer predictive maintenance and optimization of energy consumption services. For this purpose, the information provided by the existing control systems of ACT facilities are not sufficient because current control systems do not capture all information required. Additional sensors and control systems need to be integrated and connected to a network. The result is an Internet-of-Things (IoT) solution that forms the basis for new business services. The planned IoT solution is intended to provide diagnostic support for possible optimizations in ACT facilities and for the operational processes of the case study company. Based on the above background, an R&D was started that has the aim to develop technological and organizational support for energy optimization in ACT facilities based on IoT technology. The project did not explicitly have the aim of developing a DT of the facilities to be supervised, but it quickly became clear that a DT would be an important contribution to the project. Thus, the researchers participating in the project had the possibility to apply the DT design approach. The case study description in this section covers selected aspects of all three life-cycles included in the DT design approach (see Figure 1): section 5.1 reports on identifying the business goals and business requirements for the new energy optimization-related services that form the basis for changes in the business model. Section 5.2 addresses modelling of ACT facilities and the additional sensors to be integrated. The resulting model connects enterprise modelling and DT design, as it includes relevant information for the business processes and also is used for configuring DT of actual facilities. Section 5.3 describes the architecture of the IoT solution, which basically is the infrastructure for the DT as it focuses on information flow from physical facility to its digital representation. Section 5.4 tackles the DT operation by addressing dashboards and organizational integration. 5.1. Enterprise Goals and Requirements To understand the goals of the case study enterprise and the problem to overcome for reaching these goals was an important task in the preparation and start-up phase of the project. For this purpose, we used the method components for goal/problem modelling, process modelling and actors and resource modelling from the 4EM method [4]. The next step was identifying requirements to the overall IoT solution and the DT. To this end, employees of the case study enterprise first described to us all the desired functions of the overall system. For each requirement, a description was developed along with guidelines on how to achieve the desired goal. Those include required technical capabilities and outputs respectively functions of the human interface. Based on this information, it was then possible to identify and specify the required data for each requirement (e.g., origin or required recording duration and measurement accuracy). The requirements were prioritized in terms of importance and feasibility. Maintenance support was defined as the most important requirement. Up to now, it has only been possible to fix acute errors during maintenance work. Errors occurring only temporarily often remained undetected. Visualization of the current state of a facility (i.e., the values of different sensors and their inter-relation) and development of the values over time (historical view) are expected to make these problems visible. The automatic and permanent checking of components of a facility to detect disruptions and anomalies has the second highest priority from a business perspective. The recognition of user-induced operating problems (operator error) and the identification of avoidable excess consumption (energetic inspection) are counted as equally important. Detecting rule errors has the third highest priority: incorrect rules in control systems can cause considerable additional energy consumption that goes unnoticed. Data gathered from the system also is expected to change the way of maintenance. On the one hand, dynamic adjustment of maintenance cycles is envisioned: it is preferable to determine maintenance intervals by intensity of a facility’s use rather than on fixed time intervals. On the other hand, components with deviation behaviour should be discovered and maintained or replaced before they break (predictive maintenance). Understanding avoidable excess consumption by the system can open up new business models for the company in the future. Once sufficient data is available from many facilities, comparisons can be made between them. This is intended to detect, for example, the oversizing of a facility (facility dimensioning). Often a facility is designed for more people in a room or building than are actually present. 5.2. Modelling Language and Tool Support We used the ADO.xx meta-modelling platform [17] to develop a modelling language and tool to assist ACT technicians in designing the solution. This platform enables the realization of full-fledged modelling software, which, in addition to the modelling language, also contains procedures and functionalities in the form of mechanisms and algorithms. The modelling language for ACT facilities is based on the requirements of the case study. The classes of the meta-model represent the possible components in such facilities. Attributes contain, for example, information about the type of the components or the unique ids of sensors. The symbols are based, among other things, on the European standard DIN EN 12792 and the knowledge of domain experts involved in the project. Arrows show the logical relationship between components and airflow direction. Sensors are shown with a circle and a line to the component or place in the model. The letters indicate the sensor type. An example model of a fictitious facility (Figure 2) shows some objects of the modelling language and contains six sensors: Two each for controlling the supply and exhaust air (Temperature and CO² content). Further, the ventilators are each equipped with a sensor for measuring the pressure difference. Figure 2: Objects of the Modeling Language. Entering configuration data (information about location, operator, and components) in the tool is facilitated by dialog boxes and is the first step in creating a new facility. This input automatically creates the respective modelling objects, including the attribute values (e.g., type of the heat recovery or size of the ventilators), and thus supports the creation of the model. After an object is placed in the model, the technician can assign unique ids to the corresponding sensors. Through the technician’s input in the tool, the MQTT topics are automatically configured for the installed sensors, which can be uniquely assigned in conjunction with the facility id. Figure 3 shows an example of an existing ACT facility of the case study company. It is used to evaluate the suitability for supporting the development and configuration of the IoT solution via the tool. Figure 3: Model Example of an ACT Facility. 5.3. An Architecture for Using Models to Design IoT Solutions The design of an industrial air conditioning system is done individually for each customer. In these systems, we need a variety of sensors to understand what is happening inside the air conditioning system. However, the signals from the sensors are not readily interpretable, because often only an analogue signal of 0 to 10 volts is measured. These measurement points then need to be processed and contextualized in order to make sense of them and understand the performance of the system. These heterogenous structures impact the IT architecture as well. Data must be heavily pre-processed to be useful, and there is great potential in comparing installed systems with similar configurations. At the same time, the use of the implemented system should not require many IoT- and analysis-specific skills, but only domain knowledge. To this end, figure 4 presents the planned architecture of such a management system. The application is divided into a physical and logical layer. The former configures and manages the sensors. It is responsible for connecting sensors and gateways to the server stack, including data encryption and decryption. In our case, an application server (see Figure 4) receives the data in a binary format representing an analogue signal (0 to 10 volts). Afterwards, the data is sent to a second server-side application to process the sensor's voltage signal into a physical unit. It has the necessary calibration and interpretation information to convert the signal to the given measured aspects and also adds information on the location and type of the sensor. Figure 4: Architecture of Model‐Driven System. The now interpreted signal is sent to the logical layer via MQTT to make sense of the data, provide the processing capabilities, and generate outputs. The data arrives at an MQTT broker with an unambiguous id of the corresponding system, the kind of sensor location, and its measurement. Afterward the data is stored in a time-series database, to provide persistent storage and build the foundation for generating simple reports and analyses and more sophisticated reports based on AI-based applications. A document-centric database (Figure 4: NoSQL Database) contains the necessary background information to understand, group, and compare the air conditioning systems that are similar. Each of the various components of a new system need to be configured initially. Manually setting up each component would impose much of the complexity on the air conditioning engineer, thus requiring much costly training and limiting the application scenarios of the solution. This is solved by providing a configuration layer with two separate applications. The ADO.xx-based modelling tool gathers the required information, packs it into a JSON file, and sends it to a server application. The server application configures the processing layer: A configuration tool manages the alignment of the logical and physical stack by assigning unambiguous ids for the components. A separate tool is required to configure the physical layer itself. This tool assigns gateways and sensors to the server stack, gathers the sensor type (e.g., temperature, humidity), and connects the sensor values to the alignment ids, thus configuring the MQTT topic. 5.4. Bringing the Application to Use The overall goal of our system is to reduce energy consumption in industrial-sized air conditioning facilities. Due to legal requirements and possible warranty issues, our system does not actively interfere with the ACT control systems but informs a technician on possible wasteful settings or wrongful system behaviour. In this aspect our system can be regarded as a digital shadow [18]. Staff is then responsible for taking corrective measures. The inspections of the industry-scale air conditioning systems that are mandatory in Germany are performed manually by a visiting technician. The technician checks the current behaviour of the system and the wearing parts. The starting point for additional analysis functionality provided by the DT is relatively simple dashboarding and alarming functionalities. For example, a simple historical view of the airflow can reveal whether the air conditioning system shuts down properly in the evenings and off-week. Likewise, an alarm can be configured for deviations from such a scenario to inform the technician automatically. While the solution to such a scenario is trivial from a technical perspective and can be built simply on top of the time-series database, it can quickly reveal significant saving possibilities. The number of connected facilities will increase over time, thus also contributing to a rising pool of analysable data. In combination with the configuration settings on the installed systems, it shall allow us to compare similar air conditioning systems. We expect it to reveal hidden overconsumption of energy and guide improvement recommendations for existing systems. Figure 5: Example Diagram for Conveying Air. Figure 5 shows a diagram from the dashboard that also could be included in a (semi-) automatically generated report. It contains real data taken from the example facility shown in Figure 3. The calculation of the volume of conveying air requires some configuration data previously recorded via the modelling tool (k-factor, type of measurement, and number of parallel ventilators). In the example, a differential pressure measurement is performed. Based on the pressure difference measured with the corresponding sensor on the ventilator (see Figure 3) and its manufacturer-specific k-factor, the volume flow is first calculated. This can then be used to determine the volume of conveying air over periods of time. The customer is provided a web interface with diagrams like this and some automatically generated text lines to get an evaluation of the facility behaviour. All recorded data can be visualized for individually selected periods by moving the slider. 6. Discussion 6.1. Results of the Evaluation The evaluation strategy in section 4.2 put the effectiveness of the DT design approach into focus and used the defined requirements to operationalize effectiveness. Thus, we revisit the requirements and discusses if and how they were met in the industrial case. This discussion has to cover two aspects: (1) are the defined requirements valid for the industrial case? If the requirements would not be valid, the case would not be suitable for evaluating the approach; (2) how does the DT approach support the requirements? The responses are expected to uncover shortcoming and improvement potential. Table 1 summarizes both aspects for the defined requirements. Table 1. Results of the evaluation Does the DT approach fully Is the requirement valid for Requirement support the requirement? Why the case? Why? (not)? Yes; case company aims at reaching Yes; EM method supported all required IR1: DT has to support business goals; DT is considered as analysis and elicitation tasks (goal + goals / business model tool to reach this aim requirements analysis, process design) Yes; DT design used requirements Yes; DT is supposed to provide IR2: DT as part of from EM to identify required functions, “cockpit” for staff in maintenance operations design architecture and create suitable department supervising facilities visualization for DT operation Yes; roles to be supported by DT Yes; the priorities of the requirements IR3: scope of DT depends and processes to be performed in the were used to extend the scope stepwise. on org. integration organization by these roles define The continuous development and DT scope lifecycles allowed for several iterations Yes; roles and process to be Yes; the stepwise extension according IR4: features visible in DT supported and what information is to priorities (s. above; IR3) also depend on org. integration required define features in DT concerned the visible features Yes; technical components in Yes, on general level. DT design IR5: Component facilities (e.g. sensors and lifecycle includes this task as part of integration with DT communication) and infrastructure architecture design, but not how to development components had to be interoperable decide on actual integration approach Yes; requirements were defined in Yes; in particular the capability-driven IR6: required support of priority groups. Implementation of design supports the identification of continuous engineering groups was expected in iterative way mutual dependencies that is essential according to priority for continuous engineering Yes, in general. Modelling is essential Yes; case company considered part in the approach, but (a) additional SR1: support of modelling modelling as essential in domain specific models turned out to and model management engineering processes. be essential (b) model management requires additional tool support SR2: Support of adaptation Yes; case company considers Yes; see IR6, continuous engineering and adjustment adaptability of DT as essential Yes; however, the DT development is Yes: case company considers SR3: Continuous lifecycle not finished yet, i.e., if this requirement continuous improvement in management is fully met has to be decided after systematic way as essential additional lifecycles In summary, the industrial case proved to be a suitable basis for evaluating the DT design approach. At the same time, the soundness of the requirements was confirmed by the case, as all requirements were clearly visible and confirmed. Furthermore, all three life-cycles of the DT design approach proved relevant and required. The basic procedures underlying the different lifecycles were applicable to the industrial case. Improvement potential was identified when it comes to the level of detail of the lifecycle description and specificity of the different tasks for the application domain at hand. Two aspects of the improvement potential are as follows: Domain specific modelling language (DSML): the case showed the advantages of a domain- specific modelling language for DT design and linking business motivation and DT functionality. The DT design approach includes context modelling as part of the capability modelling and DT design. However, the context modelling language so far was primarily used in IT-related application cases. The engineers at the case company were not familiar with information modelling approaches in the IT sector and had problem to understand context modelling. With the switch to a more familiar way of modelling, i.e., symbols and terms used in ACT technology, the definition of requirements to DT design went considerably smoother. Thus, future work on the DT design methodology should investigate when and how to develop and integrate a DSML. Model management environment: the DT design approach supports model management from a conceptual perspective by defining dependencies between models, integration of models and, for some models, model transformation. However, the approach does not contain recommendations for model storage, versioning, and management. Although this basically is a question of tool selection, a best practice recommendation would support the approach. 6.2. DT integration and Business Ecosystem Thinking The application case presented in this paper discusses DT development from the point of view of developing a specific DT for a specific prototype air conditioning unit. However, the use case company’s requirements extend further. It intends to compare similar units installed in different buildings in order to identify possibilities for energy savings, common scenarios of error occurrence, maintenance needs, as well as design improvements. This requires the integration of the individual DTs into management dashboards and the company becoming what is often denoted as real-time enterprise [19]. However, making a DT part of a system of systems is not without challenges as discussed by Michael et al. in [20]. The most relevant challenges to this application case are: (1) vertical composition of DTs for the inclusion of them into dashboards visualizing various aspects of operating DTs according to the business strategy in terms of goals and KPIs; (2) composition of DTs for different perspectives, e.g., presenting the data for the purpose of energy savings by avoiding unnecessary wasteful energy requires data that are internal, but for example, programming the DT so that a building is precooled or that temperature comfort levels are changed in time periods when the energy costs are especially high require integration with temperature forecasts and energy pricing data, which are external (c.f. for instance [21]; (3) rights and roles in the integrated DT would have to include not only the operational managers of the air conditioning units, but also maintenance managers and design engineers. Some of these challenges can be addressed by setting common data exchange principles and an integrated system architecture. But this is not sufficient for efficient operation of energy efficient buildings and the use case company should be able to contribute to this goal. Building operation and management can be seen as a business ecosystem that needs to operate in a resilient and sustainable fashion for all of the actors involved – building technology providers, such as the use case company, building owners, operators, as well as occupants. In this regard, one can envision that in the future the use case company could consider having a system that provides certain data views, for example, concerning energy consumption during certain time periods to external actors, such as building managers or occupants. Then it comes to design and management of such a constellation of actors it is important to realize that they might have conflicting goals and KPIs, e.g. effort spent on adjusting and managing the air conditioning unit by the building operator vs reduction of the energy costs for the occupants. To consolidate this diversity of goals we propose to apply the principles of digital business ecosystem and to map the roles of each actor in the ecosystem. For instance, who acts as governor, modular produced, integrator, and customer is important to analyze along with the business goals of their individual companies and how they contribute to the overall business goals of the ecosystem. This approach of business ecosystem analysis is briefly presentenced in [22]. 7. Concluding Remarks This paper is a part of a design science research project on methods and approaches for DT design and engineering. It has presented an approach to DT design that integrates EM and capability modelling, demonstrates how it has been used for an industrial use case DTs for air conditioning systems. The approach taken in the use case elaboration also required development of a modelling language and a tool based on the ADO.xx platform. On the basis of the experiences of the use case we draw evaluation conclusions that the proposed approach to DT design is effective and supports the requirements identified in earlier stages of this research project. This is however does not complete the research and, as discussed in the previous section, new directions of work are to be explored, chiefly among which are strengthening the real-time management aspects and multi-actor perspective of the ecosystem of digital twins. 8. References [1] Matt, C., Hess, T., & Benlian, A. (2015). Digital transformation strategies. Business & information systems engineering, 57(5), 339-343. [2] Sniderman, B.; Mahto, M.; Cotteleer, M. (2016) Industry 4.0 and manufacturing ecosystems: Exploring the world of connected enterprises. Deloitte University Press [3] Sandkuhl, K., Stirna, J. (2020). Supporting Early Phases of Digital Twin Development with Enterprise Modeling and Capability Management: Requirements from Two Industrial Cases. In: Nurcan, S. et al. (eds) Enterprise, Business-Process and Information Systems Modeling. BPMDS EMMSAD 2020. LNBIP 387. Springer, https://doi.org/10.1007/978-3-030-49418-6_19 [4] Sandkuhl, K., Stirna, J., Persson, A., Wißotzki, M. (2014). Enterprise modeling. Tackling Business Challenges with the 4EM Method. Springer, 2014. [5] Sandkuhl, K., Stirna, J. (eds.) (2018) Capability Management in Digital Enterprises. Springer [6] Strange, R., & Zucchella, A. (2017). Industry 4.0, global value chains and international business. Multinational Business Review. [7] Berman, S. J., & Bell, R. (2011). Digital transformation: Creating new business models where digital meets physical. In IBM Institute for Business Value. [8] Hermann, M., Pentek, T., Otto, B. (2016) Design principles for Industrie 4.0 scenarios. In: proc. HICSS ’16, IEEE. [9] Berman, S. J., & Bell, R. (2011). Digital transformation: Creating new business models where digital meets physical. In IBM Institute for Business Value. [10] Breque, M., De Nul, L., & Petridis, A. (2021). Industry 5.0. Towards a sustainable, human-centric and resilient European industry. Publications Office of the European Union, Luxembourg. doi: 10.2777/308407. [11] Mittal, S., Khan, M. A., Romero, D., & Wuest, T. (2018). A critical review of smart manufacturing & Industry 4.0 maturity models: Implications for small and medium-sized enterprises (SMEs). Journal of manufacturing systems, 49, 194-214. [12] Schumacher, A., Erol, S., & Sihn, W. (2016). A maturity model for assessing Industry 4.0 readiness and maturity of manufacturing enterprises. Procedia Cirp, 52(1), 161-166. [13] Wortmann, A., Barais, O., Combemale, B. et al. (2020) Modeling languages in Industry 4.0: an extended systematic mapping study. Softw Syst Model 19, 67–94 [14] Johannesson P., Perjons E. (2014) An Introduction to Design Science. Springer [15] Yin, R. K. (2002). Case study research: Design and methods. Thousand Oaks, CA: SAGE Publications [16] Venable, J., Pries-Heje, J., and Baskerville, R. (2016) FEDS: A Framework for Evaluation in Design Science Research, European Journal of Information Systems (25:1), pp. 77–89. [17] OMiLAB: The ADOxx Metamodelling Platform, https://www.adoxx.org/live/home, accessed 2022/10/23. [18] Becker, F. et al. (2021). A Conceptual Model for Digital Shadows in Industry and Its Application. In: Ghose, A., Horkoff, J., Silva Souza, V.E., Parsons, J., Evermann, J. (eds) Conceptual Modeling. ER 2021. LNCS vol 13011. Springer, https://doi.org/10.1007/978-3-030-89022-3_22 [19] Kuhlin B., Thielmann H. (eds.), (2005) The Practical Real-Time Enterprise: Facts and Perspectives, Springer, https://doi.org/10.1007/b138980 [20] Michael J., Pfeiffer J., Rumpe B. and Wortmann A. (2022) Integration Challenges for Digital Twin Systems-of-Systems," 2022 IEEE/ACM 10th International Workshop on Software Engineering for Systems-of-Systems and Software Ecosystems (SESoS), pp. 9-12. [21] Henkel, M., Stirna, J., Groissböck, M., Stadler, M. (2013). Supporting Energy Efficiency Decisions with IT: Initial Experiences from the EnRiMa Project. In: Kobyliński, A., Sobczak, A. (eds) Perspectives in Business Informatics Research. BIR 2013. LNBIP, vol 158. Springer, https://doi.org/10.1007/978-3-642-40823-6_25 [22] Grabis, J., Tsai, C.H., Zdravkovic, J., Stirna, J. (2022). Endurant Ecosystems: Model-Based Assessment of Resilience of Digital Business Ecosystems. In: Nazaruka, Ē., Sandkuhl, K., Seigerroth, U. (eds) Perspectives in Business Informatics Research. BIR 2022. LNBIP 462. Springer, https://doi.org/10.1007/978-3-031-16947-2_4