Keywords

1 Introduction

Precast concrete construction is generally considered a suitable approach to meet the growing demand for housing and the main issues of the construction industry, such as long construction times and high costs. Prefabrication, however, implies by no means that the precast modules are manufactured in series with large quantities and a high degree of automation. Instead, they are individual products manufactured in a handcrafted process. Automation is usually only implemented for a few sub-processes. In order to fully exploit the advantages of prefabrication, precast concrete elements must be produced in series on the one hand and in digitized and automated manufacturing processes on the other. The introduction of Industry 4.0 (I4.0) in the manufacturing industry has demonstrated how end-to-end digitization and interconnection can establish the basis for automated production environments [1]. Applying I4.0 to the industrialized production of precast concrete modules has the potential to increase production efficiency in the construction industry sustainably. The additional requirements placed on the modules by serial production must already be considered in design and construction regarding the subsequent production process.

This paper presents an approach to the industrialized series production of precast concrete modules according to the I4.0 model for modular construction. The additional requirements resulting from the serial production and assembly of the modules are specified in the context of design and construction. Furthermore, a concept for a digital twin based on the Asset Administration Shell (AAS) known from I4.0 is proposed. Within the framework of a case study, a prototype of a precast concrete module is presented that meets the requirements for serial production and has a digital twin in the form of an AAS enabling production in a cyber-physical production system (CPPS). The application of the digital twin is exemplarily demonstrated by using heat treatment to rapidly cure a precast concrete module.

2 State of the Art

2.1 Precast Concrete Components and Modular Construction

Precast concrete components are manufactured under regulated conditions and thus usually have a better quality than concrete components built on the construction site [2]. This is ensured by, for example, geometrically stable and reusable steel formworks. The individuality of buildings, in contrast, is reflected in a low repetition rate of the concrete components used, which then avoids multiple uses of formworks. However, in industrial buildings that almost consist of the same beam-, plate-, and column elements, the reinforcement ratio or different installation parts for connections also lead to individual design and consequently individual manufacturing. But, manufacturing is most effective when the same element is mass-produced in an automated manner. When automation is incorporated, precast concrete component construction offers the potential to improve sustainability (i.e., environmental, economic, and social) as well as all processes (i.e., design, production, and construction) [3]. To achieve this, a modularization of structures into equal or at least similar modules is reasonable since modular construction aims to industrialize the prefabrication of building elements [4]. This enables mass production techniques up to mass customization when off-site construction is utilized. Hereby, off-site construction refers to partial structures with already installed (non-)structural elements, for example, walls with windows and electric wiring, or whole room modules [5]. However, the benefits of both, modular construction, and off-site construction, are manifold. Since the production is moved from on- to off-site, the production, as well as the construction process, is mainly independent of weather conditions. Building elements can be prefabricated using serial production methods to ensure quality, avoid unnecessary waste, and accelerate – not only – the fabrication process. In addition, the construction on-site is reduced to “assembly only”. This means that the design of structures must emerge from both, manufacturing and assembly. In architecture, engineering, and construction (AEC) therefore Design for Manufacturing and Assembly (DfMA) [6] originating from the production industry has become an approach to avoid high costs, low productivity, and long delivery time. DfMA follows principles such as minimizing the number of building elements or joints, respectively, choose optimal material, optimize components, and streamline processes.

2.2 Industry 4.0 and Digital Twin

Industry 4.0 (I4.0) refers to the digital transformation of the manufacturing industry, enabled in particular by advances in information and communication technology, leading to a convergence of the physical and virtual worlds [1, 7]. In I4.0, production environments form cyber-physical production systems (CPPS) whose participants are interconnected with processes and other participants to exchange data and information to achieve individual goals. Smart products are uniquely identifiable, can be located in the production system at any time, and have information about their history, current state, and next steps to reach their target state. I4.0 enables the integration of individual customer requirements and a lot-size-one production while maintaining the economic conditions of mass production. In addition, last-minute changes, flexible reactions to malfunctions and errors as well as transparency about the manufacturing processes allow for optimized decision-making [1, 8]. The evaluation and analysis of production data in real-time are one of the key concepts of I4.0 in which the digital twin plays a central role [9].

