A Modular, Logistics-Centric Digital Twin Framework for Construction: From Concept to Prototype

Abstract

Traditional construction logistics rely on manual processes and fragmented tools, leading to inefficient planning, poor communication, and disorganized supply chains. Despite advances in digitalization, there is a lack of integrated, data-driven approaches tailored to construction logistics. To address this gap, this paper adopts a design-science approach to develop and evaluate a modular Digital Twin (DT) framework, the ConLogTwin. The framework integrates planning data with real-time site data through a robust data storage layer and digital services for automated planning and analytics. A prototype demonstrates the technical feasibility of mirroring both physical and organizational setups of projects, enabling more efficient and adaptive logistics management. The work contributes a modular reference architecture that integrates established open-source tools into a coherent, adaptable framework for construction logistics, enhancing practical applicability and lowering implementation barriers. A limitation is that the framework has not yet been validated in a full-scale field study, leaving its effectiveness in practice to be tested in a future study.

1. Introduction

The construction industry remains one of the least digitalised sectors, with a considerable lag in the adoption of digital technologies and innovative practices in comparison to other industries [1,2]. Nevertheless, emerging trends such as the Internet of Things (IoT) and big data are beginning to transform operational processes, offering new opportunities for transparency, automation, and optimisation [3]. These technologies generate increasing volumes of data that, if utilised effectively, can significantly enhance decision-making and process control [4]. In practice, however, much of the available data remains underutilised, creating so-called ‘data gaps’ [4].

Construction logistics, defined as the planning, implementation, coordination and control of material and information flows as part of the execution of a construction project [5], is particularly affected by these shortcomings. Although digital tools now support both planning and real-time execution, a significant proportion of data is poorly integrated or not systematically used, leading to inefficiencies [6,7]. Legal requirements such as the European Supply Chain Act [8] and the Corporate Sustainability Reporting Directive for recording CO₂ emissions [9] further underline the need for structured and transparent data management. Sundquist et al. [10] postulate that efficiency improvements in transportation and logistics can reduce total costs by up to 20%. Especially on-site, a substantial share of material handling is carried out by craftsmen [11], yet 32% of their time is spent on activities considered wasteful, such as unnecessary searching and travelling, largely due to a lack of comprehensive logistical oversight [7].

A key strategy to address these challenges is the effective coordination between on-site and off-site operations, which requires enhanced communication and collaborative planning among all stakeholders [10]. Various organisational and technical approaches have been developed over the years to improve logistics. These include Construction Consolidation Centres (CCCs), Just-in-Time (JIT) deliveries, and dedicated distribution teams, all aimed at improving supply efficiency and reducing on-site storage needs [12]. Complementary measures such as demand smoothing, on-site marketplaces, and off-site manufacturing contribute to streamlined resource management. Delivery Management Systems (DMSs) [12] have become widely used to coordinate site deliveries and provide visibility across the supply chain, with recent work showing how mobile applications and Geoinformation Systems (GISs)-based dashboards can further improve communication and decision-making [13,14]. Common Data Environments (CDEs) similarly facilitate the management of distributed project data. While these systems represent significant progress towards integrated construction logistics, they remain fragmented solutions that lack semantic data integration and limit stakeholder accessibility, thereby falling short of a full Digital Twin (DT).

Parallel to these developments, the adoption of the Building Information Modelling (BIM) method has enabled model-based construction logistics planning, where digital models are used to calculate material quantities and to plan, visualise, and validate site equipment in three dimensions. While promising, model-based logistics remains underrepresented in industry practice [15]. Simulation systems, including discrete event simulation, have also been used to optimise logistics strategies and assess their impacts on construction processes [16,17,18]. Although simulations demonstrate considerable potential, they are typically scenario-specific and cannot easily capture the dynamics of daily site operations.

Digital technologies further extend to IoT-based monitoring and location-aware systems that generate large volumes of real-time data. Platforms such as Autodesk Tandem [19] or Bosch IoT [20] enable sensor integration, while Global Positioning System (GPS) and geofencing techniques automate delivery notifications and route monitoring. GIS visualisations support oversight of deliveries and traffic flows [21,22], and drones or stationary cameras are increasingly used to track site progress. Additional IoT devices, including weather stations, smart cameras, Radio frequency identification (RFID)-equipped components, and digital time-tracking tools, further enrich the available data streams [23,24,25]. Yet, despite their potential, these technologies remain fragmented and are rarely combined into a unified decision-support environment.

Against this backdrop, the concept of the DT has gained attention as a promising unifying solution. According to Grieves [26], a DT consists of a real object and its corresponding digital counterpart, connected by a continuous, automated flow of data. DTs support services such as simulation, automation, and real-time planning [21]. Conversely, within the domain of construction, DTs are frequently associated with a BIM model, thereby constraining their full potential impact [27,28]. The development of the DT within the construction industry is still in its early stages [27]. In order to realise the full benefits of DTs in construction logistics, a shift towards dynamic, real-time integration is required, as well as clarity on the necessary hardware, software, and data infrastructure [29,30,31].

Research aim and objectives: The aim of this paper is to determine how a DT for construction logistics can be designed and technically implemented to address the inefficiencies and integration gaps outlined above, particularly at the construction site. To achieve this aim, the paper pursues three objectives: (1) to analyse existing definitions and applications of DTs in construction; (2) to derive requirements for a DT in construction logistics; and (3) to propose a modular framework, termed ConLogTwin, for the technical realisation of such a DT.

Research question: How can a DT for construction logistics be designed and implemented to provide real-time integration, flexible modularity, and effective process support for construction logistics management?

The remainder of the paper is structured as follows: Section 2 explains the design of the research and the development of the ConLogTwin framework. Section 3 defines the key terms and assesses current practices and research in DT for construction logistics, leading to the identification of framework requirements. Section 5 presents the architecture and data model of ConLogTwin, including its core and service-based extensions. Section 6 demonstrates and evaluates a prototype implementation of the framework in a small-scale case study. Finally, Section 7 summarises the findings and discusses implications and future research directions.

2. Research Design

This paper is conceptual in nature, with the primary objective being the integration of recent research and the development of an integrated framework, named ConLogTwin. The objective of this study is to provide additional value and direction for future research in this field. The approach does not rely on empirical data but follows a structured design methodology appropriate for developing technical solutions in information systems research [32].

