# Digital Twins and Road Construction Using Secondary Raw Materials

Authors: Sebastjan Meža; Alenka Mauko Pranjić; Rok Vezočnik; Igor Osmokrović; Stanislav Lenart
Journal: Journal of Advanced Transportation
 (2021)

---

## Abstract

Secondary raw materials (SRMs) tend to be a valuable replacement for finite virgin materials especially since construction works (i.e., building and civil engineering work such as road construction) require vast quantities of raw materials. Using SRM originating from recycling a broad range of inorganic waste materials (e.g., mining waste, different industrial wastes, construction, and demolition waste) has been recognized as a promising, generally more cost-efficient, and environmentally friendly alternative to the exploitation of natural resources. Despite the benefits of using SRM, several challenges need to be addressed before using SRM even more. One of them is the long-term durability and little-known response of construction works built using such alternative materials. In this paper, we present the activities to establish a fully functioning digital twin (DT) of a road constructed using SRM. The first part of the paper is devoted to the theoretical justification of efforts and ways of establishing the monitoring systems, followed by a DT case study where an integrated data environment synthesizing a Building Information Model and monitored data is presented. Although the paper builds upon a small scale, the case study is methodologically designed to allow parallels to be drawn with much larger construction projects.


---

## Body

## 1. Introduction

Recently, information technology (IT) support has been gaining momentum, even in more conservative industries such as the construction sector [1,2]. Facing ever higher requests to build bigger, higher, faster and more efficiently and with less environmental impact, Architectural, Engineering and Construction (AEC) experts attempt to find different means to tackle the challenges that arise with automatization of construction works’ design, construction, use, and reconstruction or demolition [3]. Correspondingly, it is well-documented that the AEC industry is undergoing a significant shift away from using 2D and 3D CAD models toward a more enriched digital data structure in the form of a Building Information Model (BIM) [4–6]. This is a conceptual change, as the final product of design is becoming a semantically defined product. Following this methodology, it is possible to create a digital model of a facility in which both geometric information and nongeometric properties of all the elements are included. The need for managing information in digital environments along the building lifecycle was first recognized by private investors, followed by the European Union Public Procurement Directive [7], encouraging the European Member States to require the use of BIM for publicly funded construction and building projects.Standardization bodies, such as buildingSMART, have made great efforts to mould the data structures into open-source file formats, such as Industry Foundation Classes (IFC) [8], since the standardization is crucial to achieving interoperability among highly specialized tools that engineers use for various analyses. Researchers go hand in hand with software providers to meet the common goal to create a sheer virtual representation and/or simulation of the physical assets of the built environment [5,8]. Henceforth, the long-standing tendency of IT research in AEC to come up with a complete virtual replica of construction projects in the design stage prior to the start of the construction works is being embodied. As ever higher percentages of investors, including government bodies, contractors, and operators, realize the benefits of IT-supported construction, it is safe to say that BIM is becoming more recognized as the industry standard. However, we must not overestimate that the use of IT has reached its full potential solely by wider adoption of BIM [9].Our preliminary literature review indicates that if we split AEC-related activities into two subcategories of buildings and civil engineering projects (i.e., roads, railways tunnels, embankments, etc.), the latter tends to receive more modest IT support [4]. This is especially true for activities that follow the design phase (e.g., progress monitoring, quality control during construction, and monitoring during the operation phase). Moreover, civil engineering projects need constant monitoring and maintenance due to diverse loads and high safety requirements in connection with ageing issues [10,11].


### 1.1. Research Objective and Methodology

The paper is working toward proving the hypothesis that civil engineers can significantly benefit from the digital twinning of secondary raw material- (SRM-) based road construction projects. Methodologically, the research builds on an overview of the current state of IT in civil engineering and, equally importantly, it summarizes the challenges arising from using SRM in road construction, keeping the focus on long-time monitoring.The theoretically identified requirements and challenges are meaningfully examined in an SRM-based road construction project case study. To this end, using a digital twin DT is presented for a simple road designed with extensive use of SRM. Accordingly, the means to assess feasibility, suitability, and sustainability of SRM in civil engineering project based long-term monitoring is being examined.


## 1.1. Research Objective and Methodology

The paper is working toward proving the hypothesis that civil engineers can significantly benefit from the digital twinning of secondary raw material- (SRM-) based road construction projects. Methodologically, the research builds on an overview of the current state of IT in civil engineering and, equally importantly, it summarizes the challenges arising from using SRM in road construction, keeping the focus on long-time monitoring.The theoretically identified requirements and challenges are meaningfully examined in an SRM-based road construction project case study. To this end, using a digital twin DT is presented for a simple road designed with extensive use of SRM. Accordingly, the means to assess feasibility, suitability, and sustainability of SRM in civil engineering project based long-term monitoring is being examined.


## 2. Related Work and Background

From the early history of construction, there has been a need for comprehensive information support of the construction processes. Regardless of the data exchange technology, which has changed throughout history, engineers have strived for the most orderly and structured project documentation possible. Up until recently, the focus was primarily on addressing the technological challenges of design, such as how to most systematically collect and present data before the “first shovel”, especially in light of the optimization of the construction process. These efforts are, of course, justified and still relevant, but in this paper, we focus our attention on the processes that follow the construction itself. We are not only addressing technological questions but also highlighting challenges facing the construction industry from a whole other perspective, that is, the ecological and economic impacts of construction works, especially in terms of the Circular Economy (CE) paradigm.


### 2.1. Construction, Digitalisation, CE, and SRM

Closing material loops through recycling and reusing materials in resource-intensive industries is becoming more and more relevant in the face of increasingly stringent environmental requirements and the need for climate change mitigation in general. Correspondingly, the European Union is increasingly recognizing strengths that coincide with the transition from linear business models to CE [12]. Although extensive efforts to promote the benefits of CE, as well as legislative and financial simulations, are being established, the amount of material being recycled and reused as SRM is far from optimal. This is especially true in traditionally more conservative sectors, such as the construction industry. The main obstacles for implementation are, regulative, cultural, sectoral, and financial—driven mainly by the abundance and low cost of virgin materials [13]. Unfortunately, this coincides with the fact that the construction industry is one of the largest consumers of raw materials. That being said, CE models can be useful, especially for civil engineering projects, where a massive amount of material is needed [14].In Europe, a total of 6,265,212 km of roads existed in 2016 [15]. The total costs of the entire road network were equal to about 184 billion EUR in 2016 with investment costs of ca. 145.5 billion EUR and operational and maintenance costs of 38.3 billion EUR. This is estimated to be 1.2% of the annual GDP in the EU [16]. 226.8 million tonnes of asphalt was produced in 2016 for road construction and rehabilitation [17] and around 0.6 billion tonnes of aggregate [18]. Considering that 12% of all aggregate is currently being recycled and reused and that up to 100% of asphalt could be reclaimed in the EU [17], which in practice is considerable, these numbers show that there is a large potential for decreasing environmental and economic impacts of road construction and civil engineering works in general by using SRM and thus preventing the depletion of natural materials and shortening transport distances by using locally available SRM-based materials. All things considered, the need to use SRM is increasing, and correspondingly, the long-term monitoring of the built environment is becoming more and more relevant.The enormous yet untapped potential for setting circular business cases in the construction industry is being intensively investigated within the EU-founded project named CINDERELA [11]. SRM-based construction products developed in the CINDERELA project successfully replace virgin materials and decrease environmental impacts. Recycled aggregate, i.e., secondary aggregate from recycled construction and demolishing waste, is an excellent material for base and subbase courses, while certain manufactured aggregates, such as recycled Electric Arc Furnace (EAF) slag and reclaimed asphalt, are excellent for surface course asphalt layers (Figure 1). Additionally, there are several other well-known SRM-based materials for road construction and maintenance that can be used, (1) either in the surface course as aggregates (e.g., manufactured aggregate from recycled foundry sand, recycled glass, ladle slag, and recycled crumb rubber) or as a binder (e.g., alternative bitumen from organic waste) or both (i.e., reclaimed asphalt); (2) road-base (e.g., recycled and manufactured aggregate from different waste, reclaimed asphalt), typically chemical or mechanical stabilization is needed to achieve the required load-bearing capacity; and (3) subbase and or embankments (e.g., geotechnical composites) [19]. Using SRM in lower road structure layers is particularly interesting as they are usually the largest in terms of material volume, but this does not omit their uses in other road layers with higher required load-bearing capacities.Figure 1
Typical road layers and type of SRM used.The effort of the CINDERELA project to establish a long-term sustainable business model based on applying SRM-based materials is only one piece of the puzzle. It is equally important to prove that such less-conventional construction materials and structures are safe both environmentally and structurally. It is important to realize that more challenging issues when using SRM are less familiarity with such materials by engineers, especially considering their long-term behaviour. Therefore, with this in mind, it is even more important to carefully collect data on the response of SRM-based construction materials once installed in a real environment.


