=Paper=
{{Paper
|id=Vol-3298/DTE-3
|storemode=property
|title=Integrating Organizational and Technological Aspects of Digital Twin Engineering
|pdfUrl=https://ceur-ws.org/Vol-3298/paper_DTE_2709.pdf
|volume=Vol-3298
|authors=Benjamin Nast,Achim Reiz,Kurt Sandkuhl,Janis Stirna
|dblpUrl=https://dblp.org/rec/conf/ifip8-1/NastRSS22
}}
==Integrating Organizational and Technological Aspects of Digital Twin Engineering==
https://ceur-ws.org/Vol-3298/paper_DTE_2709.pdf
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