As outlined in Section 1, the implementation of a DT in construction logistics necessitates a robust technical concept. In order to address this need, the study employs the ’Design Science Research Methodology for Information Systems’ (DSRM-IS), as proposed by Peffers et al. [33]. This methodology is particularly well-suited for creating and evaluating artifacts—defined as purposeful IT constructs developed to solve identified problems—within complex sociotechnical contexts [34]. The DSRM-IS is a more suitable methodology than empirical, theoretical, or purely engineering approaches for the study in question, due to the fact that it is oriented towards the design and evaluation of innovative solutions within a research context. In contrast to empirical methods, it does not restrict itself to the observation of existing systems, and in contrast to theoretical approaches, it guarantees practical applicability. Compared to agile or engineering design methods, DSRM-IS offers a structured, academically rigorous framework that bridges theory and practice. As such, DSRM-IS is a highly relevant framework for the construction of digital systems such as ConLogTwin, due to its support of iterative design, stakeholder analysis and practical validation.

Furthermore, the methodology incorporates elements from the DT development process outlined by Segovia and Garcia-Alfaro [35], which complement and align with DSRM-IS principles. Based on these foundations, a structured workflow for the development of ConLogTwin was created (Figure 1).

Initially, the problem statement, as presented in Section 1, is formulated. In the following section, the problem’s circumstances are explored and analysed in a literature review. This includes the analysis of the groups involved in construction logistics, the data sources of construction logistics information, and the use cases of a DT for construction logistics. The objectives and requirements for a DT in the context of construction logistics are thus formulated. The development of the ConLogTwin concept is facilitated by these objectives. The technical feasibility of the concept is then verified through a demonstrative implementation, after which the concept is assessed with regard to the previously defined requirements. The development process is characterised by iterative steps, ensuring the attainment of objectives. In the ensuing chapters, the results of the overall process are presented as the ConLogTwin framework.

3. Frame of Reference

3.1. Construction Logistics

3.1.1. Fundamentals

Construction logistics is a specialised area of basic logistics and includes the planning, implementation, coordination and control of material and information flows as part of the execution of a construction project [36]. This is visualised by the ‘6R rule’, according to which the right materials and information should be available at the right time, in the right place, in the right quantity, in the right quality and at the right cost [37]. Construction logistics can be viewed from different perspectives and structured accordingly:

• Conceptual frame
  Günthner & Borrmann [38] define three conceptual levels for analysing construction logistics. At the first level, construction logistics is described by the elementary logistical activities of ‘transport, handling and storage’. The second level also includes the planning, management and control of logistical flows to maximise the availability of materials. At the third level, the horizon expands and the entire cross-company value creation network is considered as a flow system. This is the so-called Construction Supply Chain (CSC).
• Spatial distribution
  Girmscheid et al. [7] divide construction logistics spatially into supply, disposal and construction site logistics. Supply logistics deals with the transport of construction materials to the construction site. Disposal logistics covers the removal of materials and waste from the construction site. Construction site logistics manages the transport and storage of materials within a construction site.
• Functional separation
  Thunberg [39] considers two distinct processes. In this context, the actual planning and building of a structure is described as the construction process, which must be coordinated with the production and delivery of materials to the construction site within the supply chain process.

The CSC is a converging supply chain that exists for a limited period of time. This requires the creation of information and material flows across functional and company boundaries [40]. As a result, a temporary network is created for the exchange of information and goods between the players involved [41]. For this reason, each project has its own so-called construction logistics setup (CLS) [42]. In these CLS various logistics services are implemented in order to coordinate the information and material flows. This modular structure led to the development of logistics service providers (LSPs) [43]. With a few exceptions, the companies that operate as LSPs come from the fields of construction consultancy, material supply or rental of construction equipment. With the establishment of LSPs, additional services have been developed alongside traditional material transport, such as space and container management, waste management, organisation and information, media supply, provision of security services, rental and operation of construction equipment and other services [44]. In the area of organisation and information, the focus is on notification and supply control to ensure an orderly flow of materials to the construction site as well as time slot management for loading zones and means of transport to avoid conflicts on the construction site.

3.1.2. Challenges of the CSC

Methods from traditional supply chain management cannot simply be applied to the CSC, as the latter is strongly characterised by the following industry-specific features [16,38]:

• Individual production;
• Temporary location;
• Highly fragmented industry structure;
• Production in the open air;
• Limited storage;
• Limited freight splitting;
• Short-term and fragmented customer-supplier relationships;
• Construction during planning.

Therefore, Vrijhoef & Koskela [45] proclaim four roles of the construction supply chain management: improving the interface between site activities and the supply chain, improving the supply chain, transferring activities from the site to the supply chain and the integration of site and supply chain.

The CSC bridges a network off-site and on-site between players regularly changing from project to project [10]. However, three groups can be categorised [46]. These are the municipality, the developer and the contractor These groups can be broken down further, as shown in Figure 2.

Furthermore, municipalities started to enforce governance structures for construction logistics to reduce negative impacts such as congestion and interference with neighbouring citizens and businesses. Unfortunately, these governance structures clash with the business models of private actors involved in construction logistics [47].

3.1.3. Data Sources in Construction Logistics

In construction logistics the information from several actors needs to be combined to achieve a holistic delivery planning. Figure 3 provides an overview of key data sources and their associated actors, based on guidance from Suva and the City of London, who outline the essential components of a construction logistics plan [48,49]. The actor in control of the corresponding data source is highlighted according to the colour scheme in Figure 2.

In planning and work preparation, specialised or partial models are created with varying degrees of detail for the individual disciplines—including construction logistics. The level of detail of the construction logistics model is described by the ‘Level of Logistics’ [50]. Depending on the requirements of the project, the overall building model includes geometric, structural, and material data. Alphanumeric information such as reinforcement details or component quantities is added, along with schedule data covering both primary construction activities and secondary logistics processes, like delivery coordination.

Logistical information can be categorised into two main types: product data and process data. Product data includes information such as weight, stackability and packaging, while process data encompasses delivery times and transport aids. This data is generated and maintained in a wide range of formats. Typically, building geometry is stored in the IFC format—a widely adopted industry standard [51]—however, other data, such as supplier catalogues, sensor outputs, and real-time updates from third parties, often exist in both standardised and non-standardised formats. In practice, many sites still rely on traditional 2D plans, further complicating integration.

3.1.4. Requirements for Construction Logistics Management Software

The tools used for planning and controlling construction logistics are heavily dependent on the type of construction site being supplied. There are major differences between linear construction sites such as motorways or railway lines and vertical construction sites such as in building construction or industrial construction. However, what these tools have in common is the aim of efficiently providing the parties involved with the information they need. Figure 4 therefore shows which information is recorded by a typical DMS [12], which requirements are placed on a construction site management system [52] and which information is required to evaluate the performance of construction logistics [11]. For these systems to function effectively, data must be continuously collected, stored and passed on.