### 2.2. Digital Twins (DTs) for Road Construction

In the broadest and simplest context, DTs can be defined as a cyber-physical integration of assets, processes, or system for virtual simulations, benchmarking, and checks [20,21]. DTs act as a bridging element between the real and virtual environment in which real-time entity data is collected. They are a sort of artefact; a meeting point or an interface that resides between an “inner” environment, the substance and organization of the artefact itself, and an “outer” environment, the surroundings in which it operates.More specifically, to fit the needs of CE principles in AEC, DTs can be seen as the concept of providing constant access to the digital representation of physical assets, whereby digital data is generated in real-time by sensors that complement the baseline BIM with continuous monitoring of the physical environment. The critical dimensions of data in which a database defining the real environment can be characterized as a DT cannot be clearly defined. The model includes structured geometric and attribute data (material data, chemical and mineralogical composition, strength, etc) as well as unstructured support data in the form of real-time material characteristics sensor readings.When monitoring construction with SRM, where we do not know the exact response to external influences, it is important to monitor possible changes in the geometry (i.e., deformations and displacements), as well as supporting information (e.g., temperature, pressure, or external influences, monitoring of environmental impacts in the form of leaching potential toxic elements, particle, and gas emissions) as presented in Section3. All this information is crucial, primarily to ensure mechanical stability, safety, economy, and environmental impacts and to seek further opportunities for improvements in road construction materials and roads.In the civil engineering domain, much is underway and still in development regarding the practical usability of DTs as systems of support for technical decision-making processes. On one hand, the current version 4.2 of the most commonly used interchangeable BIM format, namely, the IFC, still lacks certain features and functionalities for road construction elements compared to buildings in general [22]. Consequently, the modelling phase still requires a lot of effort, typically involving various software products as well as a lot of manual computer work. Also spanning disciplines of model creation and later maintenance, DTs demand initial close cooperation of both of these areas of expertise.Moreover, civil engineering projects include technically very different entities, which all have to be internally connected (aligned) to provide really valuable information on the transport network level (or its smaller segments). This connectivity not only is limited to the alignment of individual digital models inside a common coordinate frame but also involves the establishment of methodological steps that will define relevant parameters for the transport network as a whole. For any digitized system to be useful for planning future activities, one also has to achieve a high degree of data sharing between different databases [23]. This in itself represents a big challenge.There is an additional step that complicates the scenario: the DTs, by definition, must contain up-to-date information on the current state of the road in question. This can only be achieved by including data from different monitoring sensors (see Section4). How this sensor data is distilled down to the BIM and its parts is still an open question, especially because substantial amounts of sensor data may be involved, some with high data acquisition rates. Two possible ways to include sensor data are as follows:(i)
To add separate sensor data elements to the already existing BIM(ii)
To assign sensors results to corresponding BIM element propertiesIn both cases, the initial step would involve preprocessing the sensor data flow and estimating vital measurement parameters to avoid oversaturating the BIM.


## 2.1. Construction, Digitalisation, CE, and SRM

Closing material loops through recycling and reusing materials in resource-intensive industries is becoming more and more relevant in the face of increasingly stringent environmental requirements and the need for climate change mitigation in general. Correspondingly, the European Union is increasingly recognizing strengths that coincide with the transition from linear business models to CE [12]. Although extensive efforts to promote the benefits of CE, as well as legislative and financial simulations, are being established, the amount of material being recycled and reused as SRM is far from optimal. This is especially true in traditionally more conservative sectors, such as the construction industry. The main obstacles for implementation are, regulative, cultural, sectoral, and financial—driven mainly by the abundance and low cost of virgin materials [13]. Unfortunately, this coincides with the fact that the construction industry is one of the largest consumers of raw materials. That being said, CE models can be useful, especially for civil engineering projects, where a massive amount of material is needed [14].In Europe, a total of 6,265,212 km of roads existed in 2016 [15]. The total costs of the entire road network were equal to about 184 billion EUR in 2016 with investment costs of ca. 145.5 billion EUR and operational and maintenance costs of 38.3 billion EUR. This is estimated to be 1.2% of the annual GDP in the EU [16]. 226.8 million tonnes of asphalt was produced in 2016 for road construction and rehabilitation [17] and around 0.6 billion tonnes of aggregate [18]. Considering that 12% of all aggregate is currently being recycled and reused and that up to 100% of asphalt could be reclaimed in the EU [17], which in practice is considerable, these numbers show that there is a large potential for decreasing environmental and economic impacts of road construction and civil engineering works in general by using SRM and thus preventing the depletion of natural materials and shortening transport distances by using locally available SRM-based materials. All things considered, the need to use SRM is increasing, and correspondingly, the long-term monitoring of the built environment is becoming more and more relevant.The enormous yet untapped potential for setting circular business cases in the construction industry is being intensively investigated within the EU-founded project named CINDERELA [11]. SRM-based construction products developed in the CINDERELA project successfully replace virgin materials and decrease environmental impacts. Recycled aggregate, i.e., secondary aggregate from recycled construction and demolishing waste, is an excellent material for base and subbase courses, while certain manufactured aggregates, such as recycled Electric Arc Furnace (EAF) slag and reclaimed asphalt, are excellent for surface course asphalt layers (Figure 1). Additionally, there are several other well-known SRM-based materials for road construction and maintenance that can be used, (1) either in the surface course as aggregates (e.g., manufactured aggregate from recycled foundry sand, recycled glass, ladle slag, and recycled crumb rubber) or as a binder (e.g., alternative bitumen from organic waste) or both (i.e., reclaimed asphalt); (2) road-base (e.g., recycled and manufactured aggregate from different waste, reclaimed asphalt), typically chemical or mechanical stabilization is needed to achieve the required load-bearing capacity; and (3) subbase and or embankments (e.g., geotechnical composites) [19]. Using SRM in lower road structure layers is particularly interesting as they are usually the largest in terms of material volume, but this does not omit their uses in other road layers with higher required load-bearing capacities.Figure 1
Typical road layers and type of SRM used.The effort of the CINDERELA project to establish a long-term sustainable business model based on applying SRM-based materials is only one piece of the puzzle. It is equally important to prove that such less-conventional construction materials and structures are safe both environmentally and structurally. It is important to realize that more challenging issues when using SRM are less familiarity with such materials by engineers, especially considering their long-term behaviour. Therefore, with this in mind, it is even more important to carefully collect data on the response of SRM-based construction materials once installed in a real environment.


## 2.2. Digital Twins (DTs) for Road Construction