Since its introduction, the digital twin has become a key element in the digital transformation of many industries. As a result, various definitions of the digital twin emerged reflecting industry-specific requirements. In general, a digital twin is a formal virtual representation of an asset, process, or system that captures the entity's attributes, properties, and behaviours. It provides communication, data management, interpretation, and processing methods in a context-specific frame [10]. The digital twin is often synonymously used in the literature with concepts such as digital model or digital shadow. In their work, Kritzinger et al. [11] delineate the digital twin by its vertical integration. They define the concept by three main components: a physical asset, a virtual representation, and a bidirectional data link that connects the two [11]. In the construction industry, a lack of consensus prevails, particularly regarding the role of BIM in the context of digital twins. The digital twin is understood here either as an extension, complementary, or completely independent of BIM [12]. Delgado et al. [13] see BIM and the digital twin as a response to different industry requirements. According to Boje et al. [14], BIM provides methods, technologies, and data schemas to enable a standardized semantic representation of building structures, while the digital twin provides a more holistic socio-technical and process-oriented representation. Furthermore, BIM lacks methods for integrating dynamic data and their semantic description, which are essential for control systems of any kind.

2.3 The Asset Administration Shell

In Industry 4.0, the AAS provides a framework as an industry-neutral standard for implementing modular digital twins [15]. The AAS consists of several submodels, each depicting a closed view of an aspect or use case that combines to form an overall digital representation. Submodels contain all relevant data in the form of static and dynamic attributes and properties stored as literal values or as references to external files such as PDF, IFC, or STEP. For data exchange within a cyber-physical production system, it is of essential importance that the meaning of the data is unambiguously interpretable by both humans and machines. For this purpose, the data stored in the submodels are given a semantic identifier and are unambiguously semantically described by concept descriptions (Fig. 1). The AAS is based on a UML data model for which XML, JSON, and RDF serializations exist. Furthermore, an AAS package container is available, which, in addition to a serialization, contains all other files referenced in the AAS. AASs are divided into three different types. Type 1 is the passive AAS in the form of a file that is used for interoperable data exchange along the value chain. Type 2 is a reactive AAS in the form of a server application whose data content can be accessed via standardized interfaces, e.g., HTTP/REST, OPC UA, or MQTT. Type 3 refers to an active AAS that can initiate communication with other entities of the CPS in addition to type 2 and can thus interact with its environment. A special Industry 4.0 language is currently being developed for active communication [16]. For further information on the AAS please refer to the official documentation [15].

Fig. 1.
figure 1

Concept of the AAS based on [15].

3 Concept

The generalized concepts for serial production of precast concrete modules with requirements originating from rapid production and modular construction, as well as for the digital twin are derived being the basis for the case study.

3.1 Serial Production of Precast Concrete Modules

The production of precast concrete components can be coarsely divided in the subsequent process steps: shuttering, insert reinforcement, concreting, early strength hardening, and stripping as well as storing until the strength for assembly is reached. However, serial production of modular concrete components aims for a not only precise but rapid manufacturing. This contrasts with the different production times of the individual process steps. While concreting, for example, takes durations in the range of minutes, the hardening process until stripping exhibits several hours up to days; achieving a final strength sufficient for installation even weeks. Thus, a rapid heat treatment of 80 ℃ directly after concreting – and therefore non-compliant with standardized heat treatments acc. to [17] – is assumed here as investigated in [18], which only takes about 2–6 h. Thereby, high-performance concrete is used that on the one hand is suitable for these high heating rates and on the other hand exhibits a high strength after heat treatment almost suitable for installation. Since the hardening process still takes several hours, this discrepancy in the time sequence must be adjusted by paralleling or scaling the individual process steps. However, the storage of components can be omitted.

Next to accelerated strength development, residual shrinkage deformations are pronouncedly reduced by heat treatment [18] so that time-dependent deformations of the module, except for load-induced creeping, are minimized. This ensures that no undesired shape deviations, which exceed the dimensional tolerances, prevent subsequent assembly. However, resulting tolerances of the individual process steps, e.g., depending on formwork material, manual or automated accuracy, and measurement technique, must comply with the tolerances of the joints and consequently of the building structure [19]. Therefore, all process steps must be controlled by means of quality control so that deviations in the geometrical, thermal, or mechanical parameters of the module or processes, respectively, can be used to adjust the production (or the design). In conclusion, the process steps of serial production of precast concrete modules can be summarized as shuttering, insert reinforcement, concreting, rapid heat treatment, stripping, and (continuous) quality control.

However, generalized requirements, e.g., for the dimensional accuracy of modular concrete components cannot be drawn, since they strongly depend on their individual structure, modularization method, and joints, as well as the used materials and production. This underlines the necessity of the holistic digital representation as a digital twin, which is developed conceptually in the following section.

3.2 The Digital Twin of Precast Concrete Modules

For precast concrete modules to be produced in a production process based on the I4.0 model, a suitable implementation of a digital twin is required that virtually mirrors the modules and collects, evaluates, and provides all relevant data for the production processes (cp. Fig. 2). In the construction industry, modular digital twin concepts have become established, which can be adapted to the requirements of the individual life phases due to their exchangeability, adaptability, and expandability. The respective modules are globally uniquely identifiable so that data can be referenced and aggregated. The data is accessed via standardized interfaces.