3.2. Digital Twin

3.2.1. General Definition

According to Grieves [26], the DT consists of a digital object in the virtual world and a corresponding object in the real world. There are communication links between these two objects. In this sense, Kritzinger et al. [53] differentiate the DT from the digital model and the digital shadow through the bidirectional, automated data flow. Information relating to the real object is therefore stored in the DT. In addition to information about the status, this can also be information about the process, e.g., about the manufacture of the real object. The recorded information can be used to simulate the behaviour of the real object in the virtual world and then send control commands to the real twin based on the results. Kritzinger et al. [53] list the following tasks of the DT:

• Monitor;
• Simulate;
• Predict;
• Diagnose;
• Control.

A DT can also be considered a cyber-physical system. Cyber-physical systems are the connection of embedded systems for monitoring and controlling physical processes using sensors and actuators via communication devices with the global digital networks [54]. They make a decisive contribution to industrial automation and information management. Embedded systems are computers with limited performance that are connected to the environment via sensors and actuators. The hierarchical networking and integration of systems into ever more comprehensive systems is referred to as a ‘system of systems’. The challenge in designing these systems is to replace humans as the regulatory link between the individual components of object, simulation and control. To achieve this, the input data must be filtered and processed accordingly. For example, sensor data should be specifically selected to be used for a simulation, as otherwise a direct association from data source to data sink would lead to an unfiltered flood of simulations.

In order to create a DT, it is necessary to design a suitable data structure, collect and link the required data and develop suitable interfaces for using the DT [55]. For this purpose, a general outline for DTs is established, which presents the different parts of each DT in a five layer architecture [56,57]. The sensing layer gathers data from physical environments using sensors and devices, capturing real-time information. The communication layer transmits this data securely between different system components, ensuring seamless connectivity. The storage layer stores the collected data efficiently, providing easy access for future use and analysis. The analytics layer processes and analyses the data, transforming raw information into actionable insights. Finally, the visualisation layer presents these insights in user-friendly formats, such as dashboards or graphs, enabling informed decision-making.

However, there is currently no precise and uniform definition and description of a DT [58]. In the construction industry, the term DT is closely associated with the term BIM model [27] as the DT of a building usually contains the geometry, structural properties and component information. In addition, maintenance intervals or logistical process properties can supplement the DT.

3.2.2. Requirements of a DT

The successful implementation of a DT in any system requires fulfilling a range of technical, operational, and security criteria. These requirements ensure that the DT accurately represents the physical counterpart while simultaneously providing valuable insights and facilitating efficient management. The evaluation of a DT is informed by the key characteristics defined by Klar et al. [59] and the requirements for DT outlined by Moyne et al. [60]. These characteristics and requirements can be applied as follows:

Firstly, affordability is crucial; DT systems must be cost-effective to be viable in real-world construction projects. Concurrently, these systems must offer sufficient data capacities to manage and process large volumes of real-time and historical data without compromising system performance. Given the sensitive nature of construction data, strong security mechanisms and compliance with data privacy regulations are essential to protect the integrity of information and to foster trust among stakeholders.

To ensure compatibility with various tools and platforms, standardisation plays a key role. This includes using open data formats and communication protocols to achieve interoperability with other systems. Moreover, a DT should be capable of dynamic adaptation, continuously updating itself to reflect real-time changes in the physical environment. This adaptability goes hand in hand with high levels of capability and accuracy in data representation and analysis.

One of the most critical functions of a DT is its ability to generate valuable insights. Whether by discovering inefficiencies, predicting outcomes, or prescribing optimal actions, a DT should actively contribute to decision-making and process optimisation. Additionally, the system must be extensible, i.e., it should be sufficiently flexible to accommodate future upgrades or new data feeds, without compromising maintainability. This is characterised by minimal downtime and low overhead for updates.

Furthermore, data sovereignty must be guaranteed, allowing organisations to retain full control over their data, including where and how it is stored or shared. Finally, to support long-term utility and adaptability, DT components should be designed for reusability and interchangeability, enabling them to be applied across different projects or replaced without significant reconfiguration.

3.2.3. Use Cases of Construction Logistics DT

The development of theoretical use cases of DTs in construction logistics demonstrates their benefit and usability. As part of the ‘Last Mile Delivery Challenge’ research project at TU Braunschweig [61], a series of use cases have been identified for the domains of work preparation, operational logistics, and facility management.

In the area of work preparation, DTs provide support for the visualisation of logistics relationships, the simulation of delivery processes, the integration of supplier data post-contract award, and the conversion of bulk deliveries into cycle-based schedules. These capabilities improve foresight and alignment between planning and execution.

In the context of operational construction logistics, DTs offer tools for real-time monitoring of construction progress, material usage, supply chain status, and sustainability metrics. In addition, support is provided for site logistics through functions such as storage area management, ergonomics monitoring [48], and oversight of autonomous systems. It is a particular requirement for autonomous systems to have accurate spatial models, semantic building data, and live sensor integration [62]. Additional features include security-related monitoring of project spaces to prevent theft or unauthorised access.

In the domain of facility management, DTs enable the structured handover and preparation of logistics data relevant to building operation and maintenance.

While this list is not exhaustive, it highlights the broad range of services a DT must support and the importance of a modular, standardised architecture. Standardised, reusable services not only increase scalability and adaptability but also facilitate continuous improvement and long-term integration across construction logistics workflows [63].

4. Existing Approaches for DTs in Construction Logistics

The logistical data is generally available in existing software systems, but is not linked in the sense of a functional DT. BIM or model-based logistics control lacks performance, as the model is overloaded with all logistics parameters. In addition, there is a lack of suitable BIM software on the part of the logistics stakeholders [64]. DMS systems for delivery planning lack data transfer from planning. CDE platforms are well integrated into BIM software tools and some are even open source. However, they do not enable the integration of sensor data (e.g., Speckle [65]).

Current research is being conducted with the objective of developing data-driven planning and control workflows for the planning and construction of buildings and civil infrastructure [31]. For instance, recent research explores how processes in the construction industry, and in particular construction logistics, can be made more efficient and safer through the use of digital methods. Table 1 briefly describes the DT approaches and analyses them in terms of the technologies and architectures used.

Weber [16], Voigtmann, & Bargstädt [17] and Alvanchi et al. [18] use simulations to analyse logistics strategies and their effects on construction processes. Furthermore, the role of the BIM model to support construction processes is often considered, as it contains the information for the construction processes and can be used for visualisation [66]. In addition, GIS are utilised to enhance the visualisation and monitoring of the supply and disposal logistics of the construction site [13,14,21,22]. These approaches have shown promise in visualising site activities, yet current tools lack the capacity to coordinate logistics dynamically across multiple domains or stakeholders. While they have demonstrated the potential of digital tools to optimise logistics processes, these efforts remain fragmented and often limited to case-specific implementations.

