Open AccessArticle

Agile Construction Digital Twin Engineering

Philipp Zech

^1,*

Alexandra Jäger

¹,

Larissa Schneiderbauer

²,

Hans Exenberger

Georg Fröch

² and

Matthias Flora

Department of Computer Science, University of Innsbruck, 6020 Innsbruck, Austria

Unit of Construction Management and Tunnelling (iBT), University of Innsbruck, 6020 Innsbruck, Austria

Author to whom correspondence should be addressed.

Buildings 2025, 15(3), 386; https://doi.org/10.3390/buildings15030386

Submission received: 2 December 2024 / Revised: 17 January 2025 / Accepted: 22 January 2025 / Published: 26 January 2025

(This article belongs to the Special Issue Advanced Research on Intelligent Building Construction and Management)

Download

Browse Figures

Figure 1
Manifestations of DTs [<a href="#B27-buildings-15-00386" class="html-bibr">27</a>]. "> Figure 2
Agile engineering. "> Figure 3
Process model for a typical change according to [<a href="#B36-buildings-15-00386" class="html-bibr">36</a>]. "> Figure 4
Three stages of the CDT. "> Figure 5
Generic change management process. "> Figure 6
Agile, change-driven process model for engineering DTs. "> Figure 7
Identification of quick wins for customers and stakeholders. "> Figure 8
Relationship between lead time and cycle time. "> Figure 9
Technology Acceptance Model with the four constructs training, perceived usefulness, perceived ease of use, and use [<a href="#B49-buildings-15-00386" class="html-bibr">49</a>]. "> Figure 10
Bootstrapped model. Values in ovals denote the R2 value of the construct; values in brackets indicate the 95% CI of the corresponding path. Asterisks indicate statistical significance at the 0.01 (***), 0.05 (**), and 0.1 (*) levels, respectively. "> Figure 11
Illustration of an information delivery process according to ISO 19650-1. "> Figure 12
Change management process aligned with information delivery process according to ISO 19650-1. ">

Versions Notes

Abstract

Digital twins have attracted a lot of attention recently. However, the current manifestations are merely digital shadows, lacking means for bidirectional data exchange, which makes their use for assisting the construction of buildings much more difficult. We argue that this is due to the lack of a systematic process for developing a digital twin during a building’s life cycle. We argue to look for a solution by combining agile engineering with IT change management to establish an agile, change-driven process for engineering digital twins. Such a process, of course, deserves a qualitative assessment of the engineering process and the resulting digital twin. In the future, it should be possible to obtain a digital twin from a BIM-based design process by applying IT change management in an agile manner. This should happen under maximum automation and life cycle orientation. Our proposal is motivated by several years of interdisciplinary collaboration between civil engineering and computer science and evaluated using the Technology Acceptance Model. While the TAM is not specifically designed for digital twin methodologies, its application here aims to assess perceived usefulness and ease of use of DT methodologies from the user’s perspective, without addressing scalability concerns. This aims to provide actionable insights to guide the refinement of the process model, aligning it with user requirements and achieving its intended outcomes. Our evaluation confirms the proposed process’s perceived usefulness and ease of use, with robust correlations indicating strong acceptance potential among stakeholders. These results highlight the feasibility of the proposed approach and its alignment with expectations in real-world applications.

Keywords:

agile engineering; IT change management; digital twin engineering; building information modeling

1. Introduction

Despite already having been conceived two decades ago, digital twins (DTs; see Section 2.3), e.g., virtual replicas of cyber–physical systems (CPS; see Section 2.2), only started attracting widespread interest in recent years [1]. Current manifestations of DTs in the architecture, engineering, construction, and operator (AECO) domain mostly fall into the category of digital shadows lacking bidirectional connections with a building for remote control (see Figure 1) and describe ad hoc solutions, such as the early but ongoing integration of Building Information Modeling (BIM; see Section 2.2) and the Internet-of-Things (IoT) [2,3]. They aim to implement a specific, stakeholder-motivated use case rather than provide a holistic, digital replica of a physical asset customizable to stakeholders’ use cases and available as early as the design phase of a building [1]. These ad hoc approaches exist on account of lacking a systematic process that allows for careful engineering of DTs, starting as early as the design phase. We argue, however, that the issue lies rather in the engineering aspects of such a process, as crafting a DT is mainly about information integration and filtering relevant information. As for DTs, these sources of information are as follows:

Static asset models that subsume the plethora of system and engineering models (e.g., project information models), as well as related models describing a CPS (e.g., asset information models).
Dynamic asset models comprise, among others, simulation models for behavior modeling and optimization, and machine learning models for informed decision-making.
Sensor, machine, and process data from the actual CPS and its environment.

Following this line of thought, we claim that the successful engineering of a DT capitalizes on an engineering process’s capacity to integrate information from diverse and heterogeneous sources. Therefore, pure forward (information) engineering fails in the long run because it is not designed to integrate feedback from the CPS, i.e., reflecting the CPS asset as is instead of as planned or designed, respectively. Beyond that, no CPS exists in the early phases. On the contrary, IT change management and agile engineering allow for the definition of a process scaffold for continuous, stakeholder-driven information integration, eventually yielding a DT.

IT change management (see Section 2.5) is a well-established IT service management discipline. The objective of change management is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes to control the IT infrastructure to minimize the number and impact of any related incidents upon service. Changes in the IT infrastructure may arise (i) reactively, in response to problems or externally imposed requirements, e.g., legislative changes, (ii) proactively, seeking improved efficiency and effectiveness, (iii) enabling or reflecting business initiatives, or (iv) from stakeholders. IT change management heavily relies on IT infrastructure modeling in combination with information integration from different physical sources in the physical IT infrastructure [4,5]. We thus conjecture that the application of IT change management for generating a DT is imperative to tackle the fundamental challenge of information integration.

Agile engineering (see Section 2.5) over the last two decades has emerged as an efficient process model in software engineering [6,7]. Specifically, agile engineering capitalizes on delivering a software system in small increments, thereby being completely driven by stakeholder and user requirements [6]. In addition, agile engineering employs rigid quality assurance to guarantee the deliverance of what is eventually expected by stakeholders and customers [6]. Considering the waterfall-like, rigid process structures that are currently employed in AECO [8,9], we argue that agile is a worthwhile alternative, as it allows for continuous reevaluation and revision of stakeholder and user requirements, thereby loosening AECO’s rigid process structures [10].

In this article, we propose a novel engineering process for DTs in AECO motivated by well-established practices and techniques, as employed in agile engineering and IT change management, embedded in conventional design, construction, and operating BIM processes. This readily yields a process for iteratively building a DT by continuously integrating data sources from the CPS and its environment to keep it in synchronization with the virtual replica. Crucially, doing so yields two immediate benefits, viz. the change-anticipative nature of agile engineering provides the necessary leeway to address the unexpected, whereas change management provides the necessary procedure to handle the unexpected. In the early development phases, e.g., design and planning, many data sources may not be available, yet these can be mocked and replaced upon integrating the actual physical data source. Doing so allows the application of IT change management during the initial development phases and consequently tracks every change distinctively. Eventually, the progress of the resulting process is driven by stakeholder requirements and accompanying use cases, therefore providing the necessary level of genericity to realize different stakeholders’ use cases. Intriguingly, the resulting process naturally aligns with BIM, as BIM, by design, has a change-driven nature [11]. Finally, we discuss how to achieve a qualitative assessment of our proposed process by proposing a set of agile-inspired metrics [12]. This result is seminal as, so far, the AECO domain lacks quality metrics for processes. Observe that Succar’s five BIM metrics are not applicable, as they are about assessing the performance of BIM and thus do not apply to the process level [13]. Our proposal is evaluated in an expert survey using a demonstrator and the Technology Acceptance Model (TAM) [14].

According to a recent study by Yilmaz et al., the construction industry is currently being substantially accelerated by the adoption of digital solutions [15]. Yet, many companies struggle to successfully conduct this digital transformation due to budget constraints and the complexity of the existing commercial, digital solutions [15]. Specifically, Yilmaz et al. mention unified change management as one of the top priorities in digitalizing the construction industry. Our proposal aims at delivering an approach to achieve unified change management by relying on existing, time-tested approaches.

Our contribution is structured as Design Science Research (DSR) [16] and delivers an artifact, e.g., our proposed process, to facilitate building DTs in AECO. Development of our artifact is initiated with the phase of requirements elicitation (see Section 4.1) and concludes with a single-case mechanism experiment (see Section 6.1). Our artifact is deployed as a treatment to the following design problem, expressed using the DSR template [17]:

Improve digital twin construction in AECO (context)
by developing an agile, change-driven process (artifact)
to deliver a context- and situation-aware method (requirements)
that delivers the construction digital twin (goal).

The remainder of our contribution is structured as follows. Section 2 introduces definitions of used relevant concepts, e.g., of CPSs, BIM, DTs, agile engineering, and IT change management. Following that, Section 3 presents the problem context on which our work is built. Next, Section 4 presents the main contribution of our article by proposing our novel, agile, change-driven process for the simplification of the processes for establishing a DT for engineers and architects. Section 5 then investigates the natural congruence of our proposed process with BIM. Section 6 evaluates our proposal using the TAM, positions our work with respect to related work, and discusses any threats to validity. We conclude in Section 7 with the current limitations of our work and an outlook.

2. Background and Definitions

Before discussing our manuscript’s main ideas and contributions, relevant concepts must be defined. This section thus introduces definitions of CPSs, BIM, DTs, agile engineering, and IT change management to foster any subsequent discussions.

2.1. Cyber–Physical Systems

Cyber–physical systems (CPS) are a new breed of systems that integrate physical and computational capabilities and allow for a wide range of novel human–computer interactions [18]. The IoT, cloud computing, big data, and machine learning were some of the technological advancements that came together to form the concept of a CPS. These technologies are used by CPSs to build intelligent systems that can sense, process, and react to current events in real time [18]. CPSs are becoming more significant today as part of the ongoing digitalization of the manufacturing and construction industries, from smart homes and buildings to industrial automation and autonomous vehicles. They have the power to change how we work and live by enabling more effective, resilient, and sustainable systems [19]. As part of their interdisciplinary nature, CPSs pose unique challenges in terms of design, implementation, and operation, cf., modern, smart buildings [20]. These challenges include the need for real-time processing, reliability, and security. A CPS must be able to operate in dynamic environments and handle unexpected events without compromising safety or performance [21]. Successfully engineering a CPS thus requires specialized expertise in multiple domains, such as mechanical or construction engineering, electrical engineering, computer science, or control engineering.

2.2. Building Information Modeling

Building Information Modeling is a term that represents the digital transformation in the AECO sector and has gathered several definitions and interpretations in recent years [22,23,24]. In the internationally recognized standard ISO 19650-1 [25], Building Information Modeling is defined as the “use of a shared digital representation of a built asset to facilitate design, construction and operation processes to form a reliable basis for decisions”. In other words, BIM refers to a fully integrated, collaborative process of modelling a digital building model. An important aspect regarding the definition of BIM is that it is not only about the purely geometric modeling of an asset, but that semantic information, such as material properties, specific characteristics for rooms and spaces, or information concerning cost and time, is of major importance for the description of a digital building model and thus constitutes Building Information Modeling.

Especially in the design phase, there are considerable differences to conventional processes. The integral and transparent collaboration of the disciplines is based on the generation of specialist models, which are referenced to each other so that a virtual replica of the asset is created even before the execution phase begins. The early detailing of building models enables the prevention of cost and schedule delays due to inadequate design quality.

In the field of building engineering or infrastructure engineering, this method offers the possibility of optimizing the life cycle performance of buildings in the early phases by means of various types of models and analyses.

2.3. Digital Twins

DTs, that is, virtual replicas of a CPS, e.g., an embedded system, a smart building, or a digital shopfloor, according to Grieves and Vickers [26] generally comprise three fundamental building blocks, viz. the following:

The virtual instance, i.e., the assemblage of system, test, product, and simulation models, which together replicate the physical asset;
The product instance, i.e., the built CPS;
Interchanged data and connections, i.e., the digital thread, allowing for bidirectional communication between the virtual and product instance.

The assemblage of models to establish the virtual instance thereby epitomizes the central source of complexity in engineering a DT. Not only are these models heterogeneous in describing different aspects and stakeholder views, but more importantly, these models need to evolve alongside the physical asset to reflect it as is. As such, DTs typically manifest in three variants [27], as shown in Figure 1:

Digital model: information exchange between the virtual and product instance is purely manual.
Digital shadow: information exchange between the product and the virtual instance is automated.
Digital twin: both directions of information exchange are automated.

Figure 1. Manifestations of DTs [27].

Despite their concept having already been around for multiple decades [26], recent advances in the IoT, data analytics, and machine learning have ultimately made it possible to create more accurate and sophisticated models for being used in DTs. Regarding their resulting use to monitor, analyze, and optimize the performance of physical assets, predict failures, and simulate scenarios in a risk-free environment, DTs have the potential to revolutionize the way companies design, build, and operate physical assets and systems [28,29]. DTs are currently used across a wide range of industries, including manufacturing, energy, aerospace, healthcare, and more [30].

To illustrate this definition with an example from the construction sector, a digital model, as the first variant, might describe a building’s HVAC system using only static data, such as its design specifications. A digital shadow could then build on this by displaying real-time sensor data, such as current temperatures and energy consumption, i.e., for monitoring purposes. In contrast, a digital twin would take this a step further by analyzing the real-time data alongside additional factors like weather forecasts, occupancy schedules, or energy demand. By integrating these inputs, the digital twin could automatically adjust HVAC settings to optimize energy efficiency, reduce costs, and maintain occupant comfort.

Boje et al. [31] extended the concept of DTs to the notion of a construction digital twin (CDT), which our work also addresses. The CDT is a virtual replica of a physical construction project that uses real-time data from sensors, construction management software, and other sources to simulate the behavior and performance of the project throughout its life cycle. Unlike manufacturing DTs, the CDT must account for the larger scale and intrinsically different dynamics of construction projects [31].

2.4. Agile Engineering

Since the early 2000s, the software engineering community has seen a tremendous change towards agile engineering to overcome issues often associated with plan-based development models by emphasizing continuous adaptation and customer collaboration [32,33]. In its essence, agile engineering postulates the introduction of short cycles, where each cycle focuses on a dedicated objective. After each cycle, the current state/progress of a project is evaluated, replanned if necessary, and execution continues with the next objective in line. At its core, agile describes a lightweight two-staged process that is repeated until all work is completed (see Figure 2). The first phase, i.e., requirements engineering, focuses on establishing the necessary requirements for the objective in the cycle. The second phase addresses the design and implementation of the objective, marking the end of the cycle. The SCRUM methodology [34] is one of the most established agile software engineering approaches. Agile engineering naturally anticipates change and goes hand in hand with metrics for assessing project progress and product quality after every cycle [12]. As for its benefits in faster time-to-market, higher quality software, and increased customer satisfaction, agile engineering has gained widespread acceptance nowadays, and has been systematically evaluated in several studies [35]. To fully deploy its benefits, agile engineering, however, demands constant communication and collaboration among all involved project stakeholders.

2.5. IT Change Management

IT change management describes a systematic procedure to manage changes to the IT infrastructures of an organization [36]. The systematic and structured management of such changes greatly reduces risk exposure as well as the severity of the impact and, consequently, operational disruptions. Most importantly, however, IT change management aims at facilitating the prolific implementation of a change at the first attempt. To successfully conduct such changes, change management heavily relies on well-defined process models, which define the necessary steps from recording the change to its evaluation, authorization, prioritization, planning, testing, implementation, documentation, and review [36]. The Information Technology Infrastructure Library (ITIL) defines an organizational framework and thus completely neglects the underlying technical infrastructure for implementing the framework. Nevertheless, a database-backed system for tracking changes in a dedicated format is beneficial.

Such process models may subsequently be implemented in change management tools. However, while software support may greatly ease the management of changes, at its heart, change management remains a process and is independent from any software solution. No specific input format, output format, or storage requirements need to be observed.

According to [36], a process for a typical change follows the model shown in Figure 3. Roughly speaking, to initialize a change, a request for change (RFC) containing relevant information regarding, e.g., initiator, trigger, and description is created and subsequently reviewed for feasibility. Such an RFC usually is motivated by either a necessary change or the addition of a feature, which eventually also boils down to a change that must be applied. If not rejected, the proposed change is assessed and evaluated, i.e., relevant resources are identified, and the impact of the change is elicited. After authorizing the change, given the RFC’s evaluation and assessment, the change is implemented and finally reviewed. That is, stakeholder satisfaction and resource consumption are evaluated regarding the achievement of the change’s objective. In synopsis, change management defines a framework, based on best practices, that aims at (i) minimizing risk and costs, (ii) optimizing efficiency and consistency, (iii) enhancing communication, (iv) alignment with operational strategies, and (v) reducing costs.

3. Problem Context

Typically, CDT requirements are defined based on dedicated use cases that emerge throughout the life cycle of a construction project. In addition, great care must be taken in defining the CDT’s general functional requirements due to the extremely high friction of projects in the AECO industry. Even within a single project, the definition must account for the varying expectations of project stakeholders, technologies, and periods throughout the entire project life cycle. The CDT requirements must be consistently adapted as a project progresses, drawing parallels to agile processes [32].

In the following, we discuss two interdisciplinary research projects, viz. BIM2BEM-Flow and TIM, which establish the problem context of our work. Specifically, these projects target the establishment of DTs in the construction domain for the purpose of energy efficiency planning (BIM2BEM-Flow) and large-scale underground infrastructure management (TIM) using DTs.

Both BIM2BEM-Flow and TIM serve as foundational examples of how the unique challenges and opportunities in the construction domain can inform the development of a systematic and adaptive approach to CDT engineering. BIM2BEM-Flow highlights the critical role of data integration and life cycle orientation in supporting continuous energy efficiency improvements, a central objective that aligns closely with our proposed agile and change-driven methodology for CDT development. Similarly, TIM provides insights into the structured yet fragmented nature of large-scale infrastructure projects, where long implementation periods and complex stakeholder ecosystems demand a robust yet flexible process for CDT development. These projects not only highlight specific use cases but also demonstrate the broader challenges of aligning CDT development with life cycle dynamics, stakeholder needs, and technological evolution. By addressing these challenges, our research aims to provide a generalized, adaptable framework for engineering CDTs that builds upon the lessons learned from these interdisciplinary initiatives.

3.1. Use Cases in BIM2BEM-Flow

BIM2BEM-Flow is an interdisciplinary framework developed to bring BIM data into building energy modeling (BEM) environments, enabling continuous energy efficiency planning across all stages of a building’s life cycle. BIM2BEM-Flow moves beyond BIM’s traditional focus on design and coordination, embedding energy efficiency and sustainability as central goals in both the design and operational phases of a building. The framework is specifically tailored for complex workflows that require seamless data exchange between digital building models (BIM) and building physics tools for energy simulation, making it possible to incorporate energy insights dynamically as the project progresses.

The BIM2BEM-Flow framework supports a wide range of use cases, such as energy flow simulation, which allows project teams to evaluate energy demands and usage patterns in detail. It incorporates both natural and artificial lighting simulations, supporting informed lighting decisions to optimize both energy efficiency and occupant comfort. The system also enables robust building operation and maintenance workflows, leveraging data-rich BIM models to provide maintenance insights, extend asset life, and ensure energy systems perform as designed throughout a building’s operational phase. BIM2BEM-Flow thus plays a critical role in integrating real-time performance data with energy models, bridging BIM’s design-focused phase with ongoing energy performance monitoring.

In addition to monitoring, BIM2BEM-Flow supports continuous system optimization. By enabling real-time data integration for systems such as HVAC and lighting, it allows stakeholders to track energy usage, making adjustments as needed to meet or exceed predefined energy benchmarks. Additionally, the framework’s data-driven approach supports proactive energy management, using data from various systems to identify optimization opportunities and ensure energy consumption remains aligned with project goals.

BIM2BEM-Flow is built to support interoperability through industry standards such as IFC and uses advanced meta-modeling techniques to automate data transformation processes, ensuring seamless collaboration between BIM and BEM tools. This interoperability empowers stakeholders across architecture, engineering, and facilities management to maintain energy efficiency without needing specialized knowledge of each tool’s data formats. By defining data transformations and rules at the parameter level, BIM2BEM-Flow provides an adaptable framework for continuous energy performance improvement, ultimately supporting industry needs for sustainable, data-driven building operations.

3.2. Use Cases in Tunnel Information Modeling

Tunnel Information Modeling (TIM) is the specialized implementation of BIM in the tunneling industry and currently being driven forward intensively by industry and research. During this initial phase of BIM implementation, the focus of the industry strongly lies upon the design and construction phase, partly due to the long project implementation periods for big infrastructure projects like tunnels. As an example, Austrian infrastructure developers decided to establish general use cases for BIM in tunneling and came up with a list of 18 general BIM use cases [37]. These range from design or coordination, all the way to construction phase simulation or model-based billing. The operational phase is not yet included in these considerations, and therefore the last use case is the creation of an as-built model.

From the authors’ experience from participating in various research and pilot projects for TIM, it can be said that the tunneling industry in general is predestined to work with BIM and a CDT. The very structured approach due to the usually huge project scope can very easily be aligned with the general approaches for BIM. The main limiting factors are the rather negative attitude towards digitalization of current management personnel, which can only be overcome by a generational change. Another limiting factor is the desire to work with fully developed structures, mature templates, and defined normative guidelines from the outset, as there can be no such practical developments without concrete project work.

As established earlier, BIM is only the preliminary stage for or a part of the digital twin. Many of the defined BIM use cases can be transferred to CDT use cases. Due to the high potential of CDT usage in the operational phase of a tunnel, these need to be added in the future. Siemens, for example, has created its own very specific DT for tunnels and defines, among other things, virtual initiation or the protection from threats as reasonable use cases [38].

3.3. Consolidated Use Cases

The discussions in Section 3.1 and Section 3.2 outline the diverse use cases for which the CDT will ultimately be employed during its and the twin building’s life cycle. Clearly, this is not an exhaustive list, and, depending on the nature of a construction project, new use cases may emerge over time. In our discussion, however, the two projects discussed in the preceding sections provide the empirical basis from which we derive our use cases and, consequently, the CDT’s necessary requirements, as discussed in the following section. Table 1 is a summary of the aforementioned use cases.

4. Agile Construction Digital Twin Engineering

Engineering a CDT is a complex endeavor that encompasses the entire building life cycle. Eventually, however, prior to constructing it, it is necessary to infer the necessary requirements. In this work, we will not focus on the technical requirements of the CDT per se, but instead on the requirements for the underlying process as proposed in this work. We will therefore infer the necessary process requirements for our proposal below.

4.1. Requirements for the Construction Digital Twin

The CDT within the life cycle of a project can be divided into three distinct phases. The first phase is the phase of concept and design, during which no CPS exists. In this phase, the CDT is constructed, which aids the entire design process and serves as the foundation for the next phase. This is the construction phase, during which the CDT is utilized for supervising construction and must be adapted to all deviations resulting from differences between the planned and actual construction. The result is a constructed CDT that is identical to the CPS. After construction, the third phase consists of asset monitoring and operation. Few modifications will be made to the CDT’s geometrical appearance and static properties, but its dynamic properties will be heavily utilized. In its concluding phase, the CDT serves two primary functions. First, the asset’s dynamic properties enable its control via sensors and maintenance procedures. Second, the geometry and static properties serve as data storage for a variety of purposes, such as the history of each constructed element or as the premise for future adaptations.