The AAS offers an ideal platform for developing digital twins for the industrialized production of precast concrete modules. Due to the data and information structured in submodels, each of which offers a self-contained view of an aspect or use case, the AAS enables a modular and flexible implementation. The digital building models created as part of the Building Information Modeling (BIM) process, which include the logical building structure and other semantic properties and attributes, contain a subset of the data required to implement digital twins for the industrialized production of precast concrete modules. Integration of data from IFC-based BIM models and other data sources enables a continuous flow of information along the lifecycles and enables rapid deployment of digital twins (cp. Fig. 2) [20].

To build digital twins based on the AAS, specific submodels, and the required data structures must be developed for each aspect or use case of an asset. Standardization of the AAS’s data structure is advisable to ensure exchangeability along the value chain and life phases. The Standardization Council Industrie 4.0 (SCI4.0) is currently, among other things, driving forward the standardization of certain submodels of the AAS. Standardized submodels exist for aspects, such as Identification, Technical data, and Documentation, which provide a basis for developing AASs. Submodels can be composed into AAS templates enabling rapid deployment by connecting, integrating, and evaluating various data sources. In previous work, an AAS template for the industrialized production of precast concrete modules has been created [21]. The template consists of the already standardized submodels as well as additional submodels for Detailed Design, Production, Quality Control, and Requirements (cp. [21, 22]).

Fig. 2.
figure 2

The AAS as the implementation of the digital twin along the value chain.

4 Application

Within the scope of a case study, a Y-shaped precast concrete element has been designed that meets the requirements of serial production and is virtually represented by a digital twin in the form of the AAS. Following DfMA and modular construction principles, the module is derived from a honeycomb-like structure minimizing material demands while ensuring high stiffness. It is produced in a rapid, serial production-ready process with integrated quality control. Production relevant data are stored in the AAS and can be used for further communication and interaction in the production.

4.1 Design

The Y-shaped module exhibits arm lengths of 1 m. Its cross section is rectangular with rounded edges (radius of 2.215 cm), which results in a module’s height of 4.43 cm defined by the formwork made from steel profiles. The width tapers from 11 cm at the end of the arms to 14 cm in the module’s center. Due to the intended heat treatment, a high-performance concrete based on the binder Nanodur Compound 5941 is used [18]. However, for a standardized design it can be characterized to a C100/115. Two conventional steel bars type B500 with a diameter of 10 mm per module’s arm serve as reinforcement. Thereby, a mean reinforcement ratio of 3.1% results. The minimum concrete cover is 0.5 cm only, which is sufficient due to the dense concrete matrix. The bearing capacity is described by the resistance moment to normal force ratio given by MRd-NRd-design chart, which is derived with respect to the geometry and materials used according to [23]. The conceptual honeycomb structure, the module’s geometry, and an exemplary load-bearing capacity for the center of an arm are depicted in Fig. 3.

Fig. 3.
figure 3

Design of a Y-shaped module for an exemplary honeycomb wall-like structure.

For assembly, the modules exhibit steel plates with holes of 3 cm in diameter for screw connections at the end of their arms, which only transmit forces, not bending moments. The hole clearance for assembly is set to 2 mm since it has been proven to be sufficient for modules with an arm length of 2 m and bolted connections with prealignment of the modules [24].

4.2 Digital Twin Representation of the Y-Shaped Precast Concrete Module

The digital twin representation of the Y-shaped precast concrete module shown in Fig. 3 has been created based on the template for AASs presented in [21]. As data basis serves an IFC-based BIM that, in addition to the geometric representation of the component, contains all data and information about material and reinforcement. The requirements placed on the component regarding production and quality have been compiled in a Requirements Interchange Format (ReqIF) file, including mapping to the corresponding data in the AAS (cp. [22]). Figure 4 shows screenshots of the resulting AAS of the Y-module.

Fig. 4.
figure 4

AAS of Y-shaped module.

4.3 Production