In the broadest and simplest context, DTs can be defined as a cyber-physical integration of assets, processes, or system for virtual simulations, benchmarking, and checks [20,21]. DTs act as a bridging element between the real and virtual environment in which real-time entity data is collected. They are a sort of artefact; a meeting point or an interface that resides between an “inner” environment, the substance and organization of the artefact itself, and an “outer” environment, the surroundings in which it operates.More specifically, to fit the needs of CE principles in AEC, DTs can be seen as the concept of providing constant access to the digital representation of physical assets, whereby digital data is generated in real-time by sensors that complement the baseline BIM with continuous monitoring of the physical environment. The critical dimensions of data in which a database defining the real environment can be characterized as a DT cannot be clearly defined. The model includes structured geometric and attribute data (material data, chemical and mineralogical composition, strength, etc) as well as unstructured support data in the form of real-time material characteristics sensor readings.When monitoring construction with SRM, where we do not know the exact response to external influences, it is important to monitor possible changes in the geometry (i.e., deformations and displacements), as well as supporting information (e.g., temperature, pressure, or external influences, monitoring of environmental impacts in the form of leaching potential toxic elements, particle, and gas emissions) as presented in Section3. All this information is crucial, primarily to ensure mechanical stability, safety, economy, and environmental impacts and to seek further opportunities for improvements in road construction materials and roads.In the civil engineering domain, much is underway and still in development regarding the practical usability of DTs as systems of support for technical decision-making processes. On one hand, the current version 4.2 of the most commonly used interchangeable BIM format, namely, the IFC, still lacks certain features and functionalities for road construction elements compared to buildings in general [22]. Consequently, the modelling phase still requires a lot of effort, typically involving various software products as well as a lot of manual computer work. Also spanning disciplines of model creation and later maintenance, DTs demand initial close cooperation of both of these areas of expertise.Moreover, civil engineering projects include technically very different entities, which all have to be internally connected (aligned) to provide really valuable information on the transport network level (or its smaller segments). This connectivity not only is limited to the alignment of individual digital models inside a common coordinate frame but also involves the establishment of methodological steps that will define relevant parameters for the transport network as a whole. For any digitized system to be useful for planning future activities, one also has to achieve a high degree of data sharing between different databases [23]. This in itself represents a big challenge.There is an additional step that complicates the scenario: the DTs, by definition, must contain up-to-date information on the current state of the road in question. This can only be achieved by including data from different monitoring sensors (see Section4). How this sensor data is distilled down to the BIM and its parts is still an open question, especially because substantial amounts of sensor data may be involved, some with high data acquisition rates. Two possible ways to include sensor data are as follows:(i)
To add separate sensor data elements to the already existing BIM(ii)
To assign sensors results to corresponding BIM element propertiesIn both cases, the initial step would involve preprocessing the sensor data flow and estimating vital measurement parameters to avoid oversaturating the BIM.


## 3. Sensing in Civil Engineering

Detailed knowledge and understanding of the condition of physical components of transport infrastructure are essential for undisturbed transport of people and goods and thus for every person’s well-being. Some recent attempts managed to integrate structural health monitoring (SHM) data into BIM to some extent [24,25]. Though this kind of approach is particularly relevant for bridges, tunnels, and retaining structures, one should note that sensing/geotechnical monitoring in road construction projects is equally important [26]. It is provided by measuring and monitoring surface movements, subsurface deformations, in-situ earth and pore pressures, stresses on structural members [27], etc. The design data combined with well-organized continuous monitoring data and its assessment can support the formation of DTs, enabling its efficient whole-life digital-based management support [28].


### 3.1. Progress Monitoring

Effective construction progress monitoring aims to allow identification of time and cost deviations in a very early stage, and it enables implementing corrective actions. It is essential in the construction phase to detect the as-planned components in as-built data [29]. Automated detection of these can enable effective decisions regarding construction progress. It is based on two main pieces of information, (1) the plan and (2) measurements of the actual progress. However, for effective digital representation of the physical and functional characteristics of assets, not only does geometry and its progress during construction matter but the quality control of in-built materials and their characteristics are also essential.


#### 3.1.1. Sensing Geometrical Properties

Vick and Brilakis [29] distinguish a nonspatial and spatial type of geometry progress monitoring. As the nonspatial monitoring relies heavily on manual data collection processes, such as visual inspections, checklists, and daily/weekly reports, it cannot enable automated processes [29]. It is also time-consuming and labour-intensive and includes subjective assessments. Such an approach normally demands a lot of coordination effort and also involves significant error rates [30].Spatial geometry monitoring, if simple handheld tape measures are excluded, is based on highly accurate methods including Total Stations, Global Navigation Satellite System receivers, Light Detection and Ranging (LiDAR) scanners, and Photogrammetry, briefly compared in [29]. Detection performance generally depends on position accuracy and point cloud density or image resolution. While point cloud processing enables the recognition of three-dimensional geometry (Figure 2), and thus construction progress, image processing enables construction material identification. Their combination leads to truly automated progress monitoring [31].Figure 2
Typical results from geometry monitoring. Point-clouds obtained by terrestrial LiDAR enables automatic generation of a comparison between design requirements and construction results and its visualization.


#### 3.1.2. Materials Characteristics

Besides precise geometry data, complete digital representation of DTs must also include accurate information about installed materials and characteristics of single elements forming the asset, e.g., road, where one deals with various pavement layers such as the subbase course, base course, and surface course [32]. A 4D BIM-based construction quality model ensures information consistency from design through various construction phases [33].In the case of pavement construction, quality inspection must be scheduled immediately after the completion of individual layers. Development of mechanistic-empirical pavement design methods demands measurements of performance-related soil properties during the earthwork construction [34]. Thus, required BIM component (e.g., road embankment-unbound bearing layer) characteristics must include data on the type of installed material, gradation curve, and in-situ measured performance characteristics, such as moisture content, density, and stiffness. Location-spot sensing tools (e.g., light-weight deflectometer, nuclear density gauge, loading plates, and dynamic cone penetrometer) can be used to determine characteristics. Modern rollers can be equipped with sensors for real-time monitoring of the compaction, commonly known as continuous compaction control (CCC) [35]. Their advantage is the possession of continuous material characteristics. Figure 3 presents a result of such measurements, clearly indicating locations with less compacted soil.Figure 3
Compaction process of an unbound bearing layer can be visualized by CCC measurements. The evaluation process is described in detail in [36].


### 3.2. Maintenance Monitoring

Different parameters describing the condition of a geotechnical asset might be monitored after the civil engineering asset construction completion. Such monitoring, also named Structural Health Monitoring (SHM), is currently aimed to continuously monitor (Figure4) the performance of an asset with a real-time assessment to provide the so-called proactive monitoring. Proactive means that it enables an in-time reaction to asset response discrepancies and continuous care for the good condition of the asset. Existing assets are monitored to determine if and when remedial measures will be required.Figure 4
Continuous monitoring of moisture and temperature on the local road to detect negative effects of freezing.Smethurst et al. reviewed the role of instrumentation and monitoring, the instrumentation typically installed and parameters measured, focused mainly on slopes [26]. The importance of the initial design and set up of the instrumentation and monitoring scheme for the monitoring aims achievement is pointed out. Therefore, successful maintenance monitoring needs to be continuous, nearly real-time (depends on the parameter monitored), reliable, and with clear criteria for decisions [37].Embedded sensors within the built environment are a rich source of information for efficient maintenance of assets. A range of new monitoring technologies and sensors are being developed recently and new ones are introduced constantly. Besides conventional techniques such as piezometers, settlement plates, strain meters, stress cells, and pressure pads [38,39], optical fibres and remote sensing technologies seem most promising. The common goal of all emerging sensing technologies is to cost-effectively achieve maximum data rates of high-resolution data to enable automated monitoring and, therefore, greater lifespan for instrumentation [26], all to reach an extension of service life.


### 3.3. Technologies for Whole-Life Monitoring

Emerging sensing technologies (e.g., satellite imagery, robotic inspections using an unmanned aerial vehicle (UAV), energy harvesting for continuous monitoring, wireless sensor network, distributed fibre-optics sensors, and low power miniature sensors) can be suitable to monitor particular characteristics and detect any anomalies or deterioration issues. Furthermore, BIM and the Internet of Things (IoT) provide additional tools for a comprehensive view of the status of build assets and improve the efficiency of information use [40,41]. Using the mentioned novel technologies enables the formation of an optimal framework for whole-life performance management [11], the practical application of which is also a subject of research presented within this paper.