Table 1. Current research regarding construction DT.

Ref.	Description	DT Technology	Architecture
[67,68]	Reference architecture for a semantic DT	Semantic web, ontology	Component-based
[69]	Framework for a city-scale, user-centred DT	Web-based	Layered
[70]	Framework of building-DT for monitoring applications	Web-based	Component-based
[14,71]	Reducing traffic disturbances of construction logistics	Desktop app, simulation	not disclosed
[72]	Modular and interoperable DTs of built assets	Web-based, knowledge graph, ontology	Micro Service-based
[73,74,75]	Monitoring and prediction of the condition of a building	Web-based, structural analysis, BIM	Service-oriented
[76,77,78,79]	Optimisation of transport on- and off-site	Web-based, GPS, robotics, simulation	Service-oriented
[80,81]	Construction progress prediction based on machine data	Web-based, machine telemetry, simulation	Not disclosed
[82]	Delivery management for mobile silos based on a CSC-DT	Web-based, GPS, refilling sensor	Service-oriented
[83]	Safety management of construction processes	Web-based, BIM, simulation	Component-based

Table 1. Current research regarding construction DT.

Ref.	Description	DT Technology	Architecture
[67,68]	Reference architecture for a semantic DT	Semantic web, ontology	Component-based
[69]	Framework for a city-scale, user-centred DT	Web-based	Layered
[70]	Framework of building-DT for monitoring applications	Web-based	Component-based
[14,71]	Reducing traffic disturbances of construction logistics	Desktop app, simulation	not disclosed
[72]	Modular and interoperable DTs of built assets	Web-based, knowledge graph, ontology	Micro Service-based
[73,74,75]	Monitoring and prediction of the condition of a building	Web-based, structural analysis, BIM	Service-oriented
[76,77,78,79]	Optimisation of transport on- and off-site	Web-based, GPS, robotics, simulation	Service-oriented
[80,81]	Construction progress prediction based on machine data	Web-based, machine telemetry, simulation	Not disclosed
[82]	Delivery management for mobile silos based on a CSC-DT	Web-based, GPS, refilling sensor	Service-oriented
[83]	Safety management of construction processes	Web-based, BIM, simulation	Component-based

Other research shows, that the investment in DT has the potential to increase productivity through predictive analytics and minimise the numerous challenges facing the construction industry [84]. Therefore, current research is investigating the technologies used to create DTs and the ecosystem in which these DTs are used. On the one hand, there are studies that deal directly with the architecture and storage technologies for implementing a DT for a construction project [67,68,69,70,72]. On the other hand, DTs are being developed that focus on solving and demonstrating specific problems or use cases [14,75,78,80,82,83].

In research, the development of new technologies has increased research into DT for construction logistics. Nevertheless, current approaches are fragmented, lack a holistic strategy and lifecycle integration [56]. Especially the application of DTs in construction logistics is in nascent stages [58]. The existing approaches lack the flexibility, extensibility and interoperability required for a holistic DT. These limitations stem largely from two core issues: (1) the absence of a technical and data framework spanning all construction logistics phases and stakeholders, and (2) the limited ability of current approaches to interlink heterogeneous data types—such as sensor data, BIM models, scheduling, and operational logistics—in real time. The development of a modular DT framework with the focus on construction logistics is therefore necessary.

5. The ConLogTwin Framework

5.1. Concept

The aim of the ConLogTwin is to integrate the data from the entire construction supply chain into a DT. It should contain all information that is relevant for the planning and control of logistics during the construction of a building. When using this DT, the focus is on construction site logistics. Here, the primary construction processes should be optimally supported by the secondary logistics processes. This means ensuring a smooth flow of materials as close as possible to the installation site without intermediate storage or other waste as well as monitoring the proper disposal or recycling of waste [36]. For better operational planning on the construction site, it is necessary to have an up-to-date overview of incoming material deliveries, stocks stored on the construction site and provision times for materials to be ordered. Above all, the main purpose of the ConLogTwin is to optimise execution processes, reduce manual labour and thus reduce construction logistics costs.

From a holistic perspective, Figure 5 illustrates the relationships between the construction supply chain and its digital representation during execution. Outside the construction site, status data from production and telemetry data from logistics are used to monitor the supply chain. GPS data from traffic is particularly relevant for deliveries to the construction site. Geofencing, i.e., the automated triggering of an action once a geo-localised boundary on the earth’s surface has been exceeded [85], can be used to automate the notification of deliveries to the construction site. GIS are used to visualise the location of deliveries. On the construction site, construction progress is monitored by stationary and mobile camera systems (drones). Noise sensors can also be used for this purpose [23]. Other process data is recorded by IoT devices, e.g., an appropriately equipped access scale, a weather station on the crane, smart cameras and motion sensors to monitor loading zones, telemetry data from means of transport and lifting equipment (crane, construction hoist, industrial trucks) in combination with RFID chips on building components [24], smart pallets, drying sensors in the screed [25] and many more. The digital recording of time worked on a smartphone or tablet by the personnel on the construction site can also contribute to the ConLogTwin process data. BIM is used for the spatial visualisation of information on the construction site.

Figure 6 shows a typical process flow within the ConLogTwin. As the supplier produces and delivers the material to the construction site, the delivery plan gets automatically updated. Status groups, such as the site manager and the LSP, are informed about progress for their scheduling purposes. When the material arrives on-site the LSP gets advised were to unload and store the material. The construction workers and site managers get notified and can search for the materials needed for their next work steps.

To achieve all of this, the data must be semantically linked, summarised and then displayed in a dashboard for specific target groups or made available to other applications via an interface. Therefore, the ConLogTwin should offer appropriate interfaces to record the described and other process data using sensors. In contrast to the Building Information Model, the ConLogTwin is not just a form of data storage, but extends the concept to include a service architecture that enables simpler interaction and additional automated services. In addition, the possibility of integrating autonomous systems turns the DT into a cyber-physical system.

5.2. System Architecture

