Building Lifecycle Management System for Enhanced Closed Loop Collaboration
- 2.4k Downloads
In the past few years, the architecture, engineering and construction (AEC) industry has carried out efforts to develop BIM (Building Information Modelling) facilitating tools and standards for enhanced collaborative working and information sharing. Lessons learnt from other industries and tools such as PLM (Product Lifecycle Management) – established tool in manufacturing to manage the engineering change process – revealed interesting potential to manage more efficiently the building design and construction processes. Nonetheless, one of the remaining challenges consists in closing the information loop between multiple building lifecycle phases, e.g. by capturing information from middle-of-life processes (i.e., use and maintenance) to re-use it in end-of-life processes (e.g., to guide disposal decision making). Our research addresses this lack of closed-loop system in the AEC industry by proposing an open and interoperable Web-based building lifecycle management system. This paper gives (i) an overview of the requirement engineering process that has been set up to integrate efforts, standards and directives of both the AEC and PLM industries, and (ii) first proofs-of-concept of our system implemented on two distinct campus.
KeywordsProduct Lifecycle Management Internet of Things Building lifecycle management Interoperability Quality Function Deployment
Building Information Modeling (BIM) is not a new concept, but rather one that is playing an increasingly larger role in the architecture, engineering and construction (AEC) industry. From design to construction, the concept of BIM has been a feature across many industries for nearly 30 years . It remains a strong and important player in the field because of its ability to allow designers to go beyond representing the physical space of a new or retrofitted building to the intrinsic properties of the structure as well. BIM is not just about the design of new buildings, it also plans for years of use. This is because designing, scheduling, constructing and evaluating a building is done in the BIM model long before any construction actually takes place. Although it is true that the future of the construction industry is digital and that BIM facilitating tools and standards (e.g., IFC) will foster long-term facility management, there are still technological and managerial challenges ahead . The nature of these challenges depend on the building lifecycle, which is generally defined as a three-phase process : (i) Beginning-of-Life (BoL) including design, manufacture and construction of the building; (ii) Middle-of-Life (MoL) including its use and maintenance; and (iii) End-of-Life (EoL) including its disposal and recycling. Our research puts special emphasis on post construction challenges.
One of the major challenges after the delivery of the building (i.e., when starting MoL) lies in the difficulty to close the information loop between all phases of the building lifecycle. For example, due to the lack of system integration and other factors such as the non-maturity of the IoT (Internet of Things), it is not that easy to collect, capitalize, and share information/knowledge acquired from MoL (e.g., during use and maintenance activities) with other building lifecycle stakeholders, and vice-versa . This is all the more important since such information could result in enhanced decision-making in BoL (e.g., to improve the next generation of buildings and boost the innovation process by capturing new business and user needs), or in EoL (e.g., to guide decision-making about the reuse of components by having information related to the building use conditions). The establishment of such a closed-loop information/collaboration structure throughout the asset lifecycle is not only facing the AEC industry but other sectors, too, e.g., manufacturing where concepts such as Closed-loop PLM 1 [13, 14] emerged over the last decade.
Given the above, the contribution of our work is twofold: (i) design/develop an open & interoperable building management system that integrates efforts, outcomes (technologies, standards…) and directives of both the AEC industry and adjacent sectors such as Closed-loop PLM and IoT; (ii) set up an effective and evolutive requirement engineering framework for ensuring successful system component development. Sections 2 and 3 deal respectively with these two contributions, Sect. 4 presents proofs-of-concept of our system, conclusion follows.
2 When BIM Meets Closed-Loop PLM
2.1 Whole Lifecycle Approach
Managing vast amounts of disparate information throughout an asset lifecycle (car, airplane, building…) is an enormous challenge for organizations, particularly in terms of enforcement and compliance. Information governance enforces desirable behavior in the creation, use, archiving, and deletion of corporate information. By closing the loop, rules and policies are defined, policies are managed and enforced, authorized records are accessed when and as needed, and metrics are available to audit the current rules and policies. All this provides a way to continuously assess and update the process for optimum results.
As mentioned above, the concept of closed-loop PLM (or CL2M) has developed theories and tools to enable closing the information loop between multiple lifecycle phases [11, 15]. This concept emerged from the PROMISE EU FP6 project, where real-life industrial applications required the collection and management of product instance-level information for many domains involving heavy and personal vehicles, household equipment, etc. Information such as sensor readings, alarms, assembly, disassembly, shipping event, and other information related to the entire product lifecycle needed to be exchanged between products and systems of different organizations. Based on the needs of those applications, requirements for data exchange were identified and, as no existing standards could be identified that would fulfill those requirements without extensive modification, new messaging interfaces were proposed (see e.g. ). Those specifications have since then been further developed by the IoT WG of The Open Group and implemented by several EU project consortia (e.g., LinkedDesign FP7, bIoTope H20202). Recently, The Open Group published those specifications as two distinct – but complementary – standards, namely the Open Messaging Interface (O-MI) and Open Data Format (O-DF) standards .
Our research work and contribution originate from this state-of-the-art with the specific aim of developing a user-friendly building lifecycle management system relying on open and interoperable standards like O-MI/O-DF. To this end, it is of the utmost importance to select and/or set up an effective and evolutive requirement engineering framework for the development of successful system components, especially in new and cross-domain contexts, as is the case in our study (combination of standards/directives from the AEC/BIM and Closed-loop PLM & IoT sectors). The next section briefly discusses such a requirement engineering framework.
2.2 Requirement Engineering Framework
Requirements inception: start the process (business need, market opportunity…);
Requirements management: to capture new needs/contexts over time.
In our context, customer needs must be transferred into product and process requirements without necessarily developing all possible technical characteristics, but only the ones that fulfil the needs for efficient closed-loop information and collaboration in a building’s lifecycle context. Let us add that the production activity is supposed to be traceable back at least indirectly to customer requirements.
Given this, our research work develops an hybrid framework based on the synthesis of well established techniques from software engineering and management theory and tools . An overview of this hybrid engineering framework is provided in Fig. 2, which combines (i) a functional analysis (using the Octopus diagram); (ii) a requirement prioritization technique (using AHP – Analytic Hierarchy Process) ; (iii) a method that transforms prioritized requirements into quantitative parameters/specifications (using QFD – Quality Function Deployment) ; and (iv) a spectral algorithm method for clustering specification conflicts identified through the QFD matrices . These phases are followed up by the software development phase, as well as the definition of KPIs (key performance indicators) to assess whether the system is free of defects, meets the user needs that may evolve over time, and so on. In the context of smart buildings, similar approaches for the development of smart home components was followed, e.g. Durrett et al.  used QFD to effectively satisfy customers’ needs as part of an integrated smart home environment. Popescu et al.  used QFD combined with AHP to identify a set of functions of lighting, heating, security, furniture, etc., that could have a critical contribution to the independent living capacity of people with special needs, if receiving smart abilities. However, none of these frameworks and analyses consider needs related to the whole building lifecycle, along with the imperative to enable closed-loop information and collaboration among distinct lifecycle stakeholders.
As a consequence, an appropriate hybrid engineering framework that enables to integrate such needs, and appropriate technology enablers from the AEC and PLM industries, is defined and proposed in this study, as will be discussed in Sect. 3.
3 A Hybrid Engineering Framework for Development of Building Lifecycle Management System Components
Primary & Constraint Functions (PF-CF) formalized through the octopus diagram
Such a requirement ranking, associated with the priority weights, are used as input of the QFD. QFD is both a requirement definition and conceptual design tool that systematically documents customer needs, benchmarks, competitors, and other aspects, and then transforms the list of prioritized requirements into design specifications. The QFD methodology flow involves four basic phases that occur over the course of the product development process. During each phase one or more matrices are generated (cf. block in Fig. 2 entitled “Turning initial requirements into specifications using QFD”), where the specifications (including their respective weight) resulting from the QFD matrix of phase n feed the matrix of phase n + 1. Figure 3 provides insight into the specifications resulting from the first QFD matrix, which all bring first technological or scientific enablers to fulfil one or more requirements. For example, Fig. 3 shows that the two most important enablers with respect to our initial requirements are (i) Data & service discovery: to enable any building stakeholder to discover and access, when and as needed, information sources and associated knowledge; (ii) Dynamic service composition: to enable building end-users to create their own services using a portfolio of “processing blocks” (including diagnosis, maintenance prediction, event-detection, storage…).
As highlighted in our requirement engineering flow (see Fig. 2), a spectral method for clustering conflicts that arise from the QFD matrices’ roof3 is further applied, followed up respectively by a validation phase of the specifications and the development of the software components. To guarantee that our system remains competitive over the short and long term, specific Key Performance Indicators (KPIs) are defined to assess in a quantitative manner several aspects such as the software bugs, the user satisfaction and new needs, etc. Although not presented in this paper, it is important to note that these KPI metrics continuously feed the QFD matrices (see Fig. 2), thus helping to produce new releases of the system/software with added or rectified features.
4 Proof-of-Concept – Building Lifecycle Management System
The first releases of our building lifecycle management software have been supplied4, enabling any developer to deploy and instantiate it in his/her own environment/buildings. Two proofs of concept of such an instantiation are today available online, namely at Aalto Smart Campus5 and Sophia Antipolis Smart Campus6.
Current vs. Future building lifecycle management system features
It is still challenging to close the information loop between multiple building lifecycle phases (e.g., by capturing information and knowledge from MoL for re-using it in BoL and/or EoL processes), which opens up opportunities for enhanced decision-making and cost saving (e.g., in facilities management). Our research addresses this lack of closed-loop system by developing an open, interoperable and integrated Web-based building lifecycle management system that integrates efforts, directives and technological enablers from both the AEC and PLM/IoT. This paper gives insight into the requirement engineering framework that has been set up for the development of system components, as well as the first proofs-of-concept of the system implementation (running on two distinct campus).
The research leading to this publication is supported by the National Research Fund Luxembourg (grant 9095399) and the EU’s H2020 Programme (grant 688203).
- 2.Aram, S., Eastman, C.: Integration of PLM solutions and BIM systems for the AEC industry. In: Proceedings of 30th International Symposium of Automation and Robotics in Construction and Mining, Montréal, pp. 1046–1055 (2013)Google Scholar
- 5.Azhar, S., Khalfan, M., Maqsood, T.: Building information modeling (BIM): now and beyond. Constr. Econ. Build. 12(4), 15–28 (2015)Google Scholar
- 15.Laplante, P.A.: Requirements Engineering for Software and Systems. CRC Press, Boca Raton (2013)Google Scholar
- 16.Popescu, D., Popescu, S., Bacali, L., Dragomir, M.: Home “smartness”-helping people with special needs live independently. In: International Conference of Management Knowledge and Learning and Technology Innovation and Industrial Management, Romania (2015)Google Scholar