Keywords

1 Introduction

The social, environmental and economic benefits of digitalization are well recognized in the Construction industry and already implemented in Aerospace and Automotive industries. In both industries, the strategic vision based on information lifecycle management, provides significant efficiency benefits, time-saving, value creation, and they are a driver for country competitiveness.

Sometimes, the legislative framework could speed the technologies adoption, but the context is not always ready. For example, the Italian country struggles to follow innovation in the construction industry, even though nowadays it recognizes as fundamental. In detail, the “Codice degli Appalti” n. 50/2016, in article 23, paragraph 13, introduces the use of specific electronic methods and tools for complex works and the Ministerial Decree n. 560/2017 defines the methods and times of gradual mandatory introduction. The obligatoriness starts from the 1st January 2019 for works value of €100 million or more, and then gradually for minor amounts from the years after, until works for a value of less than € 1 million, for which the deadline starts from 1 January 2025. Although this Decree n. 560/2017 is known as the “BIM Decree”, it never mentions the “BIM” term, but it focuses on electronic tools and methods in the building and infrastructure during the design, construction and management phases.

In general, in Architecture and Engineering Construction (AEC) Industry the process innovation through digitalization is usually associated with the BIM methodology/technologies, but the authors, in line with the Italian Decree, consider more focalized the adoption of the Building Lifecycle Management (BLM) [1,2,3] approach to cover the requirements of the asset management during their lifecycle.

On this basis, the present paper consists of the continuation of a previous authors research, named “BIM and PLM Associations in Current Literature” [4], in which the main result is that AEC industry innovation derives from PLM lessons learned. It emerges that it is necessary to extend the BIM technologies across the entire asset lifecycle, especially along the management and maintenance phases, like current PLM holistic applications for complex products, by reaching the BLM vision.

The functionalities already mature PLMs in the complex product manufacturing, should be customized to the specific context of the construction and infrastructure industry to effectively manipulate BIM complex models. Moreover, gaps discovered of learning from PLM “configuration views”, better known as “Product Structure Configuration” since it is still missing a concrete comparison about configuration management in BIM against PLM. The BIM could be to the BLM what the PIM (Product Information Modeling) is to the PLM, and the Product Structure is the missing link [5] in the BIM approach to cover the full lifecycle, calling BLM the solution at the construction industry need for managing the whole lifecycle.

Starting from this assumption and considering the Product Structure as one of the most important features of BIM, the authors analysed the state of the art in this field in both industries, highlighting how the know-how of the manufacturing sector could be utilized in AEC industry.

Following the representation of the Configuration Views in PLM, the final objective is to identify gaps in the current BIM technological process and to propose a customized Product Structure through personalized Configuration views of the construction world to implementing the Building Lifecycle Management (BLM).

The next section of the paper describes the state of the art in the manufacturing complex product regarding Product Structure and PLM, with a focus on “Product Model”, “Product Information Model” and “Product Structure” definition. In Section number 3, the Product Structure in AEC industry is analyzed. In section number 4 the authors try to integrate the Configuration Views in BLM approach. A final section of conclusion and further developments ends the paper.

2 Product Structure in PLM and Complex Products

2.1 Product Structure

A product is a materialized, artificially generated object or group of objects which form a functional unit. The materialization may contain mechanical parts, electrical components, electronic components, hydraulic components and other elements, even computer software and hardware components.

A product model contains relevant information including data, structures and algorithms, where algorithms are the links between user, data and structures [6].

The Product Structure (PS) is a concept well known for those familiar with PLM, typically the environment where complex products are developed, manufactured, used, maintained, disposed or re-introduced in the lifecycle through end-of-life treatments.

Even before PLM became a buzzword, the Product Structure represented one of the possible answers to the issue of product modeling and the needs of development of new products and maintain old ones.

The PS is defined in Krause et al. [6] as “the description of the product breakdown” and as the core of that particular branch of Product Models called “Structure-oriented Product Models” (is therefore a part of a more complete Product Model). The PS as a description of the product breakdown, is the kernel of structure-oriented Product Models. To represent the structure of products, several types of structures such as different bill-of-material structure types, classification structure, structures to describe versions and variants of a product can be used [6].

Saaksvuori and Immonen [7] defines the PS as “a model, which analyses the information on the product and how the information relates hierarchically to other pieces of information (…). It forms the heart of a PLM system, (since) parts, components, documents and assemblies are attached to the product and to each other through it”.