## 3.1. Progress Monitoring

Effective construction progress monitoring aims to allow identification of time and cost deviations in a very early stage, and it enables implementing corrective actions. It is essential in the construction phase to detect the as-planned components in as-built data [29]. Automated detection of these can enable effective decisions regarding construction progress. It is based on two main pieces of information, (1) the plan and (2) measurements of the actual progress. However, for effective digital representation of the physical and functional characteristics of assets, not only does geometry and its progress during construction matter but the quality control of in-built materials and their characteristics are also essential.


### 3.1.1. Sensing Geometrical Properties

Vick and Brilakis [29] distinguish a nonspatial and spatial type of geometry progress monitoring. As the nonspatial monitoring relies heavily on manual data collection processes, such as visual inspections, checklists, and daily/weekly reports, it cannot enable automated processes [29]. It is also time-consuming and labour-intensive and includes subjective assessments. Such an approach normally demands a lot of coordination effort and also involves significant error rates [30].Spatial geometry monitoring, if simple handheld tape measures are excluded, is based on highly accurate methods including Total Stations, Global Navigation Satellite System receivers, Light Detection and Ranging (LiDAR) scanners, and Photogrammetry, briefly compared in [29]. Detection performance generally depends on position accuracy and point cloud density or image resolution. While point cloud processing enables the recognition of three-dimensional geometry (Figure 2), and thus construction progress, image processing enables construction material identification. Their combination leads to truly automated progress monitoring [31].Figure 2
Typical results from geometry monitoring. Point-clouds obtained by terrestrial LiDAR enables automatic generation of a comparison between design requirements and construction results and its visualization.


### 3.1.2. Materials Characteristics

Besides precise geometry data, complete digital representation of DTs must also include accurate information about installed materials and characteristics of single elements forming the asset, e.g., road, where one deals with various pavement layers such as the subbase course, base course, and surface course [32]. A 4D BIM-based construction quality model ensures information consistency from design through various construction phases [33].In the case of pavement construction, quality inspection must be scheduled immediately after the completion of individual layers. Development of mechanistic-empirical pavement design methods demands measurements of performance-related soil properties during the earthwork construction [34]. Thus, required BIM component (e.g., road embankment-unbound bearing layer) characteristics must include data on the type of installed material, gradation curve, and in-situ measured performance characteristics, such as moisture content, density, and stiffness. Location-spot sensing tools (e.g., light-weight deflectometer, nuclear density gauge, loading plates, and dynamic cone penetrometer) can be used to determine characteristics. Modern rollers can be equipped with sensors for real-time monitoring of the compaction, commonly known as continuous compaction control (CCC) [35]. Their advantage is the possession of continuous material characteristics. Figure 3 presents a result of such measurements, clearly indicating locations with less compacted soil.Figure 3
Compaction process of an unbound bearing layer can be visualized by CCC measurements. The evaluation process is described in detail in [36].


## 3.1.1. Sensing Geometrical Properties

Vick and Brilakis [29] distinguish a nonspatial and spatial type of geometry progress monitoring. As the nonspatial monitoring relies heavily on manual data collection processes, such as visual inspections, checklists, and daily/weekly reports, it cannot enable automated processes [29]. It is also time-consuming and labour-intensive and includes subjective assessments. Such an approach normally demands a lot of coordination effort and also involves significant error rates [30].Spatial geometry monitoring, if simple handheld tape measures are excluded, is based on highly accurate methods including Total Stations, Global Navigation Satellite System receivers, Light Detection and Ranging (LiDAR) scanners, and Photogrammetry, briefly compared in [29]. Detection performance generally depends on position accuracy and point cloud density or image resolution. While point cloud processing enables the recognition of three-dimensional geometry (Figure 2), and thus construction progress, image processing enables construction material identification. Their combination leads to truly automated progress monitoring [31].Figure 2
Typical results from geometry monitoring. Point-clouds obtained by terrestrial LiDAR enables automatic generation of a comparison between design requirements and construction results and its visualization.


## 3.1.2. Materials Characteristics

Besides precise geometry data, complete digital representation of DTs must also include accurate information about installed materials and characteristics of single elements forming the asset, e.g., road, where one deals with various pavement layers such as the subbase course, base course, and surface course [32]. A 4D BIM-based construction quality model ensures information consistency from design through various construction phases [33].In the case of pavement construction, quality inspection must be scheduled immediately after the completion of individual layers. Development of mechanistic-empirical pavement design methods demands measurements of performance-related soil properties during the earthwork construction [34]. Thus, required BIM component (e.g., road embankment-unbound bearing layer) characteristics must include data on the type of installed material, gradation curve, and in-situ measured performance characteristics, such as moisture content, density, and stiffness. Location-spot sensing tools (e.g., light-weight deflectometer, nuclear density gauge, loading plates, and dynamic cone penetrometer) can be used to determine characteristics. Modern rollers can be equipped with sensors for real-time monitoring of the compaction, commonly known as continuous compaction control (CCC) [35]. Their advantage is the possession of continuous material characteristics. Figure 3 presents a result of such measurements, clearly indicating locations with less compacted soil.Figure 3
Compaction process of an unbound bearing layer can be visualized by CCC measurements. The evaluation process is described in detail in [36].


## 3.2. Maintenance Monitoring

Different parameters describing the condition of a geotechnical asset might be monitored after the civil engineering asset construction completion. Such monitoring, also named Structural Health Monitoring (SHM), is currently aimed to continuously monitor (Figure4) the performance of an asset with a real-time assessment to provide the so-called proactive monitoring. Proactive means that it enables an in-time reaction to asset response discrepancies and continuous care for the good condition of the asset. Existing assets are monitored to determine if and when remedial measures will be required.Figure 4
Continuous monitoring of moisture and temperature on the local road to detect negative effects of freezing.Smethurst et al. reviewed the role of instrumentation and monitoring, the instrumentation typically installed and parameters measured, focused mainly on slopes [26]. The importance of the initial design and set up of the instrumentation and monitoring scheme for the monitoring aims achievement is pointed out. Therefore, successful maintenance monitoring needs to be continuous, nearly real-time (depends on the parameter monitored), reliable, and with clear criteria for decisions [37].Embedded sensors within the built environment are a rich source of information for efficient maintenance of assets. A range of new monitoring technologies and sensors are being developed recently and new ones are introduced constantly. Besides conventional techniques such as piezometers, settlement plates, strain meters, stress cells, and pressure pads [38,39], optical fibres and remote sensing technologies seem most promising. The common goal of all emerging sensing technologies is to cost-effectively achieve maximum data rates of high-resolution data to enable automated monitoring and, therefore, greater lifespan for instrumentation [26], all to reach an extension of service life.


## 3.3. Technologies for Whole-Life Monitoring

Emerging sensing technologies (e.g., satellite imagery, robotic inspections using an unmanned aerial vehicle (UAV), energy harvesting for continuous monitoring, wireless sensor network, distributed fibre-optics sensors, and low power miniature sensors) can be suitable to monitor particular characteristics and detect any anomalies or deterioration issues. Furthermore, BIM and the Internet of Things (IoT) provide additional tools for a comprehensive view of the status of build assets and improve the efficiency of information use [40,41]. Using the mentioned novel technologies enables the formation of an optimal framework for whole-life performance management [11], the practical application of which is also a subject of research presented within this paper.


## 4. Monitoring Data Representations

Many classification schemes exist with respect to the kinds of sensors available and their mode of operation (e.g., contact sensors versus remote sensing instruments). Most sensors, however, are of local character, which means they measure a particular physical or geometric quantity in a particular location (or are located in a certain location for safety and security purposes). Hence, from this perspective, they could be included in a 3D environment using point-like objects. Furthermore, some sensors could be regarded as more line-like or network-like. Finally, one must also consider sensors that produce outputs of a surface-wise character, much like polygons are used in 2D GIS for representing area-like phenomena.