The ConLogTwin system architecture (Figure 7) is developed based on the requirements described in Section 3.1.4 and Section 3.2.2. The central component of the ConLogTwin is a structured data store that simplifies the filtering and searching of construction logistics data. It is called the ConLogTwin Core. Via an web Application Programming Interface (API) it can be queried and edited. To collect data from the construction supply chain sensors are used to capture real-time information in the sensing layer. This data is transferred via the communication layer, which uses protocols like Message Queuing Telemetry Transport (MQTT) and Hypertext Transfer Protocol Secure (HTTPS), along with web APIs for machine-to-machine communication and integration with other systems. The analytics layer automatically processes and analyses the data using ConLogTwin services, enabling automated decision-making. Finally, the visualisation layer presents valuable insights on a dashboard, providing stakeholders in the construction supply chain with clear, actionable information.

The ConLogTwin architecture can be described using multiple viewpoints to address diverse stakeholder concerns, in line with ISO/IEC/IEEE 42010 [86]. The functional viewpoint (Figure 7) represents the layered architecture, including sensing, communication, analytics, and visualization. The information viewpoint is formalized through the ConLogTwin meta-model (Figure 8), capturing entities such as Component, Package, and Delivery, with semantic links to IFC GUIDs. The deployment viewpoint (Section 6.1) specifies system components—database, object store, web API, and services—implemented as containers connected via a Docker network. The operational viewpoint (Figure 6) illustrates typical sequences, such as supplier geofencing, booking validation, unloading, and inventory updates. Together, these viewpoints provide traceability from stakeholder requirements to system design.

It should be noted, however, that ISO 42010 compliance is currently asserted conceptually through these viewpoint descriptions; no independent verification or artefact-based evaluation has yet been conducted. As such, while the framework adheres to the standard’s principles for modelling architecture from multiple perspectives, its formal compliance has not been externally validated. This limitation frames an area for future work, where independent reviews or formal architectural analysis could strengthen confidence in traceability and completeness.

5.2.1. ConLogTwin Core

The challenge, among other things, is to design a suitable data structure for the DT [55]. In particular, the integration of sensor and supplier data into the developed system poses a complex challenge. To address this, the ConLogTwin Core consists of several data bases, that allow the storage of the vast amounts of data generated in the CSC. This data storage system utilises three databases (Figure 7): The Media DB to store big media files, the Sensor DB to store time series sensor data and the ConLog DB to contain structured CSC data.

For the ConLog DB a special data structure is developed, as the widely used IFC file format does not provide the required capabilities such as real-time data handling and flexible semantic linking of logistics processes [87]. While the ConLog DB builds upon IFC data, it is not a replacement; instead, it remains connected to the IFC model through the globally unique IFC GUID, allowing interoperability with existing BIM tools.

The ConLog DB defines the following five key entities: ‘project’, ‘building’, ‘component’, ‘package’ and ‘delivery’ (Figure 8). These entities are semantically linked. The project forms the overarching container for the data. Within each project, buildings are broken down into components such as walls, columns or façade panels—mirroring the structure of the IFC model. These components are then grouped into packages based on delivery requirements and tied to deliveries that reflect actual logistics processes.

To further illustrate the concept, the ConLogTwin data model ensures complete lineage across all entities. For example, an individual façade panel is uniquely identified by its IFC GUID. This GUID links the panel to the corresponding component entry in the database, which in turn is assigned to a package grouping multiple panels. The package is associated with a specific delivery, and finally, the delivery is connected to a designated storage or installation zone on site. This chain of relationships allows stakeholders to trace any physical object through the entire lifecycle, from its IFC definition to its current logistical status.

Versioning is equally important in maintaining data integrity across planning and field execution. Planning updates (e.g., rescheduling a delivery due to crane availability) and field updates (e.g., a delayed truck arrival) are reconciled using version control rules within the ConLogTwin. Each entity retains a history of changes, enabling conflict resolution through prioritisation policies—for instance, field updates are given precedence when they contradict outdated planning assumptions. This approach ensures that the ConLogTwin consistently reflects the most accurate state of both planned and executed logistics, while still retaining a transparent audit trail for decision-making and accountability.

5.2.2. ConLogTwin Services

The ConLogTwin is supplemented by services that process and analyse the data automatically (Figure 9). Three use cases of such services are described in this paper. The algorithmic underpinnings of these services remain an area for further research and will be addressed in separate publications. Additional use cases can be incorporated into this description as needed, demonstrating the framework’s modularity and extensibility.

• IFC decomposition
  In order to be able to use data from the IFC file format from building planning and work preparation with the data structure developed for ConLogTwin, these files must be converted. The transferred files are deserialised for this purpose and then individual sub-objects are extracted from the building as components and saved individually in the data structure. The semantic information is retained and transferred to the ConLogTwin data structure. Geometric information remains in the original IFC file. The extracted component remains linked to the IFC data structure via the IFC GUID, meaning that a geometric shape or spatial arrangement of the component can also be created for visualisations or three-dimensional evaluations.
• Automated delivery plan
  As part of construction logistics planning, delivery quantities, delivery times and storage locations on the construction site are identified and linked to form a comprehensive logistics plan. The detailed planning of each individual delivery is very labour-intensive and is therefore only used for particularly relevant components or very large projects. To simplify and support this process, a service is to be integrated into ConLogTwin for automated delivery planning. This service develops a suitable delivery schedule based on the identified components and quantities from the building models and the scheduling of the work preparation. Such model-based logistics planning has already been demonstrated by Jaster et al. [88] for drywall construction, where production and storage areas are dimensioned and scheduled using the building model. While advanced dependencies between deliveries and work sequences are not directly modelled in ConLogTwin, automated delivery planning modules can accommodate these dependencies where necessary to align with project-specific workflow requirements.
• Analysing and summarising sensor data (delivery surveillance)
  The process data from the construction site, which is recorded using sensors, must first be processed and aggregated. If this is not already done ‘on the edge’, i.e., by a small computer at the sensor, this must be implemented by a service in ConLogTwin. For example, a service can automate the notification of deliveries using geofencing. By analysing image material from the construction site, the management of storage areas can be supported and the recording of material stocks on the construction site can be automated. A service can also simulate future logistics processes based on the recorded process data and use the results to monitor the schedule.

5.2.3. Data Visualisation

Regarding the requirements of a site management system (Section 3.1.4), an exemplary dashboard has been designed to visualise the collected data and the real-time status of construction logistics (Figure 10). This dashboard serves as a central interface through which various user groups, including project managers, site supervisors, logistics coordinators and suppliers, can monitor and analyse the data to make informed decisions.