Unlike a digital model (see Figure 1), which is already utilized in many projects employing the BIM method during the design phase, where it serves as the premise for the construction site, one of the essential requirements for a CDT is the incorporation of real-time data. During the design phase, this can include drafts and early simulations of the building. During the construction and operation phases, real-time data in the form of sensor and machine data become increasingly prevalent [14]. The bidirectional communication between the CDT and CPS unlocks new opportunities for enhancing processes or user convenience. An example would be a separate control for the HVAC system. Through the logical connection of intelligent systems and devices (such as sensors) to the CDT, energy flows are automatically monitored, analyzed, and regulated to achieve a perfectly balanced indoor climate.

With the integration of real-time data into the CDT, an enormous quantity of data are generated, which must be saved and systematically associated with CDT components. Filtering information is useful for comprehending and interpreting the data history in a meaningful manner. The use case, stakeholder, or project phase could be utilized to filter information. Currently, models are frequently reduced to the essential information at the start of a new phase, rather than retaining all information and filtering out the irrelevant information. In other words, the CDT should respond based on who is observing it, when they are observing it, and why they are observing it. Figure 4 summarizes the above discussion by visualizing the three phases of the CDT, which are subsequently defined more concisely.

4.1.1. CDT—Built as to Be Built—The Design Phase

As described earlier, no CPS exists in this phase, which makes it particularly interesting to define requirements for the CDT in the subsequent phases. The CDT in this phase must result from a collaborative work process akin to BIM and comprises all the sub-models from each design discipline as well as any mocked data. It is essential that each stakeholder, design office, and discipline has access to information on every sub-part of the CDT but can only edit and change the parts of the CDT in their responsibility. For all planning processes, the CDT is considered the single source of truth. The resulting requirements for the CDT in this phase are diverse. For example, the CDT must be able to handle the process of variant analysis. It should allow for quick and easy adjustments to find the best solution regarding the project’s boundary conditions. These might dictate the best technical solution but can also regulate the costs or schedule for the project. In direct relation to this, the DT must be able to handle all kinds of design simulations. These might be a structural analysis, optimizations of energy efficiency, or construction process and progress simulations [31,39]. To sum up, in this phase, the DT is mostly required to, first of all, create itself, then optimize itself, and finally act as the basis for the certification of the to-be-built asset. The CDT in this phase delivers use cases UC2, UC4, and UC10 (cf. Table 1).

4.1.2. CDT—Built While Built—The Construction Phase

The CDT performs an important role during the construction of the CPS. Since it already exists as intended, the CDT serves as the foundation for all construction planning. In this phase, the CDT must include not only temporary facilities, such as site equipment, but also structures required to construct the CPS, such as road diversions. During construction, the CDT must be modified to accommodate changes necessitated by deviations from the intended CPS. These modifications may be the consequence of impromptu decisions or an imprecise construction process. Therefore, the three most pertinent reasons are as follows. First, the DT must closely resemble the genuine CPS to meet all client requirements. Second, the CDT is a crucial instrument for bidding. Based on the CDT, the client will create the tendering documents and monitor all processes on it. Billing is the third and most essential reason. Using the CDT, the contractor typically invoices the client for actual costs, necessitating an exact replica of the CPS by the CDT. At the conclusion of the construction phase, the CDT must achieve two goals. The primary goal is to represent a knowledge base for all construction data. This could include knowing when a component was constructed, what materials were used, who constructed it, and even the weather at the time, to name a few examples. After construction is complete, the CDT must be transferred to facility management (FM) for computer-aided FM (CAFM). When a redevelopment or extension of the CPS is planned, or when a detrimental event occurs, design and construction information typically become relevant once again. The CDT in this phase delivers use cases UC3, UC8, and UC9 (cf. Table 1).

4.1.3. CDT—Built as Built—The Operation Phase

As indicated previously, the CDT for this phase should ideally be the result of the previous phase. During the phase of operation, the CDT is subject to a new set of requirements. One of the primary goals is to control the CPS using direct input signals and to collect data using sensors. From controlling the HVAC of a building to virtually stress-testing the CPS or controlling the railway signaling and movement of trains, this strategy could lead to useful outcomes. The second primary objective is facilities management and infrastructure upkeep, respectively. The CDT must permit the incorporation of CPS maintenance and repair procedures. Consequently, during the operation phase, the DT must react less to the geometric changes of the CPS and instead integrate all the data arriving directly from it. The CDT in this phase delivers use cases UC1, UC3, UC5, UC6, and UC7 (cf. Table 1).

4.2. Proposed Process

In Section 1, we argued that developing a DT is predominantly a matter of integrating information, as opposed to designing a (large-scale) system from scratch. This claim is firmly supported by the fact that a DT is typically co-designed with a CPS (such as an embedded system, a smart building, or a digital shopfloor). These CPSs are constructed according to well-established procedures [40,41]. These processes have a strong emphasis on engineering and are therefore not equipped to supervise the development of DTs. Pure forward engineering processes comprising engineering change management are intended to handle changes only after the release of a product, i.e., a completed structure (or portions thereof). Additionally, engineering change management is not optimized for information integration. A DT is typically constructed from existing information on and about the CPS (such as static information from models and dynamic information in the form of data available from and about the cyber–physical asset). This information must be integrated, correlated, and made available to stakeholders in accordance with their needs and use cases, thereby proving our primary point that generating a DT is about information integration. Alongside AECO’s well-established engineering processes, IT change management provides a systematic approach to achieving this goal.

DTs are constructed based on the requirements of stakeholders and use cases. Consequently, a process that is agile and iterative (see Section 2) and is driven by stakeholder requirements and the use cases listed in Table 1 is a natural fit. Agile methods leverage the concept of delivering software systems in small increments that are driven by stakeholder needs and accompanied by rigorous quality assurance. Specifically, the agile manifesto proposes the four principles listed below [6]:

Individuals and interactions over processes and tools (i.e., people drive the development process and not tools, so people take precedence).
Working software over comprehensive documentation (i.e., shift the focus on the process outcomes and not the process itself).
Customer collaboration over contract negotiation (i.e., customers are important not only for early requirement elicitation and final commissioning but throughout the whole development process).
Responding to change over following a plan (i.e., deliver minimum viable increments that can immediately be evaluated and changed from iteration to iteration).

The agile manifesto promotes a shift away from rigid processes and planning toward a pervasive emphasis on the consumer and the to-be-created IT system. To facilitate close coordination based on tangible artifacts, early and continuous delivery of results to the client is one of the highest priorities. Changes to customer requirements are not rejected but rather viewed as a necessary course of action to produce a customer-value-generating project outcome. This is frequently referred to as movable targets [42]. In agile projects, the development of high-quality software is a top priority to make frequent technological changes conceivable. This includes a straightforward IT architecture and ongoing code quality assurance. In agile teams, social aspects such as effective communication, motivation, and personal accountability are also highly valued.

As described in Section 2, a CDT is subject to changing requirements. Agile engineering’s change-anticipatory and iterative nature enables change response by default. However, agile methods were originally developed for software engineering and therefore do not fit CDT engineering seamlessly. In particular, the design and implementation tasks do not readily apply to the construction of a CDT, as no new artifacts are to be produced; rather, new information is to be integrated. In the case of the CDT, this will depend on the three phases, namely, in the first phase, information regarding building requirements will be integrated, in the second phase, information regarding the as-is manifestation of the CPS will be integrated, and in the third and final phase, information regarding the actual state of the CPS will be integrated (see Figure 3).

IT change management can be implemented as early as the design and planning phases to evaluate potential IT infrastructure manifestations. Eventually, a CDT becomes an IT infrastructure due to its combined need for hardware- and software-based components, resulting from its virtual replication of a CPS. This follows directly from Grieves and Vickers’ earlier definition [26], in that a DT requires a digital representation, which is ultimately software-based, a physical counterpart, i.e., the hardware, and a middleware, i.e., software for exchanging data. Figure 5 depicts a generic change management process that makes it possible to realize a CDT in accordance with the requirements of its stakeholders in a step-by-step manner.

Figure 5 represents a simplified view of the detailed process depicted in Figure 3 by condensing multiple steps into one, such as Create RFC, Record RFC, and Review RFC condensing into Describe the situation as is. By embedding Figure 5’s generic change management process within Figure 2’s agile paradigm, the resulting combination of agile engineering and change management enables the development of Figure 6’s extended, iterative agile process model for engineering DTs.

By beginning with stakeholder-motivated requirements engineering, the process depicted in Figure 6 is stakeholder-driven and ensures that stakeholders’ requirements and use cases are satisfied upon completion of an iteration. In addition, by treating the CDT as an IT infrastructure, the requirements of stakeholders are translated into change requests that are systematically incorporated into the existing CDT in accordance with well-established procedures. Lastly, the agile nature of the process enables continuous alignment with stakeholder requirements and the delivery of these requirements with high quality. This procedure is easily applicable to all three phases of the CDT (see Figure 3). In addition to the benefits derived from the application of an agile methodology to the development of the CDT, change management offers the following advantages:

Improved communication: by involving and informing team members and stakeholders about changes, communication throughout the entire project is enhanced.
Reduced organizational friction and improved productivity: naturally, communication throughout the entire project is enhanced when team members and stakeholders are informed and included in the change process.
Enhanced creativity and innovation: every change necessitates alternative/novel solutions, thereby fostering innovation and creativity among team members and stakeholders when exploring new problem-solving techniques.
Improved decision-making: every change necessitates alternative/novel solutions, thereby fostering innovation and creativity among team members and stakeholders when exploring new problem-solving strategies.

4.3. Benefits of Proposal

The process proposed in Section 4 is based on well-established agile software engineering techniques [43,44]. Agile engineering’s revisionist nature enables the identification of quick wins for stakeholders (see Section 4.3.1). In addition, process and product quality metrics of agile engineering merit additional research into their applicability and impact on CDT engineering, as discussed in Section 4.3.2.

4.3.1. Quick Wins for Stakeholders

As regards utilizing agile methods, quick wins, i.e., use cases with high strategic relevance and simple feasibility, can be easily identified to rapidly deliver value to customers/stakeholders (see Figure 7). Agile engineering’s repeated requirements engineering during each iteration facilitates the identification of quick wins. Continuous and repeated consultation and evaluation of use case-related scenarios in each iteration yields a step-by-step strategy for constructing the CDT by realizing concrete, stakeholder-motivated scenarios that are progressively evaluated and quality-assured (see Section 4.3.2). Thus, the proper identification of quick wins permits the development of a minimum viable product (MVP) from the customer/stakeholder’s perspective and enables the rapid delivery of a return on investment (ROI). As construction progresses on the CDT, all use cases are eventually addressed. Importantly, as the CDT’s base grows, the use cases on the right side of Figure 7 become progressively simpler to implement.

4.3.2. Quality Metrics

The availability of metrics that provide insight into productivity throughout the various phases of a project’s life cycle is an advantage of using an agile process. This helps to evaluate product quality and track team performance [12]. We cannot map all agile metrics to the AECO context due to the software development-related nature of agile metrics. In addition, not all selected metrics can be applied to every BIM use case, as should be evident from the context of the various use cases. Nonetheless, numerous metrics can be readily applied to the AECO context and contribute significantly to key quality criteria in the AECO domain [45]:

Plannable processes;
Transparent processes;
Effective processes and groups;
Situationally and contextually aware procedures;
Resource-conscious procedures.

In the following, we illustrate how such metrics can be used not only for evaluating the CDT’s quality (see Section “Measuring the Quality of the CDT”) but also for team building (see Section “Measuring the Team Building the CDT”). All metrics that are part of the ensuing discussion are time-tested and have their roots in agile engineering [12].