### 4.1. Data-Based Visualization

The three presented visualization types were established as part of the ongoing development within the ASSETS4RAIL project aimed at integrating sensor data into the existing IFC infrastructure [42,43].


#### 4.1.1. Point-Type Sensor Data

The IFC format contains an established list of predefined sensor types that all fall into this category, e.g., smoke, temperature, or humidity sensors. In other words, the predefined sensors all represent point-type sensors that can be visualized within a BIM using various generic or custom-made 3D elements. Any such sensor is local; therefore, a point-like representation seems justifiable. For different sensor types, different graphical elements should exist similar to the idea of establishing standardized cartographic schemes in GIS. Promoting standardized graphical elements for any sensor type should be regarded as a positive initiative since BIM projects usually span many different professions involving a lot of participants. Some sensor vendors already provide digital replicas of their products (along with the list of predefined properties) in specific software formats, e.g., Revit.


#### 4.1.2. Network-Type Sensor Data

Network-type sensors can be considered multiple sensors working as a single group with each sensor having the same internal characteristics or properties. They comprise a series of point-type sensors connected into a larger entity, thus covering more space and, therefore, enabling a denser sampling of a particular measuring quantity. The form or shape of this network can be different, as can the number of nodes it contains (i.e., point-type sensors). Examples of this kind of sensor include optical fibre cable or tape extensometers.


#### 4.1.3. Surface-Type Sensor Data

The third and final sensor representation group includes sensors that produce a surface-wise coverage of measurements of the surface under investigation. Most of these types of sensors operate using different remote-sensing principles to establish a 2D image (2D map) of the surface and its sections. The challenges of visualizing the outcomes of these sensors in a BIM environment (constructed on IFC format specifications) are significant since the high density of measurement coverage coming from these sensors leaves little space for generalization.One way of representing such 2D maps would be to texturize the BIM surfaces involved in the monitoring process. However, this turns out to be cumbersome within the available IFC infrastructure. Even more so, when transferring BIM from one software platform to another, these 2D maps would have to be transferred as well. The BIM exchange process would, therefore, be much more complex. Moreover, not all BIM software platforms support surface texturing anyway, which is yet another reason why this representation option seems less favourable.Another possibility for integrating this kind of dataset into the BIM environment is to consider them as external links of the corresponding BIM elements (or element parts when substructure of BIM element is available or prepared during the modelling phase). These external links can be in the form of basically any file type, e.g. raster images and PDF files. By following this approach, the links are added into the pre-existing BIM element property lists. Examples of surface type datasets include thermal images, LIDAR displacement maps, or ground-penetrating radar images.


### 4.2. Alternative Sensor Data Representation Approach

In all three representation models described so-far, the sensor infrastructure with its datasets is added as a separate layer to the already existing BIM. This means adding sensor elements (with corresponding outputs) to the model or preparing the BIM so that it can accommodate even surface-wise sensor technologies. These three approaches may all become somewhat disadvantageous in the following cases:(i)
A large number of sensors get involved (or large number of BIM elements containing substructure, i. e., surface patches)(ii)
The sensors operate autonomously with near real-time measurement readingsIn such cases, the BIM may become an oversaturated repository of elements representing point- or network-type sensors or surface patches (based on division resolution). The SHM analysis and forecast could become even more difficult, complex, and laborious if the sensor data integration rate into the BIM gets higher and higher.To avoid this scenario, the alternative approach would be to avoid adding sensors as a separate layer group but to include only their output (i.e., sensor representative values) directly into the property sets of the already existing BIM elements. Once these individual sensor representative values are stored for each BIM element, some kind of performance indicators (PI) could be calculated for each existing element. These individual element PIs could further be used to estimate key performance indicators (KPI) for the entire structure (e.g., road). In this scenario, the best way would probably be to have a two-level structure:(i)
A general level (for the BIM as a whole)(ii)
An individual BIM element levelAt the general level, the estimated KPIs would cover aspects such as safety, reliability, functionality, and economics. On the local element level, the PIs would be more closely connected to sensor results so that in case of some kind of malfunctioning, the problems could be isolated and resolved faster. Following this scenario, the direct visualization of any larger number of sensor datasets could completely be avoided with colour-coding simply indicating which BIM elements are potentially problematic from the sensor measurement perspective.The methodologies for calculating KPIs for various civil engineering structures are inherently somewhat different due to the character of these structures themselves. However, in the future, with BIM also covering the monitoring phase of the structure’s lifecycle and including many different sensors, such an approach would be more than welcome. This way, the sensor data aspect and the engineering interpretation of this data are separated, which leaves more space for fine-tuning both these aspects during the sensor-to-BIM implementation phase.Several researchers defined (K) PIs for the purpose of a civil engineering structure performance assessment (e.g., [44, 45]), while at the same time, examples of the actual implementation of (K) PI schemes into the BIM/IFC data structure are difficult to find. As researchers already successfully demonstrated the integration of sensor data and BIM ([46, 47]), the introduction of performance indicators into the IFC format can be expected in the foreseeable future.


## 4.1. Data-Based Visualization

The three presented visualization types were established as part of the ongoing development within the ASSETS4RAIL project aimed at integrating sensor data into the existing IFC infrastructure [42,43].


### 4.1.1. Point-Type Sensor Data

The IFC format contains an established list of predefined sensor types that all fall into this category, e.g., smoke, temperature, or humidity sensors. In other words, the predefined sensors all represent point-type sensors that can be visualized within a BIM using various generic or custom-made 3D elements. Any such sensor is local; therefore, a point-like representation seems justifiable. For different sensor types, different graphical elements should exist similar to the idea of establishing standardized cartographic schemes in GIS. Promoting standardized graphical elements for any sensor type should be regarded as a positive initiative since BIM projects usually span many different professions involving a lot of participants. Some sensor vendors already provide digital replicas of their products (along with the list of predefined properties) in specific software formats, e.g., Revit.


### 4.1.2. Network-Type Sensor Data

Network-type sensors can be considered multiple sensors working as a single group with each sensor having the same internal characteristics or properties. They comprise a series of point-type sensors connected into a larger entity, thus covering more space and, therefore, enabling a denser sampling of a particular measuring quantity. The form or shape of this network can be different, as can the number of nodes it contains (i.e., point-type sensors). Examples of this kind of sensor include optical fibre cable or tape extensometers.


### 4.1.3. Surface-Type Sensor Data

The third and final sensor representation group includes sensors that produce a surface-wise coverage of measurements of the surface under investigation. Most of these types of sensors operate using different remote-sensing principles to establish a 2D image (2D map) of the surface and its sections. The challenges of visualizing the outcomes of these sensors in a BIM environment (constructed on IFC format specifications) are significant since the high density of measurement coverage coming from these sensors leaves little space for generalization.One way of representing such 2D maps would be to texturize the BIM surfaces involved in the monitoring process. However, this turns out to be cumbersome within the available IFC infrastructure. Even more so, when transferring BIM from one software platform to another, these 2D maps would have to be transferred as well. The BIM exchange process would, therefore, be much more complex. Moreover, not all BIM software platforms support surface texturing anyway, which is yet another reason why this representation option seems less favourable.Another possibility for integrating this kind of dataset into the BIM environment is to consider them as external links of the corresponding BIM elements (or element parts when substructure of BIM element is available or prepared during the modelling phase). These external links can be in the form of basically any file type, e.g. raster images and PDF files. By following this approach, the links are added into the pre-existing BIM element property lists. Examples of surface type datasets include thermal images, LIDAR displacement maps, or ground-penetrating radar images.


## 4.1.1. Point-Type Sensor Data

The IFC format contains an established list of predefined sensor types that all fall into this category, e.g., smoke, temperature, or humidity sensors. In other words, the predefined sensors all represent point-type sensors that can be visualized within a BIM using various generic or custom-made 3D elements. Any such sensor is local; therefore, a point-like representation seems justifiable. For different sensor types, different graphical elements should exist similar to the idea of establishing standardized cartographic schemes in GIS. Promoting standardized graphical elements for any sensor type should be regarded as a positive initiative since BIM projects usually span many different professions involving a lot of participants. Some sensor vendors already provide digital replicas of their products (along with the list of predefined properties) in specific software formats, e.g., Revit.