Stark [8] highlights the possible hierarchical characteristic of Product Structures mainly referring to the way of modeling relationships among parts, components, assemblies and the whole product. As the regards information the role of a Product Structures is defining the product requirements throughout its lifecycle and describing “the information that’s needed or is produced at each phase of the lifecycle”.

Different studies ([9,10,11,12]) agree on the hierarchical nature of Product Structures and on their role of describing relations among components, parts, assemblies and products.

Citing again, the study of Saaksvuori and Immonen [7], he specifically assigns five hierarchical levels to products structures, as the example of the ship Product Structure (Fig. 1).

Fig. 1.
figure 1

The generic product structure (product model) of the ship [7]

Full size image

Being an “information construct” [9], the contents that are usually attached to a Product Structure are: 3D models, attributes of products (data, part number material information, manufacturing processes, versions, engineering parameters etc. [12]) and generic classes of information (ingredients descriptions, assembly drawings, part drawings, NC programs, and user manual) [13]. References to the data from various application systems, which might own specific databases, are stored within a Product Structure. Information about order processing, its specific data and formats, access functions and the address within a computer network can be stored within structure-oriented Product Models [6]. It can represent how a particular division in a company needs to visualize the product (i.e. a particular view), for example, the design or the manufacturing point of view [14] or, the product development and engineering sales production and maintenance [7].

PS can be also a way of categorizing product information according to the product lifecycle phases of create, build (as built), support (as maintained) and dispose [9]. For complex product like airplanes, many views of the design phase can be defined at different point in time (as specified, as designed, as designed & as planned, and as prepared) [12].

Hence, the PS is a dynamic entity [14] and it evolves, furthermore, due maintenance activities [15] making the management of PS evolution over time “the most important technology requirement of PLM”.

Many agree that the Bill of Material (BOM) is a particular Product Structure [6, 9], or better, a particular view of the Product Structure [14]. In fact, the Concept of Bill of Material is defined as “A comprehensive list of raw materials, components and assemblies required to build or manufacture a product. Hence it is a detail recipe of product which help to define, build and maintain a product. Since product goes through various lifecycle and interacts with various discipline or domain from Design to Manufacturing to Service to Finance, Bill of material also goes through similar lifecycle and various discipline or domain” [16].

Apart from efficiently showing the information organization depending on the needs of different company divisions or at different points in time, PS can be applied to various purpose: managing product variants [9], keep latest design information to prevent inconvenient design activities [12], cost efficient delivery of customized product variants [17], as base for DMU [18].

In Foufou et al. [19], “multiple Product Structure” are cited: “as-designed”, “as-built”, “as-maintained”, with reference to the activity of “product definition” i.e. the description of product requirements and relationships between parts and assemblies within these multiple Product Structures.

In Saaksvuori and Immonen [7], Product Configuration refers to the process of customizing a product introducing physical property variations. It corresponds to the creation of a Product Structure from the Product Model. Therefore, a “configuration” is a specific Product Structure corresponding to a specific set of variations applied for customizing a generic Product Structure [7]. In this sense the configuration is a method of arrangement [13] and alternative Product Structures can be considered alternative configurations. PS can be called also system architecture, and, together with parts, components and relationships must contain the associated configuration documentation [11].

The configurations should cover the entire product lifecycle, assuming different denominations depending on the associated phase: “as-planned”, “as-designed”, “as-built”, “as-maintained”, “as-disposed of” [19]. The management and update through time of the configuration of a product is called Configuration Management (CM). CM is a formal discipline that aims at assuring the quality and long-term support of complex product through consistent identification and effective monitoring and control of all of this information [13] (Fig. 2).

Fig. 2.
figure 2

Elaboration from [11]

Lifecycle configuration views.

Full size image

The standard ISO 10007:2003, QMS - Guidelines for Configuration Management, describes the four related procedures and list the identification of the Product Structure as part of the first one, i.e. “Configuration identification”. CM originated in the 50’s in military and space contexts to ensure that the detailed specifications produced for these complex products where followed from design to manufacturing and even in the Maintenance Phase [14].

2.2 Product Structure, Product Model and Product Information Model

In this section, it is explored the relation among the terms “Product Model”, “Product Information Model”, “Product Structure” and “Configurations” in contexts that deal with complex products (military, automotive, aerospace) where it can happen that some are used interchangeably, due to their close meanings. In order to clarify these concepts, the definitions found in the literature are examined below.