Measuring the Quality of the CDT

Several agile engineering metrics are readily applicable to measuring the quality of the CDT. We contend that the following metrics can be mapped directly without additional effort or modification:

Mean time to repair (MTTR) is used to track the time between detecting an issue in a product, triaging the issue, and determining and deploying a fix. In the context of the CDT, this refers to a missing or incorrectly configured information source. Importantly, MTTR typically induces a new change, resulting in additional lead and cycle time expenditures (see below).
Lead time measures the time between the customer’s first mention of a new feature and its eventual delivery to the end user. In the context of the CDT, this refers to the amount of time required for a change (the feature) to be deemed relevant and implemented. Importantly, lead time is a measure of long-term performance.
Cycle time, unlike lead time, is a short-term measurement and a subset of lead time (see Figure 8). Importantly, it is the actual completion time a feature requires, i.e., from the time it is moved from defined to started/in-progress to complete. Cycle times are a direct measurement of the time required to complete a specific task, such as integrating a specific data source as part of implementing a change.
Mean time between failure (MTBF) is used to monitor a product’s availability and dependability. The greater the time between failures, such as a non-functioning twin (i.e., rather than displaying incorrect sensor values, it displays none), the more reliable the system.
Recidivism is the measurement of tasks in reverse order. The recidivism rate increases if a task moves from planning to implementation, fails to meet the requirements, and then moves back to planning.

Collectively, these metrics allow for the evaluation of the quality of both the process application and the final product. Despite the fact that this set of metrics is incomplete, it provides a fundamental foundation for assessing and measuring process and product quality in AECO.

Measuring the Team Building the CDT

In addition to measuring the quality of the process and the final product, agile methods place an even greater emphasis on measuring the development team. As is the case with technical quality metrics, agile methods also include a variety of team measurement metrics. As with technical quality metrics, however, not all team-related agile metrics are applicable to our proposed process. Again, we argue that the following metrics can be mapped without additional effort or adjustments:

Lead time is not only a technical quality metric, but is also useful for measuring a team’s efficiency by estimating the speed of the value chain, i.e., from change definition to delivery.
Development time measures the completion time of a specific task after it has been specified and passed on to development. In the case of the CDT, this corresponds directly to change implementation, providing a valuable measure of the complexity of a task.
Deploy frequency measures the frequency with which consumers/stakeholders receive updates.
Good/failed deliveries assess the frequency with which customers/stakeholders receive a working product, i.e., a CDT that satisfies specified requirements.
Total done determines the frequency with which a working product, i.e., a CDT that meets specified requirements, is delivered to customers/stakeholders.

As for team-based quality metrics, the above list is by no means exhaustive; rather, it is intended to demonstrate that agile methods can be used to evaluate not only process and product quality, but also a team’s productivity and dedication. We claim that such measurement capacities are novel for the AECO domain and thus provide a valuable first step towards optimizing the construction of the CDT, and—if carried out thoroughly—also its accompanying CPS, i.e., the built asset. For such metrics to be effective and meet the aforesaid quality criteria, they must be utilized by the entire team, not just by a single individual. Additionally, metrics must be used in conjunction with other metrics, as each metric addresses only a particular aspect. Using them in tandem reveals the bigger and balanced picture of all project activities. Finally, metrics should be easily understandable and computable to provide meaningful insight and help in guiding day-to-day activities.

Table 2 summarizes these agile metrics, supported by descriptive examples from the AECO industry for each phase of the CDT that can readily be applied to our process in the AECO domain, as discussed next in Sections “Measuring the Quality of the CDT” and “Measuring the Team Building the CDT”.

5. Alignment with BIM

Change management and agile engineering with BIM are congruent at this stage. In particular, the management aspect of BIM, which, among other things, defines the information requirements and how the information is delivered, is very similar to the change management and agile engineering methods described [25,46]. In all phases of an AECO project’s life cycle, changes as such are the basis for all work, regardless of whether a classical or BIM approach is employed, because they are unavoidable. However, the BIM approach adds a significant collaborative element to the change-based working method. The combination of the two contributes to the proposed process model for agile, change-driven engineering of DTs (Figure 6). By stating that the CDT is the natural consequence of the proper implementation of BIM in construction projects [1,31], we complete the circle with the described congruence. In contrast, a properly constructed and utilized BIM can already represent a CDT, particularly during the design phase.

This congruence is prominently reflected in the BIM tools currently in use. Issue management tools, such as BIMCollab or Solibri, have made their way into standard BIM projects and assist in tracking all identified issues, which are merely another type of change. Similar to source code repositories in agile engineering [47], the use of common data environments (CDEs) strongly contributes to an agile work style. By establishing a single source of truth and near-real-time access to the most up-to-date models and project data in general, information-dependent parties can establish a collaborative and tightly integrated workflow. The resulting processes are consistent with agile engineering methodologies.

The necessity of the described process is most evident in the built-as-built CDT, which is one of the three phases of the CDT introduced in Section 3. An operating model for the CPS is required for this phase. This requirement exemplifies CAFM in that the proper operation and maintenance of a CPS, i.e., the built asset, cannot be carried out in the absence of a well-defined operating model. By incrementally and iteratively constructing the CDT in accordance with stakeholders, such as CAFM operators or residents, our requirements engineering process ultimately produces the required operating model. By taking into account all pertinent requirements pertaining to the operating model of a CPS and subsequently delivering the system by implementing the pertinent changes, the CDT directly reflects the operating model as required by respective stakeholders.

6. Evaluation and Discussion

The design, construction, and operation of a building or structure is an interaction of many processes, which together lead to a functioning building. To evaluate the hypotheses and the change management process outlined in Figure 6, a representative and common process within a BIM design process is taken into consideration.

6.1. Explaining Technology Use and Acceptance Using the TAM

The Technology Acceptance Model (TAM) is a commonly used theoretical framework for analyzing and predicting the acceptance and usage of information technology [14]. Originally proposed in the late 1980s, it has subsequently been worked upon by numerous scholars [48]. The TAM is useful for analyzing technology use and provides a structured approach to assessing user perception and decision-making for technology adoption. In our work, we employ a slightly modified version of the TAM proposed by Riemenschneider and Hardgrave [49], as shown in Figure 9. It includes the following components:

Training (TRA) is a valuable exogenous variable in determining the use of novel technologies and directly influences both perceived usefulness and perceived ease of use.
Perceived ease of use (EOU) assesses the extent to which users believe that using the technology or tool will be effortless and free from difficulties.
Perceived usefulness (USF) focuses on whether users believe that the technology or tool will enhance their job performance or make their tasks more effective.
Use (USE) represents the actual adoption and use of a technology or tool and is influenced by perceived ease of use and usefulness, respectively.

The TAM thus provides a systematic framework for evaluating user perceptions, attitudes, and intentions around technology adoption, making it essential for technology evaluation. This understanding can lead to changes, influence decision-making, and increase the possibility of successful technology deployment and use within an organization or user group [14,48].

6.2. Method

We created a user survey to be administered to our sample. The sample in this case comprises selected representatives from the construction domain with both academic and industrial backgrounds. After an online video demo of our proposed process model, we administered our survey to the 22 representatives, among them, BIM managers, software developers, project leads, and engineers. The average age of respondents is 38 years, with a reported average of 10 years of experience. Among the participants, there were 15 males and 7 females. The survey comprised the following question items:

USE₁: Conceivable degree of utilization of the process;
TRA₁: I understood the process from the instructions in the video;
TRA₂: I already implement agile processes and already received special training;
TRA₃: I will need appropriate training for the implementation of agile processes;
USF₁: Using the process shown enables me to complete tasks more quickly;
USF₂: Using the underlying process improves my work performance;
USF₃: Using the underlying process increases my productivity;
USF₄: Using the underlying process improves the quality of my work;
USF₅: Using the underlying process makes my work easier;
USF₆: The underlying process is useful for my work;
USF₇: The underlying process is useful to me;
USF₈: The advantages of using the underlying process outweigh the disadvantages;
EOU₁: Learning the new process seems easy to me;
EOU₂: I think the new process is clear and understandable;
EOU₃: I find the new process flexible to use;
EOU₄: It seems easy for me to use the new process skillfully;
EOU₅: The new process is easy to use;
EOU₆: The new process is not frustrating to use;
EOU₇: Using the new process does not require much mental effort.

The Likert scale used for all question items (except for USE₁) consisted of seven points, with a rating of 1 representing “strongly disagree”, a rating of 4 representing “neither agree nor disagree”, and a rating of 7 representing “strongly agree”. In case of USE₁, the scale consisted of four points, ranging from 1 representing “all the time” to 4 representing “rarely”. Furthermore, demographic data, including age, gender, job role, and years of professional experience, were collected to describe the participants.

6.3. Model Evaluation

To thoroughly assess our suggested process model, we investigate the corresponding structural equation model [50]. Structural equation modeling (SEM) is a powerful tool for analyzing complex relationships, especially among latent variables. Two main approaches exist in SEM: covariance-based SEM (CB-SEM) and partial least squares SEM (PLS-SEM) [51]. PLS-SEM is beneficial in situations where the goal of the model is to predict and explain desired outcomes, such as technological acceptance [52]. The statistical programming language R version 4.2 was used together with the SEMinR package version 2.3 to analyze our instance of the TAM using the PLS-SEM technique [51,53].

6.3.1. Measurement Model Evaluation

Beginning with the dependability and accuracy evaluation of our reflective measurement, as per the approach outlined by Hair Jr. et al. [51], we investigate the reliability of each construct by (i) analyzing indicator loadings, (ii) evaluating the reliability of the measurement instrument by calculating composite reliability (ρ_c), Cronbach’s alpha (ρ_T), and the reliability coefficient (ρ_A), (iii) assessing the convergent validity by calculating the average variance extracted (AVE), and (iv) verifying the discriminant validity by examining the Heterotrait–Monotrait (HTMT) ratios [51].

As to (i), all the loadings of the four constructs TRA, EOU, USF, and USE exhibit statistical significance at a confidence level of CI_α = 0.05 or below. Furthermore, being above the threshold value of 0.708 [50], they suggest a sufficient level of indicator reliability [51]. Concerning (ii), all four constructs measured demonstrate internal consistency [50], with ρ_c, ρ_T, and ρ_A all surpassing 0.8 [50]. Moreover, with regard to (iii), it is important to mention that all the Average Variance Extracted (AVE) values are close to the threshold of 0.5 [54], indicating a substantial level of convergent validity for the measures of the four constructs [50]. Concerning (iv), all HTMT ratio values are below the cut-off threshold of 0.75 [54], indicating discriminant validity among the four constructs.

6.3.2. Structural Model Evaluation

After assessing both the reliability and validity of the four constructs TRA, EOU, USF, and USE, we now investigate the structural component of our model. Following Hair and Alamer’s suggestions [54], we (i) examine the structural model for collinearity issues related to the variance inflation factor (VIF), (ii) assess the significance and relevance of the structural relationships by their path coefficients using model bootstrapping, and (iii) assess the explanatory capacity of the model using the determination coefficient (R²) and the effect size (f²).

Regarding (i), the VIF analysis shows that our model does not exhibit evidence of collinearity among the four constructs [50], as the greatest VIF values are below the threshold of 5 [51,54]. Regarding (ii), we assess the significance and the relevance of the structural model paths by bootstrapping the sampling distribution [55,56,57] to test the structural model’s relationship coefficients for statistical significance at CI_α = 0.05, as summarized in Figure 10. Finally, concerning (iii), the R² values (see Figure 10) for the endogenous constructs USF, EOU, and USE are located close to the moderate threshold of 0.5 [50]. This suggests that our model has a satisfactory ability to predict outcomes within the sample [51].