Similar to a time-cost progress diagram, this dashboard centrally displays the project status. In terms of the supply chain, the planned production, delivery and installation data on the construction site are compared with the actual data. To this end, the individual components are assigned a specific contribution to the overall project completion, and these contributions accumulate over time. This enables stakeholders to swiftly identify delays or deviations across the supply chain. Another visual component displays planned versus actual storage space utilisation on-site, helping logistics managers ensure that materials do not exceed available space constraints. Additionally, the dashboard provides a preview of upcoming deliveries and the current weather forecast, enabling forward planning and risk mitigation. In this sense, the system supports the integration of external data sources to retrieve information such as weather forecasts or traffic conditions via web APIs. The dashboard also features drill-down functionality, enabling users to access the granular data behind each visualised indicator. For example, users can see which specific components are delayed or which delivery batches are incomplete [89].

Recognizing that different stakeholder groups have varying information needs, the system could be extended with tailored interfaces. For example, a BIM-based visualization could help on-site workers locate material storage areas efficiently. Suppliers might use dedicated interfaces guiding them to designated loading zones and planned storage locations on the construction site to optimize delivery processes and reduce delays. Planners could benefit from detailed views of the logistical workflows on site to better understand and optimize construction logistics. Additionally, GIS-based visualizations could provide site supervisors and supply chain managers with real-time information on material status and location throughout the supply chain. The municipality could be supported by traffic flow visualizations around the construction site, assisting in permitting processes and managing traffic impacts.

The ConLogTwin systems effectively addresses the diverse requirements and perspectives of all involved actors by combining a shared overview dashboard with stakeholder-specific visualization and interaction modules, enhancing coordination and decision-making in construction logistics.

6. Small-Scale Case Study

To demonstrate the feasibility of the ConLogTwin framework, a small-scale case study was conducted using a fictitious renovation project at the institute’s own building L501. Figure 11a shows the BIM model of the building. The project involves renovation during ongoing operations, presenting several logistical challenges: a large multi-storey structure, restricted on-site storage capacity, and materials stored in partially hidden side rooms. These conditions required a smart logistics solution to reduce material search times and to enable continuous monitoring and coordination of construction logistics.

For material tracking, a solution developed by the authors for tracking load carriers (pallets) in multi-storey buildings was applied [90]. The so-called SmartPallet (Figure 11b) is equipped with an IoT sensor box that enables precise indoor localization of pallets within the building. Communication is based on LoRaWAN, with data transmitted via an MQTT bridge to the ConLogTwin, allowing for continuous monitoring of site logistics and automatic updates of material locations.

To support automated logistics scheduling, a simple sequential planning algorithm was implemented. Although basic in nature, this algorithm demonstrates the planning functionality and enables, in combination with pallet tracking data, a comparison between planned (target) and actual logistics status within the ConLogTwin dashboard (Figure 12).

Finally, a smartphone-based Augmented Reality (AR) navigation feature was developed to assist construction personnel in locating stored materials [91]. Using a marker-based AR interface, workers can be guided through the building to the required material location, reducing on-site search times and improving workflow efficiency (Figure 13).

6.1. Implementation

The following subsection describes the implementation in more detail to clarify the technical feasibility. The individual components of the ConLogTwin are organised into separate containers. Docker [92] is utilised for the orchestration of the containers. These containers comprise a database, an object store, a ‘FastAPI’ [93] web API, an ‘IFC decomposition’ service and a ‘delivery planning’ service. This setup allowed for scalable deployment, modular testing, and straightforward integration of IoT data streams, ensuring reliable operation of the demonstrator.

The ConLogTwin Core requires a suitable database solution that is appropriate for the management of both structured logistics data and time-series sensor data. Two options for the database management system were evaluated for the ConLogTwin Core (

Table 2. Comparison of database options for ConLogTwin Core.

Aspect	MongoDB	PostgreSQL
Transactions	Eventual consistency	Full ACID compliance
Scalability	Native horizontal scaling	Vertical scaling
Geospatial	Indexes for point/area queries	Geospatial joins
Time-series	Native time-series collections	TimescaleDB extension
Analytics	Weak for complex aggregations	Mature OLAP ecosystem
Schema	Flexible JSON-like documents	Rigid relational schema
ConLogTwin alignment	High adaptability for evolving project-specific requirements, lightweight IoT integration	Strong transactional and analytical capabilities but less adaptable for dynamic heterogeneous data

): PostgreSQL (including its time-series extension TimescaleDB) and MongoDB [94]. MongoDB offers horizontal scalability, enabling efficient management of large and continuously growing datasets. Its document-oriented and schema-flexible model allows it to accommodate heterogeneous data types without rigid predefined structures, a feature particularly useful for dynamically evolving construction logistics requirements. Conversely, PostgreSQL is valued for its strong ACID compliance, robust support for complex relational queries, and broad adoption in enterprise systems. However, its scalability is predominantly vertical, requiring hardware upgrades for significant performance improvements. TimescaleDB, as an extension of PostgreSQL, improves handling of time-series data, yet retains the underlying limitations of vertical scaling and a stricter schema approach.

The decision to adopt MongoDB was guided by two key factors: (i) the ease of scaling the system horizontally across distributed deployments, and (ii) its ability to flexibly integrate evolving data schemas that reflect the project-specific and real-time nature of construction logistics. This ensures the ConLogTwin can adapt over the long term without requiring rigid schemas or costly redefinition of data models. For handling sensor data, MongoDB supports practical retention strategies through TTL (time-to-live) indexes for automatic deletion of outdated measurements, compaction mechanisms for efficient storage management, and partitioning of collections to ensure scalable performance across large volumes of IoT event streams. The system’s eventual consistency model allows ConLogTwin to achieve high speed and availability, trading off strict real-time synchronization for scalable performance—a suitable balance for construction logistics scenarios where slight delays in data propagation do not compromise operational integrity [95].

The use of alternative data storage methods, such as blockchain [96] and ontology-driven frameworks [97], was also evaluated but later discarded for the prototype stage due to practical limitations in performance, integration effort, and the relative immaturity of such approaches for implementation in live construction logistics scenarios. While ontologies and semantic models offer powerful mechanisms for formalising domain knowledge, their complexity was deemed disproportionate to the immediate goals of ConLogTwin, which emphasise lightweight integration of heterogeneous data streams and real-time usability on construction sites.

Nevertheless, ontologies can become highly valuable in contexts where cross-project reuse, long-term interoperability, and reasoning over policies and compliance requirements are central. For example, semantic enrichment allows project data to be queried for questions such as whether deliveries comply with sustainability regulations, or whether supplier documentation aligns with contractual requirements. Similarly, ontology-driven representations enable alignment between different project phases and organisational silos, reducing redundancy and supporting lifecycle integration.