The starting point of this analysis is the Product Model (PM), which is a container of information. The PM is an information model, i.e. “the representation of structure and semantics of information within a subject area, a formal description of types of ideas, facts and processes which together form a model of a portion of interest of the real world, and which provides an explicit set of interpretation rules” [20]. It is aimed at accumulating all relevant information of a product in digital (or computer interpretable) system/application independent form [6, 7, 21], including its behavior [22]. It describes the Product Structure and the configuration [11] for any lifecycle phase [6, 11]. The ISO 10303 (or Standard for the Exchange of Product model - STEP) defines the information modeling language EXPRESS to outline generic Product Models [19] and make them computer accessible [20]. STEP is supported by a series of Application Standards (AP), AP203 (focused on mechanical CAD) and AP214 (automotive industry) are the most widely applied. It is important to recall that the scope of AP203 revolves around Configuration Management, geometric shapes, Product Structure, and specifications. “It looks at the definition of product as an integration of the specification of its shape, its configurations, and the applicability of its possible multiple definitions to a particular configuration. It defines the exchange of product definitions with 3D shape representations together with the data, which defines and controls the configuration of those product definitions. In this AP, the configuration is about what parts compose a product and how they are composed together” [19].

Krause et al. [6] state the relationship between the Product Structure and the PM saying that the first is a type of Product Model (a structure oriented one), and adding that PMs can also be geometry oriented, feature oriented or knowledge oriented. When more types of PMs are clustered and connected, it is possible to indicate them as an “Integrated Product Model”.

On the other hand, in Saaksvouri and Immonen [7], the PM is a general Product Structure “for a certain individual product”, the author say that in many cases the Product Model is called “generic Product Structure”. The Product Structure is what is created from the Product Model when a product is customized and therefore undergoes a number of variations, this process is the “Product Configuration” [7].

We can also find the term Product Information Model (PIM) both in the industrial language and in literature. For Saaksvouri and Immonen [7], PIM is more a “conceptual model of the product in which information on the product and the connections between various information elements and objects are analyzed at a general, generic level”. Even if merely conceptual, the PIM should describe product-information relationships formally and carefully. An example of PIM is the one proposed by NIST [23], which includes geometry, structure and assembly. Van Renssen [22] adds the lifecycle concept to the PIM, in the sense that it can collect “facts about a product” and its operations under various conditions “including requirement specification, process and mechanical design (1,2,3D), cost estimation, procurement, fabrication, construction, commissioning, start-up operation, control, inspection, maintenance and demolition”. One step of creating a PIM is defining its Product Structure.

3 Product Structure in AEC Industry

Van Nederveen et al. [24] recall that in the 80s and 90s what we now call BIM was referred as “Building Product Modeling” and “Product Modeling Of Buildings”, showing the close relationship with the general product modeling applied in aerospace, automotive and mechanical engineering. The information models (IFC) expressed in EXPRESS computer readable language define the meaning of the data incorporated into the Product Model thus generating information.

In AEC industry the Product Structure is linked with the physic and functional breakdown of the building or the infrastructure project. The software tools commonly used are focused on the project structure organized in hierarchical levels without considering the evolution of the product during its life cycle. For example, in a top-down vision, the classes of the technological unit are the first level of a Work Breakdown Structure (WBS), Technological Unit are the second level, Technical Element classes as the third level. Further levels of decomposition, although not detailed in the individual items, may correspond, for example, to technical elements [25].

In UNI 11337-1:2017 regulation, the spatial decomposition of the asset informative structure is Building/Infrastructure, System, Sub-System and Component.

These examples of Product Structure do not correspond to the lifecycle information management of the building or infrastructure.

In general, the concept of configuration view in the AEC field is not as structured as in the manufacturing sector, and it is often missed in BIM software tool, which includes only an organized Product Structure at the design stage. For example, the functionality of checking/comparing the “as built” to the “as designed” configuration views of the Product Structure is missing.

Much work needs to be done in this direction in a BLM vision, even though Gielingh [21] had already stressed the importance of product information management, storage and control with computer systems integration, since 1990, using standards and organizing the “Product Structure & configuration management”. Gielingh introduced “the General AEC Reference Model (GARM)”, developed for AEC applications within the ISO/STEP standardization effort, to facilitate data-exchange between computer-applications for design, production and maintenance of the AEC products [26], in the full lifecycle of the building or infrastructure. In this sense, the GARM lists seven fundamental “stages” in the product lifecycle: “as required, as designed, as planned, as built, as used, as altered, as demolished”, recognizable for the authors as the Configuration Views of the Product Structure.