The measurement and structural model analysis results validate the TAM in our context, indicating that the constructs of USF and EOU consistently forecast the intention to utilize the process. These findings highlight the robustness of the links within the model and offer empirical validation for its internal consistency. The validated model indicates that user perceptions are precisely represented and that it may be reliably utilized to forecast technology acceptance in this context.

6.3.3. Interpretation of Results

The outcomes of the PLS-SEM analysis offer a distinct depiction of the interplay between various structures in the TAM, which impact the acceptance and use of the suggested technology. The model demonstrates that EOU has a substantial impact on the perception of USF, as evidenced by a robust path coefficient of 0.76. The significant level of influence emphasizes the necessity of developing the technology to be user-friendly, since the simplicity of use directly improves the perceived value and usefulness of the technology. Furthermore, the correlation between TRA and USF, with a path coefficient of 0.26, suggests that although TRA plays a significant role in determining real USF, it is not the sole contributing factor. The model proposes that several factors, such as user attitudes, external influences, and the implementation environment, have a substantial impact on the adoption of the technology in practice. The existence of a negative route coefficient (−0.28) between one of the components and USE indicates the possibility of resistance or obstacles that may discourage usage. These concerns could be linked to perceived barriers or complexities that users face. It is only reasonable that our plan is currently hindered by technological limitations, i.e., the availability of a supporting tooling infrastructure. Nevertheless, our findings indicate that it would be beneficial to carry out additional research on the proposed process model after the necessary technology infrastructure has been established [10,58,59].

Implications

The analysis conclusions have significant consequences for stakeholders engaged in the development, implementation, and management of the proposed technology. The robust correlation between EOU and USE implies that to promote the acceptance and usage of a product or service, it is imperative to give utmost importance to enhancing the user experience. Streamlining user engagement and ensuring the technology is intuitive can greatly improve consumers’ opinions of its USF, potentially resulting in increased adoption rates. The correlation between USF and USE suggests that merely making the technology beneficial is required but not enough to guarantee universal adoption. This highlights the necessity of adopting a comprehensive approach that considers elements such as user education, assistance mechanisms, resolving any possible apprehensions or misunderstandings that users might have, and the availability of a relevant tooling infrastructure. The probability of effective adoption increases when thorough support is provided and user concerns are addressed. The inverse correlation identified with USE serves as an indication that certain characteristics of a technology or its implementation may be causing difficulties for users. This may encompass intricacies in the functionality of the technology, insufficient support systems, or other obstacles that cause people to be reluctant in completely embracing the technology. It is crucial to identify and address these difficulties to enhance the technology’s overall adoption and ensure that it fulfills the demands and expectations of its intended users. Evidently, the current state of our tool infrastructure is inadequate [10,58,59].

Usefulness of the Proposed Technology

The evaluation of a technology is based on its perceived EOU, which is closely connected to its perceived USF. This indicates that the process has been carefully planned and executed to provide ease of use, which is a crucial element in determining its overall effectiveness. Nevertheless, the moderate correlation between USF and actual USE suggests that although the technology is perceived as helpful, there might be other variables that influence its adoption. This may entail the requirement for more resilient implementation tactics, user enlightenment, or tackling specific obstacles that could hinder its utilization (see above). In general, according to the TAM results, the suggested process model is a feasible and efficient tool. However, its ultimate success will rely on resolving the recognized obstacles and guaranteeing that users feel assisted and self-assured in its utilization. The TAM study offers useful insights that can direct the subsequent development and improvement of the process model, guaranteeing that it fulfills user requirements and attains its desired results.

Contributions

Agile engineering contributes significantly to DT engineering by introducing a flexible, iterative approach that ensures stakeholder requirements and use cases are consistently addressed throughout the life cycle of the DT. The key contributions include the following:

Iterative Development: Agile engineering emphasizes small, incremental development cycles, enabling continuous refinement and alignment of the DT with evolving project requirements. This is particularly valuable during the design and construction phases, where real-time adjustments are often necessary.
Stakeholder-Driven Process: Agile engineering places stakeholders at the center of the development process. Frequent feedback loops ensure that the DT evolves in a way that directly reflects user needs and expectations, making it adaptable to diverse scenarios.
Handling Uncertainty and Complexity: Construction projects often encounter unexpected changes, such as site-specific conditions or regulatory updates. Agile engineering’s change-anticipatory nature allows the DT to incorporate these adjustments dynamically, avoiding rigid processes that might lead to delays or misalignments.
Focus on Rapid Value Delivery: Agile methods encourage the identification of “quick wins”—high-priority use cases that deliver immediate value to stakeholders. This ensures that the DT generates benefits early in the project life cycle, boosting stakeholder confidence and project momentum.
Quality Assurance: Agile frameworks integrate rigorous quality checks after each development cycle, ensuring that the DT consistently meets performance expectations and remains aligned with stakeholder goals.

In DT engineering, agile methods provide the flexibility and responsiveness needed to manage the evolving requirements of construction projects, ensuring that the DT remains relevant, useful, and aligned with real-world needs.

Change management plays a complementary role in digital twin (DT) engineering, providing a structured framework to manage the integration of diverse data sources and accommodate evolving project requirements. Its contributions include the following:

Systematic Information Integration: Change management ensures that data from various sources (e.g., BIM models, sensor data, and stakeholder inputs) are incorporated into the DT systematically. This structured approach minimizes the risk of data inconsistencies and enhances the reliability of the DT.
Life Cycle Adaptability: By establishing a process for recording, evaluating, and implementing changes, change management ensures that the DT remains relevant throughout its life cycle. This is crucial as the DT transitions from the design phase to construction and ultimately to operation.
Minimizing Risk: Change management frameworks reduce the risks associated with integrating dynamic and heterogeneous data by formalizing procedures for assessing and mitigating potential impacts of changes.
Enhanced Collaboration: Clear change management procedures foster transparency and improve communication among stakeholders. By documenting change requests and decisions, all parties stay informed and aligned, reducing organizational friction.
Support for Complex, Multi-Stakeholder Projects: Construction projects often involve a wide range of stakeholders with differing priorities. Change management enables the reconciliation of these priorities by providing a structured process for evaluating and implementing changes in a balanced manner.
Alignment with Agile Engineering: The change-driven nature of the process naturally complements agile engineering’s iterative approach. Together, they create a seamless system where changes can be integrated continuously without disrupting the project timeline.
Enabling Real-Time Updates: Change management supports the DT’s ability to reflect real-world conditions by ensuring that updates—such as those stemming from as-built data or operational feedback—are incorporated systematically.
Enhancing Decision-Making: Change management in DT engineering enables comprehensive data analysis and the simulation of various scenarios. These insights support well-informed decision-making and the implementation of automated processes to ensure optimal execution across all life cycle phases of an asset.

When combined, agile engineering and change management form a robust framework for DT engineering. Agile engineering provides the iterative, stakeholder-focused mechanism to develop and refine the DT, while change management offers the structured processes to handle complexity, mitigate risks, and ensure the DT evolves seamlessly over time. This synergy ensures that the DT remains a dynamic, reliable representation of the physical asset, capable of adapting to the diverse and shifting demands of construction engineering.

6.4. Contributions to ISO 19650-1

ISO 19650-1 specifies, among other things, how information must be transmitted between parties to support the decision-making of the respective appointing parties. Figure 11 depicts the pertinent diagram from ISO 19650. Due to the fact that the change management process considers information discipline by discipline, it serves as the foundation for the information exchange process outlined in ISO 19650-1. For instance, a stakeholder’s decision can result in a change request, which then initiates the described change management process. Since change requests can occur at all ISO 19650-1 figure levels, the change management process can be applied between them freely, as depicted in Figure 12. In addition, it illustrates that the information delivery processes outlined in ISO 19650-1, which are influenced by numerous changes, are supported by the change management processes, which are in turn influenced by information generation.

6.5. Related Work and Discussion

It is not a novel concept to utilize information technology and software engineering to enhance established processes in the construction industry [8,60]. Fangxioa et al. [60] already investigated the idea of integrating change management with BIM. However, their proposal addresses the early design and planning phases as they pertain to the integration of changes into the BIM model. In contrast, we seek to address all phases of the building’s life cycle. A comparable argument applies to the work of Kosicki et al. [8], which proposes a novel change process inspired by DevOps [61]. Like Fangxioa et al., Kosicki et al. only address the early design and planning phases with their Design Ops concept to enhance modeling collaboration. Again, our work aims to address all phases of the building’s life cycle, not just the initial phases of planning and design. Moreover, our proposal emerged as an interdisciplinary effort within interdisciplinary projects, with civil engineers representing the stakeholders and computer scientists as the process management and digital twin specialists. We argue that it is this combination that renders our proposal meaningful and feasible.

The concept of the construction digital twin as presented in our article is not unfamiliar. Boje et al. [31] already introduced the concept in their recent work, in which they attempt to identify current deficiencies in BIM that impede the development of the CDT along with suggestions for achieving the construction of the CDT. In contrast to their work, which is rooted at the technological level, our work is rooted at the process level through the introduction of an agile, change-driven process for engineering the CDT. Importantly, our work promotes a bottom-up process for implementing BIM and, consequently, for constructing the CDT along the phases of a building’s life cycle. Specifically, we elicited essential requirements based on the building life cycle phases that must be met for the successful construction of the CDT. Current manifestations of DTs in AECO follow a more ad hoc approach to delivering specific use cases [39,62,63,64,65,66,67]. We contend that both these requirements and an accompanying process are necessary. Our work aims to establish a generic, purely requirements-driven process that enables the targeting of diverse stakeholder needs and use cases. This is exemplified by the application of IT change management as the cornerstone of our agile process, as described in Section 4. In addition, because it is influenced by agile engineering, our proposed process includes quality metrics that enable continuous evaluation of both processes and final products. Our definitions of these metrics are, to the best of our knowledge, novel in construction engineering.

Afzal et al. [68] discuss the rapid evolution and application of a DT within the AECO sector, identifying five key components critical for its development: technologies, maturity levels, data layers, enablers, and functionalities. This highlights the growing importance of DTs in enhancing decision-making processes, optimizing operations, and improving the life cycle management of built assets. Our work aligns with their ideas in that technological readiness is a key factor for succeeding in successfully building a DT. In addition, the proposed maturity levels of Afzal et al. substantially align with a phase-based understanding of maturity in that given the actual project phase (design, construction, and operation) the DT matures. Yet, contrary to use, Afzal et al. neglect the actual engineering aspect of the DT, which for now poses the biggest challenges. Reja et al. [69] outline the objectives and implementation challenges of DTs in construction project management, framed within the PMBOK guidelines. This emphasizes the necessity of integrating geometric and non-geometric data to enhance decision-making and operational efficiency but identifies significant challenges related to data integration, interoperability, and the current state of DT technology. The work of Reja et al. thus underpins our thoughts and ideas, as well as our results in that most barriers are located at the technological layer. Apart from that, Reja et al., like Afzal et al. [68], also do not address the actual engineering aspect of the DT along a project’s life cycle. In light of Afzal et al. [68] and Reja et al. [69], our work not only investigates challenges and opportunities, and relevant requirements for engineering DTs in construction engineering but in addition provides a novel process model with the aim to facilitate building DTs in construction engineering by outlining a roadmap and guidance on how to incorporate changes along the complete building life cycle.

Our previous evaluation of our proposed procedure indicates its viability for construction engineering. Importantly, the agile nature of our process ensures that the necessary requirements are specified for the subsequent application of changes to building models, the actual building, and the CDT. In turn, the change-driven nature of our process ensures that changes are evaluated prior to application, as well as after application, to ensure that requirements are met (cf., Figure 6). Our proposed quality metrics also permit evaluation of the process’s successful application.