In the longer term, ConLogTwin could be extended by layering knowledge graphs or Asset Administration Shell (AAS) structures on top of the modular data core, thereby bridging lightweight data models with semantic reasoning capabilities. This hybrid approach would enable both efficient real-time operations and advanced analytical services such as compliance checking, automated decision support, and cross-project benchmarking. Recent work on semantic DTs demonstrates this potential, showing how ontologies can underpin interoperability and reasoning across domains [68,72].

MongoDB [98] is deployed within its own container. It is structured with collections for each entity type in accordance with the concept defined in Section 5.2.1. Alongside this, Alongside this, a MinIO [99] object storage system is used to manage unstructured data—including IFC sub-models, images and other files.

The system’s web API, built with FastAPI v0.120.3 and Python v3.13.0, acts as an interface to other applications (Figure 7). Thus, the corresponding web API container enables to store and retrieve files or data in the aforementioned containers via a web-hosted interface. Additional services, such as the ‘IFC-decomposition’ service, can also be called via this API. An authentication service can be interposed to control access to the ConLogTwin. This interface is also used to integrate sensor data from IoT devices via the MQTT protocol [100]. However, integrating live IoT streams introduces challenges such as network latency, reliability of data transmission, and the need for consistent synchronisation across subsystems—particularly when decisions depend on up-to-the-minute data. These challenges can be mitigated through asynchronous processing and modular service containers that isolate computational loads.

Cloud-based services, so called ConLogTwin Services, are used to process and deliver the requested data via the web API. As an example, the ‘IFC decomposition’ service is also hosted in a container and uses IFCConvert from IFCOpenShell [101] to parse transferred IFC files and create an entity in the database for each component for further processing in the ConLogTwin. Additional services can be easily integrated into this system. For example, a further service for automated logistics planning based on the BIM-model could be implemented in a container and then integrated into the API.

6.2. Qualitative Assessment of the ConLogTwin

To assess the feasibility and potential of the ConLogTwin framework, a structured conceptual review approach is applied. The assessment combines requirements coverage analysis, scenario-based assessment, and risk analysis [102,103]. This ensures that the key specifications set out in the literature review (Section 3) are met.

6.2.1. Requirements Coverage Analysis

Table 3. Requirements coverage by the ConLogTwin framework.

Requirement		ConLogTwin Feature
CSC	Heterogenous data sources	Web-API + flexible data model
	Delivery tracking	IoT-integration + dashboard
	Storage space monitoring	Dashboard + data model entities
	Stakeholder involvement	Web-based dashboard + visualizer
	Work preparation and order planning	ConLogTwin Service ‘Automated Delivery Plan’
DT	Data Capacities	Horizontal scalability of database
	Extensibility	Flexible data model + containerized services (e.g., Automated Delivery Plan)
	Reusability and Interoperability	Web API + flexible data model (MongoDB, IFC link)
	Valuable Insights	ConLogTwin dashboard

links the requirements defined for CSC systems (Section 3.1.4) and DT frameworks (Section 3.2.2) to the components and features of the ConLogTwin framework. This demonstrates the extent to which the proposed architecture addresses stakeholder needs.

6.2.2. Scenario-Based Assessment

The applicability of ConLogTwin is illustrated through representative construction logistics scenarios. These scenarios demonstrate the potential use and behaviour of the framework rather than empirical evaluation, as full-scale field testing is beyond the scope of this architecture-focused study.

Scenario A—Peak delivery day: Multiple suppliers arrive simultaneously. The Automated Delivery Planning service assigns unloading zones and schedules deliveries based on real-time site storage availability and component priorities. The Dashboard visualizes occupancy of storage areas and unloading zones, allowing site managers to monitor and resolve potential conflicts. This scenario illustrates how the DT supports dynamic logistics coordination, which traditional DMS solutions cannot achieve in real time.

Scenario B—Sensor outage: IoT sensors responsible for tracking material locations temporarily stop reporting. Previously ingested sensor data and planned delivery schedules are maintained, allowing operations to continue uninterrupted. Inconsistencies are flagged by the preprocessing module and responsible personnel is notified via the dashboard. This demonstrates how ConLogTwin’s combination of historical planning data and service-oriented modularity enhances resilience and operational continuity during temporary data disruptions.

Scenario C—Late supplier delivery: A scheduled delivery is delayed. The Automated Delivery Planning service dynamically recalculates the delivery schedule, updating downstream dependencies, while project managers and site supervisors are alerted. The Dashboard provides a real-time overview of adjusted delivery sequences and storage allocations. This scenario highlights the framework’s ability to maintain adaptive logistics management under unpredictable conditions, leveraging both real-time monitoring and automated planning services.

These scenarios conceptually demonstrate how specific modules of ConLogTwin address key challenges in construction logistics, such as scheduling conflicts, sensor failures, and delivery delays. While they illustrate the intended behaviour of the framework, no empirical results, performance measurements, or validated outcomes are presented at this stage. Future work will implement these scenarios in pilot studies to quantify performance and evaluate operational effectiveness in real construction environments.

6.2.3. Risk and Limitation Analysis

A structured analysis was conducted, during which key risks were identified and mitigation strategies developed. The results are depicted in

Table 4. Risk and limitation analysis of ConLogTwin.

Risk Category	Limitation	Potential Mitigation
Technical	Lack of real-world performance validation	Pilot deployment with controlled data streams
Organizational	Data sovereignty concerns	Role-based access control, contractual data agreements
Economic	Cost of maintaining containers and APIs	Cloud-hosted shared infrastructure, shared development in trade association
Integration	Compatibility with legacy tools	AAS and ICDD interface implementation, IFC-linked data model

.

The risk and limitation analysis highlights four central areas of concern. Technical risks primarily relate to the absence of empirical validation in real construction environments, which could be mitigated by conducting controlled pilot deployments to generate realistic performance data. Organizational risks revolve around data sovereignty and multi-stakeholder trust, where mitigation depends on implementing role-based access controls and establishing clear contractual agreements for data ownership and sharing. The implemented technologies already provide well-established security mechanisms [104]. Economic risks stem from the potentially high cost of maintaining containerized services and multiple APIs; these could be reduced through shared cloud-hosted infrastructure or cooperative development models at the industry level. Finally, integration risks arise from the challenge of interfacing with existing legacy systems and fragmented tools. Here, the adoption of interoperable standards such as AAS and ICDD, together with the IFC-linked data model, provides a pathway for seamless integration.

Despite these main challenges that have been exposed during the research and development phase of the Conlogtwin prototype, there is potential for the concept to be further refined into a viable product through the implementation of the established strategies.

6.3. Future Quantitative Assessment