The module is produced in the laboratory KIBKON of the Ruhr University Bochum. The formwork was built up using steel elements consisting of a bottom plate with a thickness of 2 cm on which L-profiles L 50 × 50, t = 4 [mm] with attached semi-circular profiles (Ø = 44.8, t = 2 [mm]) are connected. Thereby, the roundish shape of the module’s arms is ensured. Subsequently the reinforcement as well as the steel connectors were placed and fixed in their position. In addition, in the core of every arm two temperature sensors (edge and center) and in the module’s center are placed for temperature measurement. Also, two strain gauges per arm are attached at the reinforcement bars, also in their center. Figure 5 shows the positioning of the described sensors and of additional deformation sensors at every edge of the arms to control the axial as well as the vertical deviations. For selected sensors exemplary measurement data are depicted. The temperature sensors can be used to monitor the heat treatment. The strain gauges give information about the shrinkage strains, additionally to temperature induced ones. The deformations are critical for the fit accuracy of assembly, i.e., the axial deformations must be within the hole clearance of the connections, whereby the vertical deformations describe unintended “dishing” effects, likely resulting from uneven temperature distributions during heat treatment, shrinkage, residual stresses or friction between the module and the adjoining formwork. Directly after concreting, a heat treatment of 80 ℃ for 4 h is conducted using at total of 6 infrared radiators, one each on the upper and the lower side of an arm. The radiators themselves exhibit a temperature range of >100 ℃ and an electrical power of 3000 W each. The sensor for controlling the temperature was placed in the center, on the top of the module.

After heat treatment and cooling of the formwork, the module was stripped and stored under the environmental conditions of the laboratory for further monitoring. To clearly identify the module and access data within the digital twin, a QR code is attached to its surface.

Fig. 5.
figure 5

Sensors of core temperature, strain, as well as deformation and their position in and at the module with exemplary measuring data over time.

The formwork before concreting as well as the concrete module itself has been three-dimensionally measured using a 3D scanner type ATOS Compact Scan 8M. Additionally, the strength was evaluated by means of a rebound hammer, which must be adjusted for the used concrete and the heat treatment. Nevertheless, the evaluation of the measurements and their effect on the load-bearing capacity defined by the M-N ratio is still ongoing.

In this case study, real-time temperature, and strain monitoring during rapid heat treatment of the module has been implemented. For this purpose, the measured sensor data is transmitted to the AAS, which captures the data in a machine-readable form and makes it available for further applications. For the visualization of the sensor data, an online dashboard based on the open-source visualization platform Eclipse Streamsheets has been developed [25]. Streamsheets allow and analysis of IoT data in an online spreadsheet. The platform supports standard communication protocols such as REST, MQTT, or OPC UA, enabling combination with the AAS. In this study, the HTTP client function of Streamsheets was used to send configurable HTTP requests to an URL and for passing the response as input to Streamsheets. The data collected in the AAS can be queried and processed regularly via HTTP requests. Figure 6 shows the visualization of the temperature data.

Fig. 6.
figure 6

Plot of the temperature sensors data according to sensors shown in Fig. 5.

4.4 Results

The core temperature during heat treatment exhibits values over 90 ℃, which can be led back to two effects. First, due to central position of the sensor, the arms are partly exposed to temperatures exceeding the targeted value of 80 ℃. Second, heat development from concrete hydration during accelerated curing superimposes. A steering of the heat treatment by means of sensors on the outside and core, controlled by process parameters provided by the digital twin, is adopted in further investigations in order to avoid too high temperatures.

The qualitatively course of the strains within the module converges towards approx. 1 mm/m after about a week. Hence, only minor material-dependent strains are to be expected when the module is assembled. Otherwise, the residual deformation must be considered in the design. However, the strains presented are raw data, which still need to be investigated with respect to their material, thermal, and non-identifiable amounts for a better distinction. For the sake of automation, the quality control AAS must be enhanced to directly distinguish and evaluate between the several amounts of strains.

The deformation sensors show values for axial and vertical deformations in the same range of <0.3 mm. Whereby, both converge towards approx. 0.15 mm. This means that the assumed hole clearance for connection is sufficient. However, the effects of modules to be connected must also be taken into account, which can be checked by the structural requirements in the digital twin. Then, requirements for modules to be produced can automatically be communicated to the production process.

5 Conclusion

In this paper, a precast concrete module with thermal and geometrical sensors is produced with rapid heat treatment using Industry 4.0 concepts. Production relevant data such as process and machine parameters or sensor data are captured, processed, and provided by a digital twin. The following key takeaways can be concluded:

  • The monitoring of the production process offers the possibility to control maximum temperatures by means of the modules core temperature. In addition, the actual load-bearing capacities as well as the fit accuracy of the intended assembly can be determined based on the measured geometric deviations.

  • The developed digital twin that bases on the AAS complements existing BIM approaches by integrating dynamic data as well as communication and interaction.

  • The design and production of a modular precast component are combined with the digital representation in the form of a case study and thus forming the basis of a CPPS. This enables methods of automation to be integrated into the mass production of precast concrete components.

  • In future investigations, the continuously measured data, which are mirrored in quasi-real-time in the AAS, allow direct control of the production process. For example, the actual load-bearing capacity of an already-produced module influences the design of the structure, resulting in the requirements of subsequent modules. These requirements are then communicated to the current production.