## 4.1.2. Network-Type Sensor Data

Network-type sensors can be considered multiple sensors working as a single group with each sensor having the same internal characteristics or properties. They comprise a series of point-type sensors connected into a larger entity, thus covering more space and, therefore, enabling a denser sampling of a particular measuring quantity. The form or shape of this network can be different, as can the number of nodes it contains (i.e., point-type sensors). Examples of this kind of sensor include optical fibre cable or tape extensometers.


## 4.1.3. Surface-Type Sensor Data

The third and final sensor representation group includes sensors that produce a surface-wise coverage of measurements of the surface under investigation. Most of these types of sensors operate using different remote-sensing principles to establish a 2D image (2D map) of the surface and its sections. The challenges of visualizing the outcomes of these sensors in a BIM environment (constructed on IFC format specifications) are significant since the high density of measurement coverage coming from these sensors leaves little space for generalization.One way of representing such 2D maps would be to texturize the BIM surfaces involved in the monitoring process. However, this turns out to be cumbersome within the available IFC infrastructure. Even more so, when transferring BIM from one software platform to another, these 2D maps would have to be transferred as well. The BIM exchange process would, therefore, be much more complex. Moreover, not all BIM software platforms support surface texturing anyway, which is yet another reason why this representation option seems less favourable.Another possibility for integrating this kind of dataset into the BIM environment is to consider them as external links of the corresponding BIM elements (or element parts when substructure of BIM element is available or prepared during the modelling phase). These external links can be in the form of basically any file type, e.g. raster images and PDF files. By following this approach, the links are added into the pre-existing BIM element property lists. Examples of surface type datasets include thermal images, LIDAR displacement maps, or ground-penetrating radar images.


## 4.2. Alternative Sensor Data Representation Approach

In all three representation models described so-far, the sensor infrastructure with its datasets is added as a separate layer to the already existing BIM. This means adding sensor elements (with corresponding outputs) to the model or preparing the BIM so that it can accommodate even surface-wise sensor technologies. These three approaches may all become somewhat disadvantageous in the following cases:(i)
A large number of sensors get involved (or large number of BIM elements containing substructure, i. e., surface patches)(ii)
The sensors operate autonomously with near real-time measurement readingsIn such cases, the BIM may become an oversaturated repository of elements representing point- or network-type sensors or surface patches (based on division resolution). The SHM analysis and forecast could become even more difficult, complex, and laborious if the sensor data integration rate into the BIM gets higher and higher.To avoid this scenario, the alternative approach would be to avoid adding sensors as a separate layer group but to include only their output (i.e., sensor representative values) directly into the property sets of the already existing BIM elements. Once these individual sensor representative values are stored for each BIM element, some kind of performance indicators (PI) could be calculated for each existing element. These individual element PIs could further be used to estimate key performance indicators (KPI) for the entire structure (e.g., road). In this scenario, the best way would probably be to have a two-level structure:(i)
A general level (for the BIM as a whole)(ii)
An individual BIM element levelAt the general level, the estimated KPIs would cover aspects such as safety, reliability, functionality, and economics. On the local element level, the PIs would be more closely connected to sensor results so that in case of some kind of malfunctioning, the problems could be isolated and resolved faster. Following this scenario, the direct visualization of any larger number of sensor datasets could completely be avoided with colour-coding simply indicating which BIM elements are potentially problematic from the sensor measurement perspective.The methodologies for calculating KPIs for various civil engineering structures are inherently somewhat different due to the character of these structures themselves. However, in the future, with BIM also covering the monitoring phase of the structure’s lifecycle and including many different sensors, such an approach would be more than welcome. This way, the sensor data aspect and the engineering interpretation of this data are separated, which leaves more space for fine-tuning both these aspects during the sensor-to-BIM implementation phase.Several researchers defined (K) PIs for the purpose of a civil engineering structure performance assessment (e.g., [44, 45]), while at the same time, examples of the actual implementation of (K) PI schemes into the BIM/IFC data structure are difficult to find. As researchers already successfully demonstrated the integration of sensor data and BIM ([46, 47]), the introduction of performance indicators into the IFC format can be expected in the foreseeable future.


## 5. Digital Twinning Case Study

In this section, we present preparation work to establish a fully functioning DT of a road construction project. A case study includes the integration of sensor data with BIM, on an approximately 300 m access road project in Maribor, Slovenia, being constructed at the degraded area of a former gravel pit within the CINDERELA project. The road was designed following the CE principles, especially the use of SRM-based products, namely, recycled aggregate for the subgrade and base course and recycled grind asphalt with supplements for the surface course.Although small scale, we demonstrated challenges that could be expected in an upscaled road DT project. To best simulate cross-functional integration, various BIM modelling and BIM coordination tools were used, BIM elements that embody BIM sensors (object libraries) were custom made, various sensor data structures were embedded, etc.


### 5.1. Technical Requirements

Based on the literature review presented in Sections3 and 4 and in line with international standards, i.e., EN ISO 19650-1:2018 [48], minimal functional requirements for the platform suitable digital twinning of the road construction were identified. In summary, they include the following:(i)
Capability to import and federate multiple IFC model files (preferably to support both IFC2x3 and IFC4 schema)(ii)
Support for handling and analysing BIM metadata(iii)
Capability for data augmentation (adding new attributes) directly within the system(iv)
An interface for reading, analysing and automating the exchange of the model metadata (such as scripts, extensions, add-ins)—this is crucial since importing additional information from external data sources, such as structured XML or CSV files, is the envisioned concept of sensor data integration(v)
Capability to export integrated BIM with sensor data and links to external documentation, in the open IFC file format (preferably to both IFC2x3 and IFC4) to ensure compatibility with other supported BIM software


### 5.2. Implementation

The overall workflow consisted of four interconnected tasks (Figure5).Figure 5
IDEF0 case study execution workflow diagram.The project design was initially developed in 2D CAD. Therefore, the first step toward setting up the DT of the road was developing the BIM based on the initial plans, geometric survey, etc. The BIM was developed using the authoring tools Autodesk Civil 3D and Revit, where at the time, only the second was certified by buildingSMART as an IFC file format compatible software [49]. Although export in multiple versions of the IFC schema is available in Revit as well as Civil3D, IFC 2 × 3 was used in the case study.After modelling was completed, the common data environment to establish a federated model was chosen based on the criteria presented in Section5.1. The federated BIM served as a base to establish a DT. Bexel Manager BIM analysis and management tool was selected since it was fully compliant with the requirements.The federated BIM (Figure6) included multiple sources. Elements for the access road with earthworks were modelled in Civil 3D and sensors were modelled as separate sources in Revit. The adopted level of development of the BIM represents each material and layer of the road structure as a separated BIM element. Additionally, to relate sensor readings with specific test sections of the monitored road, the BIM was longitudinally separated to elements 10 m in length. All elements (layers) of the single-road test section include the attribute Test Section ID, containing the specific tag (test section ordinal identifier) that is also included as part of the Sensor ID attribute of corresponding sensors.Figure 6
Federated BIM.


#### 5.2.1. Data Structure within the BIM

To integrate the sensor data within the BIM, certain attribute extensions had to be ensured on the BIM elements that represent sensors. Besides a unique sensor identifier (Sensor ID), which was used to connect the data to the element, two additional attributes were generated as an output of the integration process:(i)
Sensor Value: Numerical attribute representing the (processed) value of the sensor or a KPI at the given time(ii)
Sensor Value Timestamp: DateTime attribute representing the exact time the value was sampled


#### 5.2.2. Sensor Inputs