The proposed process provides not only the framework for engineering the CDT but also a proposal for implementing BIM in a bottom-up manner. Current BIM implementations are traditionally top-down, resulting in enormous, barely comprehensible, and practically impossible process models. This is exemplified when aligning our proposed process model with ISO 19650-1, the de facto standard governing the organization and digitization of information regarding buildings and civil engineering works, including BIM. We assert that our process model can provide the missing building block regarding the generation of information. Despite specifying the type and structure of information to be made available and processed between and during the various phases of the building’s life cycle, ISO 19650-1 omits the crucial step of information generation. We are unaware of any other process that addresses the issue of information generation within the context of ISO 19650-1. We therefore claim that our work is paramount in offering practitioners a concise and efficient process model to implement the ISO 19650-1 standard for information delivery in modern BIM-based construction projects.

In summary, our contribution provides a skeleton process model for implementing BIM from the bottom up, as well as guidelines for iteratively conceiving the CDT. Inspired by agile engineering and IT change management, our process not only builds on well-established practices but also permits the immediate definition of quality criteria to evaluate the successful applicability of our proposed process model. We contend that the combination of all three—agile engineering, IT change management, and process quality metrics—provides a fertile environment for successfully implementing BIM and delivering the CDT. Importantly, the gestation of the DT using a combination of agile engineering and IT change management eventually delivers a platform for unified change management, one of the top-priority digital solution areas that are currently lacking appropriate tool support [15].

6.6. Threats to Validity

Naturally, threats to the validity of our approach exist. In the following, we discuss major threats to validity and how we mitigated those following Yin’s guidelines [70].

6.6.1. Construct Validity

Construct validity refers to the appropriateness of the claimed experimental measures and the correspondence between theory and observations. We utilized the TAM for our results. We did not engage in critical reflections concerning the quality of the TAM except for assessing its validity for the case at hand, which we assessed successfully. Under the circumstance that none of the participants in our study had any prior experience with agile or change-driven engineering, results are not skewed by such a bias. For the time being, we believe that no reflections are necessary; however, once our proposal moves to a productive stage, reflections on its appropriateness are inevitable.

6.6.2. Internal Validity

Internal validity is utilized to create a cause-and-effect relationship between a treatment and an outcome in determining if the results support the claims, cf. our design challenge, as stated in Section 1. Our findings demonstrate that a flexible, change-driven strategy permits prompt responses to difficulties in the construction process. However, we have only addressed a preliminary evaluation of our proposal in terms of its perceived use thus motivating a need for a continuing empirical evaluation of our proposal in productive use to obtain stronger evidence for our claims. To counteract this risk, we examine our idea in the previously described projects BIM2BEM [71] and TIM [72].

6.6.3. External Validity

External validity refers to the applicability and applicability of a study’s results to other contexts. We recognize that our method was only evaluated in a what-if environment, i.e., what if the process would be used. To mitigate this threat, it is necessary to apply larger, more realistic scenarios to empirically validate our current findings. Currently, it is not possible to conduct a comparative analysis with other proposals, except for those previously discussed in the context of related work, because none exist. However, based on our current evaluation, there is no reason to believe that our process cannot be successfully implemented in an actual construction environment.

6.7. Limitations

While this work addresses critical aspects of digital twin engineering, several limitations must be acknowledged. First, the scope of this study does not delve deeply into low-level technical implementation details, such as specific hardware configurations or software integration protocols. Instead, the focus has been on establishing a high-level framework and methodology, leaving finer-grained issues for subsequent research.

Additionally, considerations such as data privacy, security, and ownership are recognized as essential but are not comprehensively addressed in this work. These aspects are highly context-dependent and require tailored approaches that align with specific regulatory and organizational requirements. The handling of sensitive construction data or stakeholder information will likely necessitate a more detailed examination of privacy-preserving methods and robust data governance frameworks.

From an organizational perspective, implementing digital twins effectively requires alignment across multiple stakeholders, including construction firms, technology providers, and regulators. However, this study does not deeply explore the organizational dynamics, such as decision-making processes, change management, and stakeholder collaboration, that are critical for successful deployment. These challenges, including resistance to change or differing priorities among stakeholders, remain outside the scope of this work.

Moreover, the effective implementation of a digital twin necessitates the comprehensive digitization of construction and operational processes in general. This transformation involves converting traditional paper-based or manual workflows into digital processes. It requires the adoption of new technologies to achieve these digital processes and providing employee training to ensure their effective use. While this aspect is also not the primary focus of this paper, the presented framework establishes a strong foundation to address these challenges in future work.

Lastly, the proposed framework assumes a level of interoperability and standardization in data formats and communication protocols that may not yet be fully realized across diverse systems and projects. Addressing these organizational and technical gaps will be essential to validate and refine the framework in real-world applications.

7. Conclusions

In the construction industry, it is commonly assumed that BIM usage coincides with DT usage. In the context of Figure 1, however, the methods employed are primarily digital models or digital shadows. In AECO, it is initially necessary to raise awareness of the respective terms, whereas, in IT, a common understanding already exists. As a result of the increased use of digital methods and tools in the construction industry, including the introduction of BIM, more connections and interactions are emerging between the two disciplines. Thus, commonalities in the approaches become clearer and synergies can be utilized effectively in construction projects. This is evident in change management, whereas IT follows a considerably more systematic approach. Nonetheless, the fundamental processes are nearly identical.

This is the starting point for an important aspect of this article, which is the implementation of IT change management in the construction industry. This necessitates an even more systematic processing of changes, which ultimately includes more design process developments than is already typical in the BIM process. In the end, this would result in an improvement in efficiency and quality, and it would pursue a holistic approach. Critically, it should be noted that the creative problem-solving process in engineering and architecture is still at the forefront and that both DT and BIM must be viewed as tools.

The ultimate objective should be to achieve a DT by applying the described methods and processes in the most automated (BIM) design process possible. The advantages of such an approach would be extensive, and the new possibilities would improve results in every phase of the product’s life cycle as a result of a significantly higher information level and quality. BIM in the design process can already be viewed as a DT, it must be noted. However, future possibilities cannot be predicted with absolute certainty at this time.

We argue that a focus on IT is advantageous. In its early days, software engineering struggled to successfully execute large-scale projects and therefore sought inspiration from the well-established construction discipline; this can be viewed as the birth of the waterfall model as it is used in the information technology industry. Experts in software engineering realized in the late 1990s, however, that such plan-based approaches fail to scale and anticipate change, resulting in the birth of agile. We argue that modern construction engineering should look to IT and adopt the prevalent working styles there, such as agile engineering and change management. Our proposal outlines the initial phase of a transformational change within AECO.

Despite the growing emphasis in construction projects on IT technical aspects, possibilities, and benefits, human and social factors must not be overlooked. Parallel to the technical solutions, it is crucial to work on the effects of established processes in the construction industry and the acceptance of stakeholders. As future work, we will conduct a comprehensive empirical evaluation of our proposal in the context of BIM2BEMFlow and TIM to assess its impact on established processes and stakeholders’ acceptance.

7.1. Limitations

We recognize that our process is not the silver bullet for successfully implementing the CDT. Specific to our proposed process model, we identify two potential challenges.

7.1.1. Technical Challenges

Currently, a combination of open and closed BIM is the most common way to practice BIM. This results in immediate, unavoidable media disruptions at the level of information exchange. Evidently, this also affects our proposed procedure, as it ultimately relies on the assumptions of open formats and tools that permit simple aggregation, integration, and manipulation of data. However, we argue that to successfully implement BIM and move towards open BIM, it is necessary to fully realize BIM’s potential. On a technical level, this necessitates potentially novel, open collaboration platforms that permit both static model management and evolution based on open, common formats, such as semantic web technologies [73] and dynamic data integration from simulations in early design and planning phases, as well as the actual building during construction and operation [58,59,74]. Such a platform comprises a central repository, e.g., a database-backed versioning system for tracking the evolution of modeling artifacts over time, a data warehouse for persisting, e.g., sensor readings, and integration for BIM issues, which act as the basis for a change request, i.e., a reported issue triggers the creation of an RFC. In terms of internal data representation, the IFC is the format of choice because of its open nature and readiness to integrate with different trades as well as BIM issues [75,76].

7.1.2. Organizational Challenges

Implementing our proposed process necessitates significant organizational transformations across design offices, construction companies, and facility management teams. Such transformations often require stakeholders to shift away from established practices, leading to resistance and hesitation in adopting new methodologies. Organizational challenges in adopting DTs are well documented and encompass a range of barriers, including low levels of knowledge, limited technology acceptance, unclear value propositions, and the need for cross-disciplinary collaboration [77].

For example, a systematic review identified critical barriers to the application of digital technologies in construction health and safety, including technical issues, training and knowledge gaps, implementation challenges, data analysis limitations, and system efficiency problems [78]. Similarly, another study identified thirty-seven barriers to using digital technologies to implement circular economy practices in the construction industry, categorized into areas such as organizational, infrastructure, regulatory, and technological challenges [79]. These findings illustrate the global nature of these challenges, transcending specific regional or organizational contexts.

To address these challenges, our proposed process provides a structured framework for eliciting transformational requirements, evaluating organizational changes, and assessing the successful implementation of these transformations. The framework emphasizes stakeholder engagement, iterative feedback, and clear value propositions, which are critical to fostering acceptance and ensuring success. By aligning with Kotter’s principles for leading organizational change [80,81,82,83], our approach facilitates the smooth integration of digital twin technologies into established workflows, making the transformation more manageable and sustainable.

Author Contributions

Conceptualization, P.Z.; methodology, P.Z., A.J., L.S., H.E. and G.F.; writing—original draft preparation, P.Z., L.S. and H.E.; writing—review and editing, P.Z., A.J., L.S., H.E., G.F. and M.F.; visualization, P.Z., H.E. and L.S.; supervision, P.Z.; funding acquisition, M.F. and G.F. All authors have read and agreed to the published version of the manuscript.

Funding

The research leading to these results has received funding from FFG projects BIM2BEM-Flow [72] and Tunnel Information Modeling [73].

Data Availability Statement

Dataset available on request from the authors.

Conflicts of Interest

The authors declare no conflict of interest.

References