Building on the conceptual and prototypical development of the ConLogTwin framework, the next phase of research will focus on its empirical validation on a real-world construction site. A pilot implementation is planned in collaboration with an industry partner who will realise a pilot project as the main contractor with its own construction site personnel and BIM-based planning processes. This setting provides an ideal environment to assess the framework’s interoperability with existing digital workflows and its capacity to support data-driven logistics coordination on active construction sites.

The validation process will proceed in three successive stages. The first stage will focus on technical feasibility, integrating ConLogTwin with the partner’s BIM and DMS to evaluate data ingestion, synchronization, and the responsiveness of the digital twin under real-time conditions. The second stage will involve usability assessments through close collaboration with site managers, logistics coordinators, and construction personnel. Observational studies, guided site inspections, and feedback sessions will provide insights into user interaction, perceived value, and practical integration within established work routines. The third stage will explore economic feasibility, examining how digitalized logistics coordination can improve operational efficiency—such as reduced idle times, optimized delivery sequences, and better utilization of on-site storage areas.

Through this staged approach, the validation will begin with a limited set of stakeholders and progressively expand to include the full project team as system maturity increases. The findings will inform both technical refinements and methodological guidelines for deploying digital twin frameworks in construction logistics. Ultimately, this pilot study aims to provide evidence-based confirmation of ConLogTwin’s benefits and establish a foundation for broader industrial adoption and longitudinal evaluation in subsequent research phases.

7. Conclusions and Further Development

While many existing software tools and research projects fulfil the requirement of collecting data relevant to construction logistics (Section 3.1.4), they typically lack the functional integration and real-time responsiveness that characterise a true DT (Section 3.2.2). Research to date has focused on either technical concepts for isolated applications [56], abstract frameworks that lack practical implementation pathways [46,59], or reference architectures that are missing the perspective of construction logistics [67,68].

The ConLogTwin framework addresses these gaps by offering a technical implementation of a DT for construction logistics built on a highly flexible, modular architecture (

Table 5. Comparison of ConLogTwin with existing approaches.

Aspect	DMS/CDE	Existing DT Architectures	ConLogTwin
Primary focus	Delivery scheduling and document management	Lifecycle asset management, abstract DT reference models	Construction logistics integration and real-time site operations
Architecture	Centralized system, often vendor-specific	High-level reference frameworks, often conceptual	Modular, container-based, open-source reference architecture
Data model	Project-centric, mainly delivery slots and documents	Broad domain ontologies, often complex and abstract	Lightweight five-entity model (project, building, component, package, delivery) tailored for logistics with extensibility
Real-time data	Limited (manual updates, some GPS integration)	Conceptualized but rarely implemented in practice	IoT and sensor integration (MQTT, geofencing, IFC decomposition)
Flexibility/Extensibility	Fixed workflows, limited customisation	Flexible in theory but complex and heavy in practice	Service-oriented, easily extendable via containerised services
Interoperability	Vendor lock-in, limited APIs	Focus on standards (e.g., AAS, ICDD) but low adoption	Open API, IFC-based integration, extendable towards AAS/ICDD
Evaluation maturity	Widely used in practice but fragmented	Conceptual, little practical adoption in construction	Demonstrative prototype, qualitative requirement-based evaluation
Strengths	Proven for delivery slot booking and transparency	Conceptual completeness, cross-domain alignment	Pragmatic, implementable with open technologies, tailored to logistics
Weaknesses	No semantic integration, poor flexibility	Lack of construction logistics perspective, no field validation	Not yet field-tested, qualitative evaluation only

). This architecture allows easy integration of additional services and tools. While the underlying technology itself is not new, the combination of a flexible data model, service-oriented architecture and the focus on construction logistics distinguishes this solution, enabling modular extensions to adapt to new use cases. Using proven technologies enhances the practical applicability and reduces implementation barriers. The scientific contribution lies in the modular integration of these technologies into a coherent reference architecture tailored for construction logistics. This way, a digital logistics setup corresponding to the physical and organisational setup can be created in line with the requirements of a construction project. Proving the flexibility of the framework, services such as the automated IFC file decomposition, delivery planning, and IoT sensor-based monitoring for construction logistics have been described in Section 5.2.2. Through its web API, the ConLogTwin’s data can be integrated into a wide range of software and tools, further enhancing its utility across various construction processes and demonstrating its interoperability. One special feature is the integration of additional logistical parameters into the DT, which opens up new possibilities for further use throughout the entire life cycle of the building. As similar digital frameworks [52], this framework has the potential to significantly improve construction efficiency by reducing interruptions and streamlining operations. Moreover, the collected data can be used to verify the sustainability of a constructed building and assist in its subsequent management [105].

The investment in DT technologies, such as ConLogTwin, offers substantial benefits, including increased productivity through automated planning and monitoring [7,10,13,14], and addresses many of the logistical challenges faced by the construction industry [84]. Policymakers and practitioners are encouraged to adopt these technologies to enhance construction performance and improve logistics management. To this end, the presented approach provides an insight into the practical implementation of a DT for construction logistics.

However, it is important to acknowledge the limitations of this study. The ConLogTwin remains a demonstrative application; its components have yet to be validated in real-world construction projects. Thus, practical suitability, scalability, and long-term performance under operational conditions remain unanswered questions. In particular, the framework’s complexity and associated maintenance efforts must be weighed against its potential benefits. As Janne & Fredriksson [106] argue, meaningful assessment of these trade-offs can only be achieved through pilot implementations in collaboration with industry partners.

A further challenge lies in stakeholder engagement. In order to function effectively, the ConLogTwin requires a high degree of data sharing between project participants, which gives rise to concerns around data sovereignty, access rights, and long-term governance. The allocation of operational responsibilities, such as hosting infrastructure and maintaining APIs, also need to be clearly defined and distributed. Moreover, the integration of systems at the downstream stage of construction—particularly in relation to post-construction trades and facility management—must be addressed to prevent the creation of new data silos [36].

Consequently, future research should be directed towards several key areas. A significant area of research concerns the testing of the ConLogTwin under real conditions, with the objective of gathering empirical evidence of its impact. Another promising line of work involves expanding its analytical capabilities through the integration of AI and predictive analytics. For example, the system could be enhanced with services that detect anomalies in material flows, forecast delivery delays, or recommend optimal storage configurations in real time. This would move the ConLogTwin toward a more autonomous, decision-supportive system—an idea aligned with the concept of cognitive or self-aware DTs [107,108]. Additionally, alternative data architectures such as semantic web technologies or blockchain could be explored to improve data integration, traceability, and security, particularly in multi-stakeholder environments [96].

In conclusion, while the ConLogTwin presents a compelling vision for the future of construction logistics, its practical value will only be realised through continued development, rigorous field testing, and integration with broader industry processes.