Based on the literature review (Section3), relevant sensors for the lifecycle response of SRM-based construction materials showing the structural health and environment monitoring of the road were selected. The most appropriate position was examined primarily for monitoring but also from a modelling point of view. Finally, the sensor positions were defined and modelled. Longitudinally, sensors had to be placed in the middle of the monitored 10 m section, between the road layers. According to the naming convention, each sensor had to have the unique identifier, including the test section identifier, sensor-type mark, and sensor identifier. The adopted sensors, their type, and position in the road cross section are presented in Table 1.Table 1
Implemented sensors, types, and position in the road cross section.
SensorMarkTypeCountPositionTemperature sensorTPoint sensor36Between the layers, in road axis and boundaryInductive displacement sensor (vertical deformation)EMUNetwork sensor16On top and the bottom of subbase courses, below assumed wheels positionSoil moisture sensorTDRPoint sensor8Between the base and subbase course layers, in road axisAsphalt strain sensorHASPoint sensor8Below surface course, below assumed wheels positionHorizontal inclinometer (vertical deformation)HINetwork sensor4Below subbase course in the entire profile, measuring points distance: 25 cmPressure pads (vertical pressure)PPSurface sensor8Between two base courses layers, below assumed wheels positionIn addition to the sensors listed in Table1, the monitoring of environmental data (e.g., leachates chemistry, and particles emission) should also be considered.


#### 5.2.3. Sensor Data Integration

The Bexel Manager allows expanding functionalities by developing custom add-ins using the open C# API, which allows the development of custom software modules for exchanging data from any external data source and interacting with the BIM environment in a programmable way. These mechanisms allowed us to build a dedicated sensor integration add-in that acts as the main point of integration between the sensor data provider and the BIM itself. Additionally, working in a .NET development environment provided us access to many mature software libraries with graphs and charts, which were used to develop a highly functional UI for the add-in (Figure7).Figure 7
Sensor Data Integration Data Flow Scheme, import of test sensor data by metadata enrichment.


#### 5.2.4. Sensor Data Presentation

In the case study, the relationship between sensors and road model elements was defined during the modelling process using the standardized tagging of road model elements within theTest section ID attribute and well-structured naming of Sensor ID property, which contains Test section ID. Therefore, it was possible to create smart selection sets containing sensor elements and the corresponding road elements by creating simple attribute queries. Defining attribute-based rules is presented in Figure 8.Figure 8
Smart selection sets.The main advantage of the attribute-based queries is the automated update of element sets if the BIM is updated. In Figure9, the colour coded element breakdown according to test section selection sets is presented.Figure 9
Colour coded element breakdown.Last, we had to link the datasets, e.g., documents and photos, to the federated model elements that can complement the sensor dataset and provide full insight into the behaviour of the SRM-based construction materials and overall structural health and impact of the monitored road.


#### 5.2.5. Filtering Sensor Data Based on Specified Time-Range to Allow Aggregated Loading into the BIM Environment

With the developed add-in, received sensor data can be filtered between a specific start/end timestamp and the aggregated value can be loaded into the BIM. For example, the user can isolate the average value for a specific day and attach that value to the related sensor element based on its identifier.


#### 5.2.6. Sensor Data Processing

Since the sampling frequency of particular sensors can be quite high, it has been established that additional processing needs to be performed on the raw sensor outputs before they can be consumed within the BIM environment. This may include condensing sample resolution (e.g., minutes instead of milliseconds) or extracting valuable key performance indicators (KPIs) from the dataset. Finally, the processed data must be exposed either through a dedicated web service, a database or provided in a file.


## 5.1. Technical Requirements

Based on the literature review presented in Sections3 and 4 and in line with international standards, i.e., EN ISO 19650-1:2018 [48], minimal functional requirements for the platform suitable digital twinning of the road construction were identified. In summary, they include the following:(i)
Capability to import and federate multiple IFC model files (preferably to support both IFC2x3 and IFC4 schema)(ii)
Support for handling and analysing BIM metadata(iii)
Capability for data augmentation (adding new attributes) directly within the system(iv)
An interface for reading, analysing and automating the exchange of the model metadata (such as scripts, extensions, add-ins)—this is crucial since importing additional information from external data sources, such as structured XML or CSV files, is the envisioned concept of sensor data integration(v)
Capability to export integrated BIM with sensor data and links to external documentation, in the open IFC file format (preferably to both IFC2x3 and IFC4) to ensure compatibility with other supported BIM software


## 5.2. Implementation

The overall workflow consisted of four interconnected tasks (Figure5).Figure 5
IDEF0 case study execution workflow diagram.The project design was initially developed in 2D CAD. Therefore, the first step toward setting up the DT of the road was developing the BIM based on the initial plans, geometric survey, etc. The BIM was developed using the authoring tools Autodesk Civil 3D and Revit, where at the time, only the second was certified by buildingSMART as an IFC file format compatible software [49]. Although export in multiple versions of the IFC schema is available in Revit as well as Civil3D, IFC 2 × 3 was used in the case study.After modelling was completed, the common data environment to establish a federated model was chosen based on the criteria presented in Section5.1. The federated BIM served as a base to establish a DT. Bexel Manager BIM analysis and management tool was selected since it was fully compliant with the requirements.The federated BIM (Figure6) included multiple sources. Elements for the access road with earthworks were modelled in Civil 3D and sensors were modelled as separate sources in Revit. The adopted level of development of the BIM represents each material and layer of the road structure as a separated BIM element. Additionally, to relate sensor readings with specific test sections of the monitored road, the BIM was longitudinally separated to elements 10 m in length. All elements (layers) of the single-road test section include the attribute Test Section ID, containing the specific tag (test section ordinal identifier) that is also included as part of the Sensor ID attribute of corresponding sensors.Figure 6
Federated BIM.


### 5.2.1. Data Structure within the BIM

To integrate the sensor data within the BIM, certain attribute extensions had to be ensured on the BIM elements that represent sensors. Besides a unique sensor identifier (Sensor ID), which was used to connect the data to the element, two additional attributes were generated as an output of the integration process:(i)
Sensor Value: Numerical attribute representing the (processed) value of the sensor or a KPI at the given time(ii)
Sensor Value Timestamp: DateTime attribute representing the exact time the value was sampled


### 5.2.2. Sensor Inputs

Based on the literature review (Section3), relevant sensors for the lifecycle response of SRM-based construction materials showing the structural health and environment monitoring of the road were selected. The most appropriate position was examined primarily for monitoring but also from a modelling point of view. Finally, the sensor positions were defined and modelled. Longitudinally, sensors had to be placed in the middle of the monitored 10 m section, between the road layers. According to the naming convention, each sensor had to have the unique identifier, including the test section identifier, sensor-type mark, and sensor identifier. The adopted sensors, their type, and position in the road cross section are presented in Table 1.Table 1
Implemented sensors, types, and position in the road cross section.
SensorMarkTypeCountPositionTemperature sensorTPoint sensor36Between the layers, in road axis and boundaryInductive displacement sensor (vertical deformation)EMUNetwork sensor16On top and the bottom of subbase courses, below assumed wheels positionSoil moisture sensorTDRPoint sensor8Between the base and subbase course layers, in road axisAsphalt strain sensorHASPoint sensor8Below surface course, below assumed wheels positionHorizontal inclinometer (vertical deformation)HINetwork sensor4Below subbase course in the entire profile, measuring points distance: 25 cmPressure pads (vertical pressure)PPSurface sensor8Between two base courses layers, below assumed wheels positionIn addition to the sensors listed in Table1, the monitoring of environmental data (e.g., leachates chemistry, and particles emission) should also be considered.


### 5.2.3. Sensor Data Integration

The Bexel Manager allows expanding functionalities by developing custom add-ins using the open C# API, which allows the development of custom software modules for exchanging data from any external data source and interacting with the BIM environment in a programmable way. These mechanisms allowed us to build a dedicated sensor integration add-in that acts as the main point of integration between the sensor data provider and the BIM itself. Additionally, working in a .NET development environment provided us access to many mature software libraries with graphs and charts, which were used to develop a highly functional UI for the add-in (Figure7).Figure 7
Sensor Data Integration Data Flow Scheme, import of test sensor data by metadata enrichment.