Gozde, B. Digital Twin Research in the AECO-FM Industry. J. Build. Eng. 2021, 40, 102730. [Google Scholar]
Begić, H.; Galić, M. A Systematic Review of Construction 4.0 in the Context of the BIM 4.0 Premise. Buildings 2021, 11, 337. [Google Scholar] [CrossRef]
Tang, S.; Sheldon, D.R.; Eastman, C.M.; Pishdad-Bozorgi, P.; Xinghua, G. A review of building information modeling (BIM) and the internet of things (IoT) devices integration: Present status and future trends. Autom. Constr. 2019, 101, 127–139. [Google Scholar] [CrossRef]
Farwick, M.; Schweda, C.M.; Breu, R.; Hanschke, I. A situational method for semi-automated Enterprise Architecture Documentation. Softw. Syst. Model. 2016, 15, 397–426. [Google Scholar] [CrossRef]
Breu, R. Ten Principles for Living Models—A Manifesto of Change-Driven Software Engineering. In Proceedings of the 2010 International Conference on Complex, Intelligent and Software Intensive Systems, Krakow, Poland, 15–18 February 2010. [Google Scholar]
Beck, K.; Beedle, M. Manifesto for Agile Software Development. 2001. Available online: http://agilemanifesto.org (accessed on 4 October 2022).
Chow, T.; Cao, D.-B. A survey study of critical success factors in agile software projects. J. Syst. Softw. 2008, 81, 961–971. [Google Scholar] [CrossRef]
Kosicki, M.; Tsiliakos, M.; ElAshry, K.; Borgstrom, O.; Rod, A.; Tarabishy, S.; Nguyen, C.; Davis, A.; Tsigkari, M. Towards DesignOps Design Development, Delivery and Operations for the AECO Industry. In Towards Radical Regeneration; Springer International Publishing: Cham, Switzerland, 2022. [Google Scholar]
Sakikhales, M.H.; Stravoravdis, S. Using agile project management and BIM for improved building performance. In Building Information Modelling, Building Performance, Design and Smart Construction; Springer: Berlin/Heidelberg, Germany, 2017; pp. 65–78. [Google Scholar]
Zech, P.; Jäger, A.; Fröch, G.; Pfluger, R.; Breu, R. Agile, continuous building energy modeling and simulation. Simulation 2024, 00375497241251852. [Google Scholar] [CrossRef]
Ning, G.; Singh, V.; Taylor, C.; London, K.; Brankovic, L. Building Information Modelling: An Issue of Adoption and Change Management. In Proceedings of the ICAN Conference 2007, Sydney, Australia, 9–12 July 2007. [Google Scholar]
Davis, C.W. Agile Metrics in Action: Measuring and Enhancing the Performance of Agile Teams; Manning Publications: New York, NY, USA, 2015. [Google Scholar]
Succar, B.; Sher, W.; Williams, A. Measuring BIM performance: Five metrics. Archit. Eng. Des. Manag. 2012, 8, 120–142. [Google Scholar] [CrossRef]
Fred, D.D.; Bagozzi, R.P.; Warshaw, P.R. User Acceptance of Computer Technology: A Comparison of Two Theoretical Models. Manag. Sci. 1989, 35, 982–1003. [Google Scholar]
Yilmaz, G.; Salter, L.; McFarlane, D.; Schönfuß, B. Low-cost (Shoestring) digital solution areas for enabling digitalisation in construction SMEs. Comput. Ind. 2023, 150, 103941. [Google Scholar] [CrossRef]
Hevner, R.; March, S.T.; Park, J.; Ram, S. Design Science in Information Systems Research. MIS Q. 2004, 28, 75–105. [Google Scholar] [CrossRef]
Wieringa, R.J. Design Science Methodology for Information Systems and Software Engineering; Springer: Berlin/Heidelberg, Germany, 2014. [Google Scholar]
Radhakisan, B.; Gill, H. Cyber-physical systems. Impact Control. Technol. 2011, 12, 161–166. [Google Scholar]
Wolf, W. Cyber-physical systems. Computer 2009, 42, 88–89. [Google Scholar] [CrossRef]
Chi-Sheng, S.; Jyun-Jhe, C.; Reijers, N.; Tei-Wei, K. Designing CPS/IoT applications for smart buildings and cities. IET Cyber-Phys. Syst. Theory Appl. 2016, 1, 3–12. [Google Scholar]
Ragunathan, R.; Insup, L.; Liu, S.; Stankovic, J. Cyber-physical systems: The next computing revolution. In Proceedings of the 47th Design Automation Conference, New York, NY, USA, 13–18 June 2010. [Google Scholar]
Borrmann, A.; König, M.; Koch, C.; Beetz, J. Building Information Modeling: Technology Foundations and Industry Practice; Springer: Berlin/Heidelberg, Germany, 2018. [Google Scholar]
Azhar, S. Building Information Modeling (BIM): Trends, Benefits, Risks, and Challenges for the AEC Industry. Leadersh. Manag. Eng. 2011, 11, 241–252. [Google Scholar] [CrossRef]
Galler, R.; Huemer, C.; Bednar, T.; Huymajer, M.; Wenighofer, R.; Paskaleva, G.; Steiner, B.; Melnyk, O. Aktuelle Forschung im Bereich der Digitalisierung des konventionellen Tunnelbaus. BHM Berg Hüttenmännische Monatshefte 2023, 168, 601–607. [Google Scholar] [CrossRef]
ISO 19650-1:2018; International Organization for Standardization Organization and Digitization of Information About Buildings and Civil Engineering Works, Including Building Information Modelling (BIM)—Information Management Using Building Information Modelling—Part 1: Concepts and Principles. ISO: Geneva, Switzerland, 2018. Available online: https://www.iso.org/ (accessed on 23 November 2024).
Grieves, M.; Vickers, J. Digital twin: Mitigating unpredictable, undesirable emergent behavior in complex systems. In Transdisciplinary Perspectives on Complex Systems; Springer: Berlin/Heidelberg, Germany, 2017; pp. 85–113. [Google Scholar]
Kritzinger, W.; Karner, M.; Traar, G.; Henjes, J.; Sihn, W. Digital Twin in manufacturing: A categorical literature review and classification. IFAC-Pap. 2018, 51, 1016–1022. [Google Scholar] [CrossRef]
Singh, M.; Fuenmayer, E.; Hinchy, E.P.; Qiao, Y.; Murray, N.; Devine, D.; Twin, D. Digital Twin: Origin to Future. Appl. Syst. Innov. 2021, 4, 36. [Google Scholar] [CrossRef]
Flora, M.; Weiser, T.; Zech, P.; Fontana, A.; Ruepp, A.; Bergmeister, K. Added value in mechanized tunnelling by intelligent systems. Geomech. Tunn. 2021, 14, 522–599. [Google Scholar]
Fuller; Fan, Z.; Day, C.; Barlow, C.; Twin, D. Challenges and Open Research. IEEE Access 2020, 8, 108952–108971. [Google Scholar] [CrossRef]
Boje; Guerriero, A.; Kubicki, S.; Rezgui, Y. Towards a semantic Construction Digital Twin: Directions for future research. Autom. Constr. 2020, 114, 103179. [Google Scholar] [CrossRef]
Balaji, S.; Murugaiyan, M.S. Waterfall vs. V-Model vs. Agile: A comparative study on SDLC. Int. J. Inf. Technol. Bus. Manag. 2012, 2, 26–30. [Google Scholar]
Andrei, B.-A.; Casu-Pop, A.-C.; Gheorghe, S.-C.; Boiangiu, C.-A. A study on using waterfall and agile methods in software project management. J. Inf. Syst. Oper. Manag. 2019, 13, 125–135. [Google Scholar]
Schwaber, K.; Sutherland, J.; Alliance, S. The scrum guide. Scrum Alliance 2011, 21, 1–38. [Google Scholar]
Dybå, T.; Dingsøyr, T. Empirical studies of agile software development: A systematic review. Inf. Softw. Technol. 2008, 50, 833–859. [Google Scholar] [CrossRef]
Office of Government Commerce. ITIL Version 3 Service Transition; The Stationary Office: London, UK, 2007.
Architekten-Verein, Ö.I.-U. BIM-Anwendungsfälle Öffentlicher Auftraggeber; ÖIAV-Resort “Öffentliche Auftraggeber”: Vienna, Austria, 2023. [Google Scholar]
Siemens. Digital Tunnel: Schneller Eröffnet. Sicherer Betrieben. 2024. Available online: https://www.siemens.com/de/de/produkte/automatisierung/produkte-fuer-spezifische-anforderungen/tunnelautomatisierung.html (accessed on 9 September 2024).
Deng, M.; Menassa, C.C.; Kamat, V.R. From BIM to digital twins: A systematic review of the evolution of intelligent building representations in the AEC-FM industry. J. Inf. Technol. Constr. 2021, 26, 58–83. [Google Scholar] [CrossRef]
Chu, J.; Varaskin, S.; Klotz, U.; Mengé, P. Construction Processes. In Proceedings of the 17th International Conference on Soil Mechanics and Geotechnical Engineering, Alexandria, Egypt, 5–9 October 2009. [Google Scholar]
Bernd-Holger, S. Cyber-physical Systems Engineering. In Engineering Trustworthy Software Systems; Springer: Berlin/Heidelberg, Germany, 2016; pp. 256–289. [Google Scholar]
Gilb, T.; Finzi, S. Principles of Software Engineering Management; Addison-Wesley Reading: Boston, MA, USA, 1988. [Google Scholar]
Samireh, J.; Wohlin, C. Global software engineering and agile practices: A systematic review. J. Softw. 2012, 24, 643–659. [Google Scholar]
Hazzan, O.; Dubinsky, Y. Agile Software Engineering; Springer Science & Business Media: Berlin/Heidelberg, Germany, 2009. [Google Scholar]
Rumane, R. Quality Management in Construction Projects; CRC Press: Boca Raton, FL, USA, 2017. [Google Scholar]
Borrmann, M.; König, C. Koch and Beetz Jakob, Building Information Modeling; Springer Fachmedien Wiesbaden GmbH: Wiesbaden, Germany, 2021. [Google Scholar]
Sillitti, A.; Succi, G. Source Code Repositories and Agile Methods. In Proceedings of the XP 2005: Extreme Programming and Agile Processes in Software Engineering, Sheffield, UK, 18–23 June 2005. [Google Scholar]
Nikola, M.; Granic, A. Technology acceptance model: A literature review from 1986 to 2013. Univers. Access Inf. Soc. 2015, 14, 81–95. [Google Scholar]
Riemenscheider, C.K.; Hardgrave, B. Explaining software development tool use with the technology acceptance model. J. Comput. Inf. Syst. 2001, 41, 1–8. [Google Scholar]
Hair, J.F., Jr.; Hult, G.T.M.; Ringle, C.R.; Sarstedt, M. A Primer on Partial Least Squares Structural Equation Modeling (PLS-SEM); Sage Publications: London, UK, 2021. [Google Scholar]
Hair, J.F., Jr.; Hult, G.T.M.; Ringle, C.M.; Sarstedt, M.; Danks, N.P.; Ray, S. Partial Least Squares Structural Equation Modeling (PLS-SEM) Using R: A Workbook; Springer Nature: Berlin/Heidelberg, Germany, 2021. [Google Scholar]
Latan, H.; Noonan, R.; Matthews, L. Partial least squares path modeling. In Partial Least Squares Path Modeling: Basic Concepts, Methodological Issues and Applications; Springer: Berlin/Heidelberg, Germany, 2017. [Google Scholar]
Ray, S.; Danks, N.; Calero-Valdez, A. SEMinR: Domain-Specific Language for Building, Estimating, and Visualizing Structural Equation Models in R. 2021. Available online: https://ssrn.com/abstract=3900621 (accessed on 21 January 2025).
Hair, J.; Alamer, A. Partial least squares structural equation modeling (PLS-SEM) in second language and education research: Guidelines using an applied example. Res. Methods Appl. Linguist. 2022, 1, 100027. [Google Scholar] [CrossRef]
Nitzl; Roldan, J.L.; Cepeda, G. Mediation analysis in partial least squares path modeling: Helping researchers discuss more sophisticated models. Ind. Manag. Data Syst. 2016, 116, 1849–1864. [Google Scholar] [CrossRef]
Zhao, X.; Lynch, J.G., Jr.; Chen, Q. Reconsidering Baron and Kenny: Myths and truths about mediation analysis. J. Consum. Res. 2010, 37, 197–206. [Google Scholar] [CrossRef]
Preacher, K.J.; Hayes, A.F. Asymptotic and resampling strategies for assessing and comparing indirect effects in multiple mediator models. Behav. Res. Methods 2008, 40, 879–891. [Google Scholar] [CrossRef] [PubMed]
Zech, P.; Fröch, G.; Breu, R. A Requirements Study on Model Repositories for Digital Twins in Construction Engineering. In Proceedings of the International Conference on Cooperative Information Systems, Gröningen, The Netherlands, 30 October–3 November 2023. [Google Scholar]
Zech, P.; Pobitzer, P.; Fröch, G.; Breu, R. A Proposal for a Models-meet-Data Repository For Digital Twins in Construction Engineering. In Proceedings of the 2024 IEEE 21st International Conference on Software Architecture Companion (ICSA-C), Hyderabad, India, 4–8 June 2024. [Google Scholar]
Liu, F.; Jallow, A.K.; Anumba, C.J.; Wu, D. A Framework for Integrating Change Management with Building Information Modeling. Comput. Civ. Build. Eng. 2014, 2014, 439–446. [Google Scholar]
Ebert; Gallardo, G.; Hernantes, J.; Serrano, N. DevOps. IEEE Softw. 2016, 33, 94–100. [Google Scholar] [CrossRef]
Qiuchen, L.; Xiang, X.; Parlikad, A.K.; Schooling, J.M. Digital twin-enabled anomaly detection for built asset monitoring in operation and maintenance. Autom. Constr. 2020, 118, 103277. [Google Scholar]
Shahzad, M.; Shafiq, M.T.; Douglas, D.; Kassem, M. Digital Twins in Built Environments: An Investigation of the Characteristics, Applications, and Challenges. Buildings 2022, 12, 120. [Google Scholar] [CrossRef]
Broo, G.; Schooling, J. Digital twins in infrastructure: Definitions, current practices, challenges and strategies. Int. J. Constr. Manag. 2021, 23, 1254–1263. [Google Scholar] [CrossRef]
Donkers, A.J.; Yang, D.; de Vries, B.; Baken, N.H. Real-time building performance monitoring using semantic digital twins. in LDAC 2021 Linked Data in Architecture and Construction. In Proceedings of the 9th Linked Data in Architecture and Construction Workshop, Luxembourg, 11–13 October 2021. [Google Scholar]
Gang, Y.; Wang, Y.; Mao, Z.; Hu, M.; Sugumaran, V.; Wang, K.Y. A digital twin-based decision analysis framework for operation and maintenance of tunnels. Tunn. Undergr. Space Technol. 2021, 116, 104125. [Google Scholar]
Marc, W.; Markus, M.-W.; Herbrand, M.; Ullerich, C. The concept of digital twin to revolutionise infrastructure maintenance: The pilot project smartBRIDGE Hamburg. In Proceedings of the 27th ITS World Congress, Hamburg, Germany, 11–15 October 2021. [Google Scholar]
Afzal, M.; Man-Li, R.Y.; Shoaib, M.; Ayyub, M.F.; Tagliabue, L.C.; Bilal, M.; Ghafoor, H.; Manta, O. Delving into the Digital Twin Developments and Applications in the Construction Industry: A PRISMA Approach. Sustainability 2024, 15, 16436. [Google Scholar] [CrossRef]
Reja, V.K.; Pradeep, M.S.; Varghese, K. Digital Twins for Construction Project Management (DT CPM): Applications and Future Research Directions. J. Inst. Eng. (India) Ser. A 2024, 105, 793–807. [Google Scholar] [CrossRef]
Yin, R.K. Case Study Research Design and Methods; Sage: London, UK, 2014. [Google Scholar]
BIM2BEM-Flow. 2021. Available online: https://projekte.ffg.at/projekt/4396767 (accessed on 30 September 2022).
TIM. Tunnel Information Modelling. 2021. Available online: https://projekte.ffg.at/projekt/3368110 (accessed on 30 September 2022).
Pauwels, P.; Zhang, S.; Lee, Y.-C. Semantic web technologies in AEC industry: A literature overview. Autom. Constr. 2017, 73, 145–165. [Google Scholar] [CrossRef]
Zech, P.; Nardin, C.; Ristov, S.; Flora, M.; Breu, R. Digital-Twins-as-a-Service in Construction Engineering. In Proceedings of the 2024 IEEE 20th International Conference on Automation Science and Engineering, Bari, Italy, 28 August–1 September 2024. [Google Scholar]
Zech; Zech, P.; Goldin, E.; Hammes, S.; Geisler-Moroder, D.; Pfluger, R.; Breu, R. Model-Based Auto-Commissioning of Building Control Systems. In Proceedings of the 26th International Conference on Enterprise Information Systems (ICEIS 2024), Angers, France, 28–30 April 2024. [Google Scholar]
Zech, P.; Plörer, D.; Pfluger, R.; Breu, R. Scalable Building Energy Efficiency Balancing. In Proceedings of the 2024 Annual Modeling and Simulation Conference (ANNSIM), Washington, DC, USA, 20–23 May 2024. [Google Scholar]
De-Graft, J.O.; Perera, S.; Osei-Kyei, R.; Rashidi, M.; Bamdad, K.; Famakinwa, T. Barriers to the Adoption of Digital Twin in the Construction Industry: A Literature Review. Informatics 2023, 10, 14. [Google Scholar] [CrossRef]
Daniel, I.; Oshodi, O.S.; Nwankwo, N.; Emuze, F.A.; Chinyio, E. Barriers to the Application of Digital Technologies in Construction Health and Safety: A Systematic Review. Buildings 2024, 14, 2386. [Google Scholar] [CrossRef]
Thirumal, S.; Udawatta, N.; Karunasena, G.; Al-Ameri, R. Barriers to Adopting Digital Technologies to Implement Circular Economy Practices in the Construction Industry: A Systematic Literature Review. Sustainability 2024, 16, 3185. [Google Scholar] [CrossRef]
Slaman, Y.; Broten, N. An Analysis of John P. Kotter’s Leading Change; Macat Library: London, UK, 2017. [Google Scholar]
Gustavsson, T. Benefits of agile project management in a non-software development context: A literature review. In Proceedings of the Fifth International Scientific Conference on Project Management in the Baltic Countries, Riga, Latvia, 14–15 April 2016; University of Latvia: Riga, Latvia, 2016. [Google Scholar]
Sheetal, S.; Sarkar, D.; Gupta, D. Agile processes and methodologies: A conceptual study. Int. J. Comput. Sci. Eng. 2012, 4, 892. [Google Scholar]
Khajavi, S.H.; Motlagh, N.H.; Jaribion, A.; Werner, L.C.; Holmström, J. Digital Twin: Vision, Benefits, Boundaries, and Creation for buildings. IEEE Access 2019, 7, 147406–147419. [Google Scholar] [CrossRef]