In Eastman [27], he recovered and adapted the classification proposed by Gielingh, structuring the lifecycle according to its major transition points (Fig. 3). Eastman’s lifecycle classification consists of six consequential phases and six resulting transitions connected by information flow, the integration and the automatization of linear processes. Furthermore, several others scholars ([28,29,30,31]) focused on “Building Product Models” as an integrated representation to be taken on for translating information.

Fig. 3.
figure 3

Elaboration from [27]

One classification of the building lifecycle, addressing both phases and transitions.

Full size image

Another representation of the digital assets lifecycle evolution arrives from Ingram [32], which integrates data and model driven processes. This is organized in four group: “As Sold”, including estimating, cost and change management; “As Designed”, including design intent, design, specifications and geometry; “As Built”, including integrated plan, 4D construction, work packages; “As Maintained”, including as built/as maintained model, lifecycle visualization, smart work execution, IIoT and digital twin.

In AEC Industry, the use of the Configuration Management provides a means of tracking how the customer’s expectations generated at the beginning of a project are turned at the completion of the project. In this field, different studies ([33, 34]) show how the CM approaches in complex engineering projects need further researches.

All these previous studies can become the foundation of an integrated Product Structure for the Building Lifecycle Management based on the lesson learned from holistic PLM platforms and relative configuration views, namely, Eastman’s transitions.

4 Integrating Configuration View in BLM

Starting from the previous paragraphs, this research introduces the configuration views in the Building Lifecycle Management focusing on a Product Structure that enables the archiving of all the information, during the lifecycle in a circular vision, as reported in Boton et al. [5], in which the comparison between the PLM and BIM approaches are based on the standpoint of the Product Structure (PS).

Being Product Structure mostly arbitrary [9], the important thing is to make it consistent throughout the lifecycle in order to create a BLM Product Structure. To this end, it is proposed a Building/Infrastructure Product Structure in Fig. 4 that integrates the Product Structure of Saaksvuori and Immonen [7] and the information reported by Building SMART International [28] for domains. In detail, the System level coincides with the Domain Specific data schemas. The domain-specific data schemas contain final specializations of entities.

Fig. 4.
figure 4

Elaboration from [7] and [35]

Building/Infrastructure product structure.

Full size image

The Product Structure enables a dynamic Product Information Model that enriches the Product Model during its lifecycle. For the authors the “Configuration Views”, of the PS, can manage Building/Infrastructure data, updating and archiving information over time (Fig. 5), in a suitable manner for each specific lifecycle phase.

Fig. 5.
figure 5

Building/Infrastructure Lifecycle and corresponding Configuration Views.

Full size image

Circularity consists in focusing on the digital twin in the common data environment BLM that includes document management, three-dimensional parametric modeling via BIM, etc., and it is enriched over the lifecycle of the Building/Infrastructure, including through the use of IoT, RFID or in situ sensors.

5 Conclusions and Further Developments

The purpose of this paper was to summarize the meaning of Product Structure and Product Model for both traditional complex industries and the construction industry to formulate research questions in a precise manner to guide further developments. In particular, this study is part of two doctoral research focused on the adoption of BIM methodology for the management of different contexts, namely Wastewater Treatment plants and Social Housing districts.

The use of different Product Structure lifecycle views, optimized according to the specific life-cycle phase of an infrastructure or building, is not widespread in current practice, despite the fact that some sources have been advocating them in literature for a long time [24, 26].

Given the large number of operations involving existing buildings and structures and their long lifecycle, BIM software tools and methodology should be more optimized for after construction phases. The Asset Information Management, organized through the Product Structure and the Configuration (Management) Views is the backbone of the Building/Infrastructure Lifecycle, because contains data regarding assets in a centralized environment, integrating as designed, as built and as maintained data. This vision enables the Building Lifecycle Management including Standards, like ISO 55000. The Configuration Management, in fact, aligns and synchronizes BOM data and lifecycle information.

The BLM approach, as a “single source” for all processes and metadata, is useful for owners that have to support a portfolio of buildings or civil infrastructure and needs to support both facility management and real estate management, including maintenance management and environmental sustainability.

Further research will be focused on modeling real-life example of construction life-cycle views and testing them in real contexts. In the light of these arguments, the following research will be gathering the requirements for as-maintained and as-used views for a wastewater treatment plant and social housing located in Puglia (i.e. an Italian region) from the related stakeholders and transforming them in functionalities of a BIM-integrated piece of software to be tested. Other further research will be on how to reconcile a view of the Product Structure and the link with the underlying standard IFC.