### 5.2.4. Sensor Data Presentation

In the case study, the relationship between sensors and road model elements was defined during the modelling process using the standardized tagging of road model elements within theTest section ID attribute and well-structured naming of Sensor ID property, which contains Test section ID. Therefore, it was possible to create smart selection sets containing sensor elements and the corresponding road elements by creating simple attribute queries. Defining attribute-based rules is presented in Figure 8.Figure 8
Smart selection sets.The main advantage of the attribute-based queries is the automated update of element sets if the BIM is updated. In Figure9, the colour coded element breakdown according to test section selection sets is presented.Figure 9
Colour coded element breakdown.Last, we had to link the datasets, e.g., documents and photos, to the federated model elements that can complement the sensor dataset and provide full insight into the behaviour of the SRM-based construction materials and overall structural health and impact of the monitored road.


### 5.2.5. Filtering Sensor Data Based on Specified Time-Range to Allow Aggregated Loading into the BIM Environment

With the developed add-in, received sensor data can be filtered between a specific start/end timestamp and the aggregated value can be loaded into the BIM. For example, the user can isolate the average value for a specific day and attach that value to the related sensor element based on its identifier.


### 5.2.6. Sensor Data Processing

Since the sampling frequency of particular sensors can be quite high, it has been established that additional processing needs to be performed on the raw sensor outputs before they can be consumed within the BIM environment. This may include condensing sample resolution (e.g., minutes instead of milliseconds) or extracting valuable key performance indicators (KPIs) from the dataset. Finally, the processed data must be exposed either through a dedicated web service, a database or provided in a file.


## 5.2.1. Data Structure within the BIM

To integrate the sensor data within the BIM, certain attribute extensions had to be ensured on the BIM elements that represent sensors. Besides a unique sensor identifier (Sensor ID), which was used to connect the data to the element, two additional attributes were generated as an output of the integration process:(i)
Sensor Value: Numerical attribute representing the (processed) value of the sensor or a KPI at the given time(ii)
Sensor Value Timestamp: DateTime attribute representing the exact time the value was sampled


## 5.2.2. Sensor Inputs

Based on the literature review (Section3), relevant sensors for the lifecycle response of SRM-based construction materials showing the structural health and environment monitoring of the road were selected. The most appropriate position was examined primarily for monitoring but also from a modelling point of view. Finally, the sensor positions were defined and modelled. Longitudinally, sensors had to be placed in the middle of the monitored 10 m section, between the road layers. According to the naming convention, each sensor had to have the unique identifier, including the test section identifier, sensor-type mark, and sensor identifier. The adopted sensors, their type, and position in the road cross section are presented in Table 1.Table 1
Implemented sensors, types, and position in the road cross section.
SensorMarkTypeCountPositionTemperature sensorTPoint sensor36Between the layers, in road axis and boundaryInductive displacement sensor (vertical deformation)EMUNetwork sensor16On top and the bottom of subbase courses, below assumed wheels positionSoil moisture sensorTDRPoint sensor8Between the base and subbase course layers, in road axisAsphalt strain sensorHASPoint sensor8Below surface course, below assumed wheels positionHorizontal inclinometer (vertical deformation)HINetwork sensor4Below subbase course in the entire profile, measuring points distance: 25 cmPressure pads (vertical pressure)PPSurface sensor8Between two base courses layers, below assumed wheels positionIn addition to the sensors listed in Table1, the monitoring of environmental data (e.g., leachates chemistry, and particles emission) should also be considered.


## 5.2.3. Sensor Data Integration

The Bexel Manager allows expanding functionalities by developing custom add-ins using the open C# API, which allows the development of custom software modules for exchanging data from any external data source and interacting with the BIM environment in a programmable way. These mechanisms allowed us to build a dedicated sensor integration add-in that acts as the main point of integration between the sensor data provider and the BIM itself. Additionally, working in a .NET development environment provided us access to many mature software libraries with graphs and charts, which were used to develop a highly functional UI for the add-in (Figure7).Figure 7
Sensor Data Integration Data Flow Scheme, import of test sensor data by metadata enrichment.


## 5.2.4. Sensor Data Presentation

In the case study, the relationship between sensors and road model elements was defined during the modelling process using the standardized tagging of road model elements within theTest section ID attribute and well-structured naming of Sensor ID property, which contains Test section ID. Therefore, it was possible to create smart selection sets containing sensor elements and the corresponding road elements by creating simple attribute queries. Defining attribute-based rules is presented in Figure 8.Figure 8
Smart selection sets.The main advantage of the attribute-based queries is the automated update of element sets if the BIM is updated. In Figure9, the colour coded element breakdown according to test section selection sets is presented.Figure 9
Colour coded element breakdown.Last, we had to link the datasets, e.g., documents and photos, to the federated model elements that can complement the sensor dataset and provide full insight into the behaviour of the SRM-based construction materials and overall structural health and impact of the monitored road.


## 5.2.5. Filtering Sensor Data Based on Specified Time-Range to Allow Aggregated Loading into the BIM Environment

With the developed add-in, received sensor data can be filtered between a specific start/end timestamp and the aggregated value can be loaded into the BIM. For example, the user can isolate the average value for a specific day and attach that value to the related sensor element based on its identifier.


## 5.2.6. Sensor Data Processing

Since the sampling frequency of particular sensors can be quite high, it has been established that additional processing needs to be performed on the raw sensor outputs before they can be consumed within the BIM environment. This may include condensing sample resolution (e.g., minutes instead of milliseconds) or extracting valuable key performance indicators (KPIs) from the dataset. Finally, the processed data must be exposed either through a dedicated web service, a database or provided in a file.


## 6. Conclusions and Feature Work

Inspired by the potential benefits arising from introducing material circularity in the construction industry, this paper examines the benefits and issues engineers are faced with when they decide to use SRM materials in road construction projects. Through desktop research, it was concluded that sensing road components and their environmental impact is crucial to ensure safety and operability through their life cycle, all the way to decommissioning, recycling, and potential reuse. Accordingly, the paper summarizes monitoring techniques applicable to capture digital data compatible with existing BIM tools.Based on theoretical findings, a prototype was established to prove the hypothesis that digital twinning could be a valuable technology to address challenges posed using SRM-based materials in civil engineering projects. Correspondingly, the practical part of the research relies on data flow in a road construction project being realized within the CINDERELA project. With the successful integration of sensor data readings and BIM, we made the first step toward a fully functioning DT. Since the construction of the road within the CINDERELA project case study is still in progress, the paper mainly summarizes the prototype functioning tests from the functional point of view.Despite the fact that construction has not been completed, two theoretical evaluations has indicated the possibility of two advantages. First, we can highlight a feature that exceeds the so-called static BIM, which is the advantage of centralized data collection with related enquiries. Moreover, perhaps an even more important advantage is the graphical presentation of (K) PI. Both can contribute to better-informed decision-making, which is one of the most essential goals of digital twinning.Notwithstanding the effective prototype implementation, two main challenges must be highlighted besides the well-known lack of standardized semantic schemas in civil engineering IT support. The first is “How to incorporate a vast amount of relatively small sensors?” and equally important is “How to deal with the high frequency of data acquisition coming from some sensors?”. Both challenges need to be addressed; otherwise, the data amalgamation in DTs might be at risk.In this paper, we demonstrated that digital twinning challenges in civil engineering projects are real but manageable. It turns out that the technical problems are often attributed to software incompatibilities but can be resolved by the thoughtful use of BIM libraries with attention to its attributes. The data processing and presentation is a more complex challenge, which is not only of a technical nature. Thorough careful consideration will always be needed to frame the substantively correct message that is to be conveyed to the end-users. One of the options we used in our case is the aggregation of monitor readings with smart model breakdowns to generate a colour-coded element presentation.



---

*Source: 8833058-2021-01-19.xml*