Figure 2. Agile engineering.

Figure 3. Process model for a typical change according to [36].

Figure 4. Three stages of the CDT.

Figure 5. Generic change management process.

Figure 6. Agile, change-driven process model for engineering DTs.

Figure 7. Identification of quick wins for customers and stakeholders.

Figure 8. Relationship between lead time and cycle time.

Figure 9. Technology Acceptance Model with the four constructs training, perceived usefulness, perceived ease of use, and use [49].

Figure 10. Bootstrapped model. Values in ovals denote the R² value of the construct; values in brackets indicate the 95% CI of the corresponding path. Asterisks indicate statistical significance at the 0.01 (***), 0.05 (**), and 0.1 (*) levels, respectively.

Figure 11. Illustration of an information delivery process according to ISO 19650-1.

Figure 12. Change management process aligned with information delivery process according to ISO 19650-1.

Table 1. Consolidated use cases of discussed projects (Section 3.1 and Section 3.2).

	Use Case	Empirical Basis
UC1	Asset system control	TIM
UC2	Energy flow and usage simulation	BIM2BEM-Flow, TIM
UC3	Physical asset life cycle management	TIM
UC4	Artificial and natural building lighting simulation	BIM2BEM-Flow, TIM
UC5	Building operation and maintenance	BIM2BEM-Flow, TIM
UC6	Building system monitoring (e.g., lighting, heating, and cooling)	BIM2BEM-Flow, TIM
UC7	Building operation optimization (e.g., energy consumption)	BIM2BEM-Flow, TIM
UC8	Construction site progress monitoring	TIM
UC9	Safety and hazard monitoring	TIM
UC10	Building visualization and product line engineering	BIM2BEM-Flow, TIM

Table 2. Agile metrics for AECO combined with descriptive examples for each phase of the CDT.

		AECO Quality Criteria					CDT Phase
		Plannable Processes	Transparent Processes	Efficient Processes and Teams	Situation- and Context-Aware Processes	Resource-Aware Processes	Built as to Be Built	Built While Built	Built as Built
Quality	Mean time to repair (MTTR)	X	X	X		X	Time…
	Mean time to repair (MTTR)	X	X	X		X	… from discovery of a discipline-related collision to resolution	… to recognize and adapt deviations in the construction process from design to execution	… from the detection of an issue to its solution. Possible issue: sensor in the CDT does not track the data of the sensor in the CPS
	Lead time	X	X	X			Time to implement a new requirement.
	Lead time	X	X	X			Client-sourced (e.g., new facade system) or new requirements from a building law perspective	Adaptations due to deviating in situ geology	Changed conditions of use (e.g., changed lighting requirements)
	Cycle time	X	X	X			Time from start to finish of a task.
	Cycle time	X	X	X			Object designer incorporated new requirement of client	In case of critical event, processed immediately, equal to the lead time. For non-critical events, regular processing (lead time > cycle time)	Object planners and facility managers process new requirement due to changed conditions of use
	Mean time between failure (MTBF)	X	X		X	X	Failure (we define failure as the situation that occurs when a user does not perceive the expected result with respect to a request/specification): integration of a submodel with supported format fails	Failure: registration of the last 5 tunnel segments in the CDT not possible	Failure: CDT falsely triggers fire alarm
	Recidivism		X	X	X		Rate of tasks having to be reperformed.
	Recidivism		X	X	X		Submodel is rejected (e.g., by rule-based verification) because requirements are not met	Slab foundation is reduced to strip foundation and structural engineer not satisfied with design	Newly planned fixtures exceed capacity of the fuse
Team	Lead time	X	X	X			Time to implement a new requirement.
	Lead time	X	X	X			Implementation period for delivery of the modified facade system	Implementation period to deliver the adaptations through deviating in situ geologies	Implementation period of the delivery of the adapted CDT due to changed conditions of use
	Development time	X	X	X		X	Time to develop a new requirement.
	Development time	X	X	X		X	Connection detail of the new facade system was specified, development-time subsumes the modeling of the detail	Time required for modeling of the changed in situ geology or time required for static calculation/simulation of the new strip foundation	Fixing the link between the fire alarm system and CDT
	Deploy frequency			X			Number of delivered changes.
	Deploy frequency			X			Number of deviation(s) from information delivery plan	Number of (partial) invoices extracted from CDT	Every new deployment (such as changing requirements, missing requirements, …)
	Good/failed deliveries		X	X	X		Number/ratio of good/failed changes.
	Good/failed deliveries		X	X	X		Ratio of complete vs. incomplete data drops	Number of necessary deployments until the CDT reflects the CPS as is for subsequent invoice extraction	Ratio of rejecting/accepting the CDT in part of CAFM
	Total done	X		X		X	Number of finished tasks.
	Total done	X		X		X	Number of solved issues from an issue tracking tool (e.g., BIMcollab)	Planned construction measures as well as differences between planned and executed (e.g., defects)	Total issues from an issue tracking tool (e.g., BIMcollab) in the operational phase

Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

© 2025 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).

Share and Cite

MDPI and ACS Style

Zech, P.; Jäger, A.; Schneiderbauer, L.; Exenberger, H.; Fröch, G.; Flora, M. Agile Construction Digital Twin Engineering. Buildings 2025, 15, 386. https://doi.org/10.3390/buildings15030386

AMA Style

Zech P, Jäger A, Schneiderbauer L, Exenberger H, Fröch G, Flora M. Agile Construction Digital Twin Engineering. Buildings. 2025; 15(3):386. https://doi.org/10.3390/buildings15030386

Chicago/Turabian Style

Zech, Philipp, Alexandra Jäger, Larissa Schneiderbauer, Hans Exenberger, Georg Fröch, and Matthias Flora. 2025. "Agile Construction Digital Twin Engineering" Buildings 15, no. 3: 386. https://doi.org/10.3390/buildings15030386

APA Style

Zech, P., Jäger, A., Schneiderbauer, L., Exenberger, H., Fröch, G., & Flora, M. (2025). Agile Construction Digital Twin Engineering. Buildings, 15(3), 386. https://doi.org/10.3390/buildings15030386

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Menu