Development of a BIM and IoT-Based Smart Lighting Maintenance System Prototype for Universities’ FM Sector

Abstract

Reactive maintenance (RM) is a core service of the operation and maintenance (O&M) phase, the most prolonged and costly within the building lifecycle. RM is characterised by inefficient asset information and communication management, impacting critical FM problems and users’ experience. Building information modelling (BIM) and Internet of things (IoT) has enabled the development of digital twins, moving facilities management (FM) from a reactive approach towards a predictive one. Although previous studies have investigated the application of such technologies to FM, there is a lack of understanding on procedural issues related to its implementation in FM and RM. This research aimed to characterise strategies and decisions involved in prototyping a BIM and IoT-based smart-lighting maintenance system and identify its potential impacts on universities’ maintenance processes. The adopted research strategy and data collection methods involved prototyping, questionnaires, and interviews. The results show a high level of complexity in converging maintenance needs and technological abilities for FM and the importance of procedures and standards at organisational and industry levels. Moreover, it evidenced that the automation of functions and the centralisation of information enabled by BIM and IoT can optimise service provision, generate environmental and efficiency gains, and improve users’ safety and satisfaction.

1. Introduction

The architecture, engineering, construction and operations (AECO) sector consumes the largest number of resources of all industries. Resources are used within all lifecycle phases, but the operation and maintenance (O&M) phase is inherently the main contributor [1]. The O&M phase is often characterised by wasteful processes such as reactive maintenance (RM) services performed on a “firefighting” basis [2] and informed by inefficient asset information datasets. In addition to waste, such a managerial approach prevents the optimal resolution of critical building problems and negatively impacts users’ experience and businesses performance.

Addressing such issue, building information modelling (BIM) and Internet of things (IoT) have been driving the sector towards more sustainable and predictive practices, fostering the concepts of “smart facilities management” [3], “smart maintenance” [4,5,6,7] and smart lighting [8].

Providing rich digital databases of buildings’ systems and spaces, BIM enables the integration and automation of FM processes [1,9,10], supporting the collaboration among stakeholders over building lifecycle [9,11,12] and improvements in the quality and performance of buildings [13,14]. On the other hand, IoT is comprised of the network connecting physical objects or things to the Internet [15] and enables the real-time understanding of buildings’ components and their operation, increasing the quality of information and efficiency of FM services [16,17,18,19]. Furthermore, the integration of both technologies fosters the development of digital twins—defined as “a digital replica of a building or part of a building, that can mirror the way the actual building performs” [20] (p. 107)—enabling the capturing of changes in actual buildings, monitoring of the performance of their components and systems, and generation of data for the prediction of performance behaviour and failures [21,22].

Despite the potential of digital twins and BIM and IoT-based systems for improving the efficacy of FM and RM services, such a topic is still emergent within the AEC industry and academia [23,24,25]. Although a plethora of devices and systems are available on the market (e.g., smart homes and building management systems), technical limitations hamper the implementation of smart systems for FM purposes (i.e., a lack of integration with other FM systems and flexibility for the addition of new capabilities, and restrictions for data analysis) [26,27,28,29,30,31]. In general, such systems are built from the perspective of the IT developers [32], missing the contribution of the FM team on relevant technology, process, and policy requirements for its implementation. As a result, implementation tends to be unsuccessful, wasting financial and human resources and opportunities to improve business performance. This scenario is even more relevant for public organisations (e.g., universities and hospitals) facing budget restrictions for investments in technology despite the increasing service demand.

Previous studies have addressed the application of BIM and IoT for FM [33,34,35], particularly for RM. For instance, refs. [36,37] have investigated approaches for integrating BIM, IoT and FM systems for a series of distinct applications over the O&M stage. Similarly, ref. [38] have explored strategies for a smart-FM system based on integrating IoT, augment reality and virtual reality technologies with a BIM model to support maintenance field work. In addition, ref. [39] have proposed a mobile automated 2D barcode and BIM-based FM tool for acquiring and tracking maintenance information during inspections and ref. [40] have designed a theoretical framework for integrating indoor tracking technologies and BIM models to support maintenance teams.

As exemplified above, most investigations have focused on acquiring and installing components. In general, research on the procedural issues required for operating and maintaining such components over time is embryonic [12,41,42]. There is a lack of understanding of interdisciplinary and inter-functional decisions and steps involved in the conception, development, and implementation of BIM and IoT-based smart-systems for FM and maintenance purposes. Given the above issues, the following questions were proposed:

• How can technical and functional requirements and strategies for prototyping be established?
• How can BIM FM requirements be established and IoT devices and tools integrated, generating an effective smart-maintenance system?
• How can intelligence be generated from real-time data supporting maintenance decision-making?

This research aimed to characterise strategies and decisions involved in prototyping a BIM and IoT-based smart-lighting maintenance system, identifying its potential impacts on the maintenance process. The results demonstrated the complexity in converging maintenance sector needs and technological abilities in such an interdisciplinary project and the importance of procedures and standards at organisational and industry levels. Moreover, they evidenced that the automation of functions and centralisation of information enabled by BIM and IoT solutions can optimise service provision, generate environmental and efficiency gains, and improve the safety and satisfaction of maintenance staff and building users.

2. Materials and Methods

In this study, an interdisciplinary team of architects, engineers, facilities managers and IT professionals contributed to developing a smart lighting maintenance system prototype, conducted between July 2020 and April 2021 as part of the main author’s Doctoral research. A Brazilian University (BR University) building complex was adopted as a reference for constructing the prototype. The lighting system within a student accommodation was the object of prototyping addressing the agenda of energy efficiency and smart-buildings [13,41,43] and a critical scenario identified in our previous investigation [44]. Moreover, the eight stages of the traditional reactive maintenance (RM) process model (i.e., (1) fault detection, (2) reporting and feasibility analysis, (3) location and inspection, (4) diagnosis and planning, (5) repair, (6) check-out, (7) delivery, and (8) feedback and closing the request) provided by [44] supported the identification of potential impacts of the prototype on maintenance performance (Figure 1).

Prototyping was the adopted research strategy for knowledge generation [45]. Commonly employed in business and engineering industries to support the development of products according to the users’ needs [46,47], prototypes were here comprehended “as vehicles for research about, for and through design” [48] (p. 262), enabling the iterative learning between the participants of the design project. Therefore, a five-stage systematic process based on [48,49] was proposed to develop the system involving planning, development, implementation and testing, results and assessment, and theory generation, as shown in Figure 2.

Planning activities (Stage 1) were conducted to define the prototype scope, requirements, assumptions, and an experimental plan outline. The functional and technical requirements and strategies were established with the support of university maintenance experts, AEC and IT professionals, consulted through online questionnaires and interviews. The experimental plan involved the identification of variables to be tested, the development of test settings and protocol, and the definition of performance measurements and a data analysis strategy.

In the development (Stage 2), activities were conducted to generate conceptual, processual, and technological solutions, involving the construction of the architecture of the prototype, the sensor, and the BIM model. The prototype was then implemented and tested (Stage 3) in an experimental environment (i.e., a residential bedroom) due to restrictions in place for COVID-19.

The test protocol assessed the prototype capability for effectively managing data and providing accurate information, aiming to identify defects and failures on the prototype components [50]. A qualitative analysis of the results supported the assessment of prototype performance (Stage 4). A descriptive evaluation of the prototype was also conducted to demonstrate its potential impacts on the university maintenance processes. Finally, the discussion of the findings led to theory generation, identifying limitations and contributions of the process to knowledge (Stage 5).

A detailed description of the procedures involved in planning, development, and implementation and testing is presented below.

2.1. Planning

2.1.1. Definition of the Scope

The smart lighting maintenance system prototype aimed to deliver accurate and anticipated lighting performance information to support university maintenance teams in making decisions. The prototype’s scope included:

• Automatically detect and report current and developing abnormalities by generating notification messages triggering maintenance service response.
• Automatically populate real-time information from the sensor’s lighting central database into the SmartLab app and the BIM model parameters.
• Visualise updated lighting information on BIM and IoT interfaces.

A four-step theoretical framework of the prototype (Figure 3) was developed as a conceptual perspective of the system, based on the flow of Lighting data and information over the process. The SmartLab system and mobile application built by the researchers from the Distributed Systems and Concurrent Programming Laboratory (LaSDPC/ICMC/USP) for smart devices control (e.g., lighting and HVAC) [51] was used for the development of the prototype.

The collection step consisted of creating dynamic and static data from different sources. Dynamic data included lighting levels (V) and operating times (h) collected from sensors on the lighting. In addition, a time series was generated with lighting performance historical records. Static data refers to the permanent aspects of the lighting system (e.g., the number of lightings and lamp specification), the monitoring system (i.e., ID, type, location), and the maintenance service, all commonly stored within FM statutory documents (e.g., floor plans, equipment manual, and maintenance spreadsheets). For this study, the information was centralised in a BIM model developed in Autodesk Revit 2021 for maintenance purposes.

The second step started with transmitting the generated raw data to a cloud environment. Data were stored, processed, and analysed from the cloud repository to identify current and developing abnormalities and lighting information. In the third step, the information from the cloud environment was visualised by the maintenance team on distinct interfaces, depending on the users’ needs and the system’s behaviour. For instance, SmartLab mobile and E-mail account focused on real-time information and notification messages, while BIM interfaces provided historical records. Finally, the fourth step was to manage the lighting performance information, delivered under alert or abnormal behaviour through notification messages. Such information triggered maintenance services, supporting the anticipated opening of work requests within the CAFM software and the problem solving before disruptions to university activities occurred.

2.1.2. Establishment of Technical and Functional Requirements and Assumptions for Development

The definition of technical and functional requirements (such as automatic detection and report of failures and the use of standardised components) was supported by the findings of the questionnaires and interviews. Mechanisms for communicating maintenance data and information generated by the prototype with the existing FM tools were discussed with an IT professional of the BR University FM sector, focusing on detecting and reporting current and potential failures. The development of one web service and the creation of an e-mail notification were the two strategies drawn by the research team.

The second mechanism was adopted for this study due to its innovative, flexible, and agile aspects, since it (i) addresses the broad technological innovation process faced by the organisation, considering the implementation of modern and flexible technology for all maintenance sectors; (ii) provides a flexible alternative to trigger maintenance processes, thus supporting the generation of work requests either automatically, via the open-source ticket request system (OTRS), or manually, in the current CAFM software; (iii) can be developed by the research team with available time, knowledge, and technological resources, whereas the web service development would require new investments; and (iv) can be validated by the researcher team through tests, differently from the web service, which would require the development of a quality environment unavailable in the current CAFM software.

The following assumptions supported the prototype development according to users’ requirements, technical and process-related requirements for actual prototype implementation, and inherent limitations: the BR University FM sector is the target user of the prototype, although the solution must apply to other organisations; the FM sector has implemented BIM for maintenance and obtained BIM models of the university assets, including accommodations buildings; the maintenance team has access to the SmartLab mobile application as well as the infrastructure and capabilities to manage BIM and IoT devices and software; building users are aware of the system’s abilities; the monitored student bedroom has wireless access.

2.1.3. Establishment of FM BIM Data Requirements

The establishment of FM BIM data requirements in the early stages of the design process is essential to support the development of BIM models and, accordingly, digital twins for FM purposes. In this work, a BIM model data structure determined the required attributes of the lighting (called “parameters” in software Autodesk Revit), thus supporting maintenance activities [52] and integration with CAFM and IoT tools. In addition, data requirements for O&M (i.e., maintenance history, specifications of replaced components, vendor data, location ID, etc.) identified within standards and previous studies [40,53,54,55,56] supported the proposed structure. As shown in

Table 1. Synthesis of prototype requirements.

Set	Parameter	Name	Description
Room	Identity Data	Room ID	STE_B1_101
		Room Name	Bedroom 101
	Dimensions	Room Length (m)	4.00
		Room Width (m)	2.80
		Room Height (m)	2.80
	Lighting	Reflexion Factor (Ceiling/Wall/Floor)	70%/50%/20% *
		Maintenance Factor	0.8 *
		Median Illuminance in the Workplace (E) (lux)	300 **
		Environmental Median Illuminance (E) (lux)	150 **
		Number of Lighting Fixtures	1
Lighting	Identity Data	Identification Code (ID)	L101
		Model	SM461V W17L169
		Manufacturer	Philips
		URL	http//:www.philips.com.eg ***
		Description	Surface-mounted
		Material (Housing)	Steel
		Installation Type	Mounted
		Cost (R$)	250.00 *
		Lighting Priority Level (LPL)	LPL1
	Dimensions	Length (mm)	1685.00
		Width (mm)	171.00
		Height (mm)	85.00
		Assembling Height (m)	2.80
	Electric Data	Lamp Model	LED40S/840
		Voltage (V)	220–240 V
		Initial Input Power (W)	30
		Nominal Lifetime (h)	25.000
		Apparent Load (VA)	21.00 VA
	Photometrics	Light Loss Factor	1
		Initial Luminous Flux (lm)	1350
		Initial Colour Temperature (K)	6500
		Length of Emission Rectangle (mm)	66
		Width of Emission Rectangle (mm)	1135
		Light Source Colour	White
Lighting sensor	Dynamic Information	Performance Status	Normal/Alert/Abnormal
		% Estimated Lifetime	25%
		Link to Historical Data	http://andromeda.lasdpc.icmc.usp.br:5005/generateReport ***
	Identity Data	Sensor Identification Code (ID)	S101
		Sensor Type	Lighting Dependent Resistor (LDR)
		Sensor Measurement Unit	Volts (V)
		Sensor Location	STE_B1_101
		Sensor Assembling Height (m)	2.75
Maintenance Service	Date Record	Date of Lamp Installation	7 February 2020 *
		Date of Last Maintenance of Lamp	10 October 2019 *
		Date of the Last Cleaning of the Lamp	5 April 2020 *

Note: * illustrative data; ** established according to ABNT (1992), considering the observer’s age under 40 years, the precision of the task as an essential factor, and task background reflectance between 30 and 70%; *** accessed on 7 October 2021.

, the structure comprises four parameter sets: room, lighting, lighting sensor, and maintenance.

The first set is related to the room parameters (i.e., identity data, dimensions, and lighting), defined according to [57], and the second refers to the lighting parameters (i.e., identity data, dimensions, electric data, photometric). Other lighting parameters were based on the BIM family of Philips LED surface mounted lighting, model SM461V W17L169 [58,59]. The third set is related to the lighting sensor parameters (i.e., dynamic and identity data), whereas the fourth refers to data record maintenance services (i.e., date of lamp installation, maintenance, cleaning), as proposed by [54]. Autodesk Revit 2021 software was selected as the BIM platform since it offers the necessary modelling tools and has a free educational license.

2.1.4. Outlining the Experimental Plan

An experimental plan was outlined to support the development, testing, and assessment of the prototype performance. Primarily, it involved the definition of the monitored object, for instance, the LED lamp, and the testing variables, which were the lighting level (V) and operating time (h). Next, a rationale for the assessment of lighting performance was defined, based on the definition of LED nominal lamp lifetime proposed by [60], as follows:

• Normal status: corresponds to lighting levels greater than or equal to 70% of the initial value;
• Alert status: corresponds to lighting levels greater or equal to 50% and less than 70% of the initial value;
• Abnormal status: corresponds to lighting levels less than 50% of the initial value.

In addition, a criterion to define the % expected lifetime was proposed, considering the ratio between the measured operating time and the nominal lifetime.

Finally, test settings and protocols were developed. The prototype was implemented in the experimental environment for assessment from March to April 2021. A protocol for the test and assessment of results was then developed. Section 2.3. presents the tests applied, the components, functionality criterion and purpose, activities undertaken, performance measurement, and categories for assessing results.

2.2. Development

In the development stage, the physical and analytical dimensions of the prototype were constructed. The architecture of the prototype (Figure 4) was primarily generated, focusing on the relationship and data stream among hardware and software components to support data collection, transmission and processing, visualisation, and management. The architecture of the SmartLab prototype described by [51] was used as a reference, and commercial hardware (i.e., sensor, lighting, lamp) and software (i.e., Revit, Dynamo) components were incorporated for addressing the application proposed in this research. Principles of the microservice architecture structure style were adopted to develop a resilient, scalable, and heterogeneous prototype system [51].

As depicted in Figure 5, the integration between BIM and IoT used BIM tools’ APIs and relational databases, according to the proposition of [24]. Dynamo visual programming plugin was the bridge between Autodesk Revit and IoT database, as described by [21,33,61,62,63,64,65]. The IoT ecosystem and the CAFM systems were integrated by creating an e-mail notification to the maintenance sector triggering the opening of a service order request. The e-mail notification was designed to play two roles, depending on the CAFM system adopted, for instance, as an indirect link, providing information for manual addition into the system database, or as a direct link, automatically opening a new service request.

In addition, a logic analysis from the collection of lighting level (V) and operating time (h) data for the visualisation and management of information aimed at the generation of relevant information from real-time data, as shown in Figure 6.

2.2.1. Data Collection

The physical prototype was built in-house for the collection of dynamic data. The development of a customisable solution was due to budget restrictions and the necessity of free access to data. The prototype comprised three parts: lighting interface, core, and lamp interface, as shown in Figure 7.

Part 1 establishes the interface between the lighting and the core. A lighting male socket plugged the prototype into the lighting and provided an electricity supply. Part 2 comprised the core components of the prototype (e.g., microcontroller unity (MCU), lighting dependent resistor (LDR) sensor, resistor, rectifier, and relay). A round plastic container internally held the MCU, electronic components, and cables and externally attached the sensor. The sensor was positioned on the edge of the bottom surface of the container. Lastly, Part 3 establishes the interface between the core and the lamp. A lighting female socket plugged the lamp.

The sensor was calibrated to instantly collect lighting level (V) data whenever the lighting was turned on, thus covering situations in which the lighting was used for a few seconds or many hours. By gathering only such essential data, the sensor avoided overloading the database, thus improving the system performance. In addition, the system was also calibrated to collect data when the lighting was turned on and off, generating the operating time (h).

A BIM model of the bedroom where the lighting was located was developed as a centralised dynamic and static data database for maintenance purposes. This study focused on modelling essential geometric and non-geometric data for performance analyses (i.e., lighting and sensor characteristics and basic geometry of the room), generating a more dynamic and lighter model—as recommended by the literature [10,40,52,55]. The BIM model data structure shown in Table 1 was the reference for modelling in Autodesk Revit 2021 (see Figures 9, 14 and 15).

2.2.2. Data Transmission and Processing

Initially, two microservice groups were developed to control the lighting and visualise its performance information. The first group was integrated by “microservice of authentication and data extraction” and “status microservice” and connected the user and the prototype. Initially, data on the available building, floor, rooms, and devices (e.g., Students’ Accommodation, 1st floor, Bedroom 1, Sensor ID S101) were requested from the Postgres database. Next, data on the last device status (i.e., on-off) and the lighting performance status (i.e., lighting level (V) and operating time (h) were requested from the MongoDB database. The second group (i.e., “light microservice”) refers to the lighting control.

Two new microservices were built to address this research scope. The “alert microservice” was developed with two functionalities, i.e., analysis of lighting level data to detect performance abnormalities and notification of current and developing abnormalities for the user. The “if statement” rationale for the classification of lighting performance (i.e., normal, alert, and abnormal status) was coded into the microservice, thus providing status information for user notification. In sequence, two distinct approaches were adopted to notify abnormal and alert statuses according to the user interface—a pop-up message was proposed for SmartLab mobile application, and an e-mail message was developed for the e-mail account.

Complementary, the “historical data microservice” aimed to provide historical lighting performance records, including a time frame, lighting level, and operating time. The data were delivered in a .json file, a lightweight format for data exchange that can be opened on a web browser (i.e., Google Chrome) or imported into a Microsoft Excel spreadsheet. In addition, the file was requested by the “microservice of authentication and data extraction” for further communication with the BIM model.

Finally, Dynamo visual programming plugin was adopted to read, process, and store lighting performance real-time and historical data in the Revit environment. Commonly used in building design for parametric modelling complex structures, Dynamo is also applied for linking the BIM FM model with external data (i.e., sensor measurements, work orders) [21,33,61,62,63,64]. In this research, Dynamo was selected due to its versatility, user-friendliness, and availability of the necessary tools for this prototype development. Figure 8 shows a broad view of the Dynamo program flow, integrated by two functional groups, namely (1). obtaining real-time lighting data and information (i.e., performance status and % estimated lifetime), reading and updating it in the lighting model parameters; and (2) colouring the lighting based on real-time performance status information status.

In Group 1, a code imported information from the Microservice of authentication and data extraction to the BIM model. First, a set of basic nodes were employed to select the target element in the model and its parameters to be updated (i.e., lighting identification code (ID), sensor identification code (ID), performance status, % estimated lifetime, and link to historical data records), and then, customised Python nodes were created to request real-time information from the microservice and populate the target parameters in the model. In Group 2, an “If” statement was coded to change the lighting colour according to the real-time performance status, for instance, normal status coloured in green; alert status coloured in yellow, and abnormal status coloured in red. Figure 9 depicts the BIM 3D view showing the alert lighting status in yellow.

2.2.3. Data Visualisation

The visualisation of lighting performance information was supported by four interfaces: SmartLab mobile application, E-mail account, Autodesk Revit 2021, and Autodesk online viewer. Each one played a distinct role in the prototype and was applied in the maintenance process with the support of specific devices, as shown in

Table 2. User interfaces of the prototype system.

Interface	Role	Maintenance Process Application	Supporting Devices
SmartLab mobile application	Provide lighting performance information and notification messages for maintenance management	Supports the maintenance team in controlling the lighting (i.e., turn on, turn off) and detecting current and potential abnormalities through the visualisation of lighting performance status and notification messages	Smartphone, tablet
E-mail account	Provide information on current and potential abnormalities in lighting for maintenance management	Supports the maintenance team in detecting current and potential abnormalities through the visualisation of notification messages and triggering opening work requests	Computer, smartphone, tablet
Autodesk Revit 2021	Provide a BIM model with detailed lighting static and dynamic information for maintenance management	As a central database, it supports the maintenance team in current and potential abnormalities detection, visualisation, location, diagnosis, and repair	Computer
Autodesk online Viewer	Provide a lighter version of the BIM model for maintenance management	Supports interactions of the maintenance team with the BIM model (i.e., navigation, live sections, measurements, annotations, etc.) in a web environment, particularly relevant for field and remote works	Computer, smartphone, tablet

. In addition, addressing requirements informed by the maintenance experts, various communication channels were adopted to facilitate access to accurate information via computer, tablet, or smartphone.

2.2.4. Data and Information Management

The management of the lighting’s performance information for supporting predictive maintenance service was the last step of the prototype’s architecture. The linkage between the smart lighting system and CAFM software was undertaken by creating an e-mail notification to the maintenance sector, which triggered the opening of a work request in CAFM. Historical data records of the lighting performance generated over time can significantly optimise planning activities, such as budget setting, staff sizing and allocation, and stock control, as discussed in Section 4.

2.3. Implementation and Testing

The implementation and testing of the prototype in an experimental environment aimed to assess its capabilities and identify related limitations. The focus was on data collection, transmission and processing, and information visualisation. The information management step was not explored due to the research-related limitations (i.e., time and technical resources) to access the current CAFM software of the BR University FM sector.

The hardware and software components of the architecture were respectively implemented in physical and virtual environments. A 2.80 m width, 4.00 m length, and 2.80 m height residential bedroom with lighting in the centre of the ceiling was selected to implement the physical prototype. Figure 10 displays the physical prototype installed in the lighting.

The core software components of the architecture, namely middleware, microservices, and databases, were implemented in the virtual machines of the LaSDPC private cloud infrastructure, enabling the external access of the research team via the host. Instabilities in the infrastructure caused delays in the implementation of microservices. BIM software was implemented in the researcher’s personal computer, and the model stored in OneDrive cloud-based software.

Appendix A shows the test protocols applied to assess the prototype efficacy. Tests with the hardware components evaluated their position, attachment, and connection with electric infrastructure. On the other hand, tests with software components assessed the calibration of the sensor, Wi-Fi transmission, online storage of sensor data, the accuracy of data collection in different performance status, data processing and transmission over the IoT and BIM and visualisation of information on distinct platforms.

Simulation of three distinct performance statuses (i.e., normal, alert, abnormal) was performed to evaluate the sensor’s accuracy. As depicted in Figure 11, the normal status was demonstrated with the lamp correctly installed in the socket, the alert status with the lamp adequately installed in the socket but covered with four sheets of white bond A4 paper abnormal status with the lamp removed from the socket. The tests were conducted during daytime and night-time for identifying the influence of environmental conditions on the measurement.

3. Results

This section presents the results and assessment (Stage 4) of the smart lighting maintenance system prototyping process depicted in Figure 2, involving the implementation and testing and assessment based on performance measurement criteria and the assessment based on technical and functional requirements.

3.1. Assessment Based on Performance Measurement Criteria

Primarily, the prototype implementation and testing assessment focused on whether the prototype system effectively collected, processed, and transmitted lighting data, thus providing accurate, clear, and accessible lighting performance information to the research team.

Table 3. Assessment of the prototype according to its sets, components, and performance measurement criteria.

Set	Component	Performance Measurement Criterion	Assessment
Hardware	Lighting sensor module	Sensor data is collected with no interference from other objects	Partially
		Sensor devices are firmly and steadily attached to the lighting housing	Partially
		Sensor devices are continuously charged with no oscillations	Yes
Software	Sensor data collection	Calibration enables accurate data collection	Yes
	Wi-Fi transmission and online storage of sensor data	Data is accurately transmitted across the architecture components	Yes
	Sensor data transmission and processing	The sensor is accurately collecting data under distinct conditions	Partially
		Both data and information are accurately transmitted and interpreted by BIM and IoT platforms, generating performance information and notification messages	Yes
	Information visualisation	Information is accurate and easily visualised on SmartLab and e-mail interfaces	Yes
		Information is accurate and easily visualised on BIM platforms	Yes

shows the assessment of the prototype according to its sets, components, and performance measurement criteria and demonstrates that most requirements were fully addressed.

The hardware components tests evaluated their position, attachment, and connection with electric infrastructure. In addition, a test was applied during the day and at night regarding the sensor position. It was observed that installing the sensor on the container surface led to high interference of the environmental lighting, particularly during the day. Therefore, the sensor was installed closer to the lamp to mitigate this issue, thus enabling more consistent measurements. Regarding connection with existing electric infrastructure, the device was continuously charged over the implementation period, proving the effectiveness of the prototype design.

Tests with software components were then conducted according to the new position of the sensor and showed the collected data were consistently transmitted to the microservice and stored in the cloud infrastructure. Simulations for assessing the accuracy of the data collected by the sensor in three distinct performance statuses (i.e., normal, alert, abnormal) evidenced that night measurements were accurate, while daytime measurements presented inaccuracies related to the alert status due to environmental light interference (

Table 4. Daytime test results.

Normal Status			Alert Status			Abnormal Status
the lamp is properly installed in the socket			the lamp is properly installed into the socket but covered with four sheets of white bond A4 paper			the lamp is removed from the socket
Measurement	Lighting Level (V)	Lighting performance (%)	Measurement	Lighting Level (V)	Lighting performance (%)	Measurement	Lighting Level (V)	Lighting performance (%)
1	4095	100	1	2825	68.99	1	116	2.83
2	4095	100	2	2885	70.45	2	115	2.81
3	4095	100	3	2111	51.55	3	124	3.03
4	4095	100	4	3015	73.63	4	115	2.81
5	4095	100	5	2512	61.34	5	119	2.91
6	4095	100	6	2523	61.61	6	114	2.78
7	4095	100	7	2652	64.76	7	119	2.91
8	4095	100	8	2761	67.42	8	112	2.74
9	4095	100	9	2285	55.80	9	114	2.78
10	4095	100	10	2672	65.25	10	119	2.91
11	4095	100	11	2652	64.76	11	112	2.74
12	4095	100	12	2853	69.67	12	113	2.76
13	4095	100	13	1719	41.98	13	113	2.76
14	4095	100	14	2946	71.94	14	112	2.74
15	4095	100	15	2597	63.42	15	112	2.74
Legend
Performance Status		Normal			Alert			Abnormal
Lighting performance		lp ≥ 70%			50% ≤ lp < 70%			50% < lp

).

The performance of the prototype components in the transmission, processing and visualisation of data and information over BIM and IoT platforms was fully effective, thus providing the necessary evidence for triggering maintenance services. Furthermore, the results showed that the prototype accurately interpreted the data and generated performance information under the three tested performance statuses (i.e., normal, alert, and abnormal).

The first test demonstrated that the microservice correctly updated the percentage expected lifetime and lighting performance status in the SmartLab mobile app (Figure 12). Besides, it generated the notification messages to SmartLab and e-mail when the lighting had an abnormal or alert performance status (Figure 13).

The second test showed that Dynamo’s performance information was adequately read and interpreted, changing the BIM model parameters and the lighting’s colour. The information was effectively visualised in the BIM environment on distinct views (i.e., floor plan, ceiling plan, section plan, 3D view, etc.) (Figure 14) and the properties palette. As expected, the colours were visible only in the Autodesk Revit 2021 interface since Dynamo capabilities are unavailable in the Autodesk online viewer (Figure 15). The link to the historical data spreadsheet modelled as a parameter in Revit enabled its importation and edition into a Microsoft Excel spreadsheet (Figure 16).

3.2. Assessment Based on Technical and Functional Requirements

This section presents the assessment of the prototype according to the ability and design-related requirements provided by the maintenance experts, as displayed in

Table 5. Assessment of requirements attended by the prototype.

Category	Requirements	Assessment
Ability	Automatic detection and report of failures	Yes
	Differentiation between emergency and non-emergency services	Yes
	Supply of information on the equipment to be maintained (e.g., manufacturer, etc.)	Yes
	Generation of reports towards supporting predictive maintenance and managerial decisions	Yes
	Information on the priority of attendance of each room	Partially
Design	Use of standardised components (e.g., sensors, accessories for installation) and software that can be easily replaced and updated according to advances in technology	Yes
	Use of device for mass storage	No
	Use of a robust system with a high degree of accuracy and low likelihood of failures, ensuring the timely detection of problems	Partially
	Assurance of safety data and information	Partially
	Integration with the existing systems and facilities with no replacement of existing Lightings	Yes
	User-friendliness, considering the distinct backgrounds of the professionals	Yes
	Accessibility to all maintenance team members via smartphone	Yes
	Supply of direct and automatic tools and interfaces towards supporting de-bureaucratisation of processes and improvements in their efficiency	Yes
	Low cost of implementation, maintenance, and operation and use of open BIM platforms to reduce costs	Partially
	Possibility to be managed by the university staff	Partially

, demonstrating that most requirements were fulfilled.

The automatic detection and report of current and potential failures were undertaken by the prototype using various BIM and IoT interfaces. The differentiation between emergency and non-emergency services was addressed by defining the two critical lighting performance statuses: abnormal status (demanding immediate maintenance) and alert status (demanding maintenance). The static and dynamic information on the equipment to be maintained was centralised in the BIM model, facilitating access by the maintenance team members. The prototype also generated historical performance reports of the lightings, assisting maintenance decision-making. Instead of providing the priority attendance of each room, the prototype informed the lighting priority level (LPL) itself, covering a variety of situations in which more than one type of lighting is placed in the same room.

A series of requirements related to the prototype design was fully effective: the adoption of standardised components and software using solutions available on the market (i.e., LDR sensor, MCU, Revit software) and the microservice architecture facilitated adjustments in the parts of the prototype and the scalability of the system with no interference in its overall structure; the integration with existing systems and facilities with no interference in the current CAFM software; the development of the solution to integrate the prototype with the lighting infrastructure which enabled its power supply, removal, and reinstallation if necessary; the provision of relevant and objective data (i.e., lighting level, operating time) and information (i.e., performance status, percentage estimated lifetime, notification messages) on intuitive and diverse interfaces (i.e., SmartLab, BIM model, e-mail), supporting maintenance efficiency.

Other requirements were partially attended, such as the reliability of information affected by inaccuracies in lighting performance during the daytime, the protection of data security and privacy, due to the implementation of software components (e.g., BIM software) in local computers, and the mass storage influenced by limitations in the adopted hard disk. In addition, the requirements related to the low cost of implementation, maintenance, and operation of the system prototype and its possibility to be managed by the own university were also partially addressed.

The selection of commercial components and the development of a scalable architecture intended to reduce lifecycle costs and facilitate its management by the organisation. Although the use of commercial software (e.g., Revit) facilitates its maintenance and operation, it contributes to increasing the cost of the system in comparison to open-source solutions due to the necessity of buying licenses and updates. Additional costs involving, for instance, the computational infrastructure for data processing and storage, the specialised professionals to operate the system, and the training of organisation staff to manage the system, are equally relevant to set the overall cost of the system. Nevertheless, their assessment was not emphasised due to the limitations of this research.

4. Discussion

This section presents the discussion of findings for theory generation, the last step of the prototyping process.

4.1. Establishment of Technical and Functional Requirements and the Experimental Plan for Prototyping

A thorough understanding of the needs of the FM sector and its end-users and the capabilities of technological solutions are critical for the effectiveness of digital transformation [26,61]. At first, requirements related to the ability (i.e., automatic detection and report of failures) and design (i.e., scalability) of the system were identified, corroborating literature findings [26,54,66,67]), and revealed maintenance experts’ concerns not only with the development of a functional solution but also with its maintenance and operation by the FM sector over time. An experimental plan supported developing, testing, and assessing the prototype performance to address such requirements, as described by [26,28,29,61,68,69]. Standards [60,70] and discussion with experts were essential to developing a rationale addressing this research needs.

The complexity of developing tools and methods to measure and manage building components performance was discussed by [61,71], particularly those in which performance is not easily measurable. The authors reinforced the importance of such tools and methods to support better decision-making on FM management and avoid unnecessary interventions in building facilities. The proposed lighting priority level addressed the functional requirement of the prototype related to service prioritisation, a critical aspect of the maintenance process described in the literature [72,73,74,75]. Its benefits are mainly related to the objective prioritisation of services according to precise criteria, supporting the optimised staff and resource distributions and the structured management of outsourced services.

4.2. Establishment of FM BIM Requirements and Integration of BIM, IoT, and FM Components

The adopted approach in establishing FM BIM requirements and integrating BIM, IoT, and CAFM components addressed interoperability, a vital issue for digital transformation [28,54,61,76,77]. Decisions made by the research team addressed integration issues, as demonstrated in the prototype testing. For instance, developing an in-house lighting sensor module enabled the free collection and processing of data, overcoming access limitations imposed by commercial systems. Moreover, establishing a BIM model data structure (i.e., room ID, sensor), the adoption of interoperable programming languages (i.e., Python) in Dynamo, and the use of .json as the exchange format ensured data consistency and information among platforms. The definition of standards and protocols and the identification of critical information were essential for integrating heterogeneous systems [55,64].

However, the main contribution of the research is the proposition of a new architecture [41], exploring the IoT ecosystem structure attributes and its interface with BIM and IoT components. Using a microservice architecture structure enabled a gradual and flexible integration of distinct technologies for specific functionalities [24,78]. Furthermore, its scalable structure promoted the development of new microservices that store and process real-time data and integrate with distinct BIM and FM components (i.e., Revit, Dynamo, e-mail), providing updated performance information for maintenance actions.

Flexibility in selecting BIM, IoT, and FM components is critical for the system’s legacy. In [40,79], the authors recommend using resources available on the market (e.g., BIM software, cloud-based information management technologies, mobile devices) for new applications in the FM scenario, enabling their replacement or update. However, ref. [80] advert about the specification of particular technologies for FM business processes due to the distinct lifetimes of technologies, which would impose frequent adaptations.

The adopted mechanism for integrating BIM, IoT, and FM systems employed the Dynamo visual programming plugin as the bridge between Autodesk Revit and IoT database, thus enabling real-time and historical data and information into the BIM model parameters. Some advantages of such a mechanism corroborated by the literature are easy software development by existing BIM APIs (i.e., Revit and Dynamo), a requirement of less expertise in programming and IFC, easy linking of sensor data and model data, both stored in relational databases [81], and automatic update of sensor data on Revit interfaces [21,24]. In addition, the benefits of this approach include flexibility to integrate diverse and existing software vendors [13], availability of a single source of information, reduction of human errors, and dynamic update of information [30]. Nevertheless, the authors highlighted that the mechanism would be unsuitable for complex BIM models with many sensors since it requires a manual construction of virtual objects that represent physical sensors.

IoT and CAFM were integrated by creating an e-mail notification to the maintenance sector triggering the opening of a work request. As stated by [30], manual inputs of information in CAFM involve time-consuming, costly, and error-prone activities and must be avoided, particularly “for modern buildings of moderate and larger size” [13] (p. 156). However, considering the transition from traditional maintenance to a fully automated smart-process, it can contribute to the service performance by eliminating the detection and reporting stages currently conducted by building users.

Combining proprietary middleware and web services with a hybrid approach supports better integration of BIM, IoT, and FM systems. Although expensive and complex processes are involved in developing and implementing proprietary middleware [30], the scalability of such approaches might save both costs and time in future software development and management. Besides, proprietary middleware can make BIM a dynamic database that supports applications such as “real-time model update based on IoT device readings”, a two-way interaction involving information acquisition and control, “ubiquitous monitoring and crowdsourcing monitoring”, and “integration with other cutting-edge technologies” (i.e., virtual reality, augmented reality, and mixed reality) [24]. Advances in ICTs involving new capabilities and low-cost components have fostered innovations in the AEC industry [37]. Research on BIM and IoT integration is embryonic, and new methods, web services and SOA-based design are necessary for supporting such applications [24,36], reinforcing the relevance of this research.

4.3. Generation of Intelligence from Raw Data

The approach for generating relevant information from real-time data towards supporting maintenance decision-making according to the assessed abilities of the prototype for data collection and analysis addressed a challenge reported in the literature [7,13,41,82]. The collection of real-time data was the first step for intelligence generation, thus involving the lighting level (V) and operating time (h) collected by the lighting sensor module. Testing results show that the components and design solutions adopted in the prototype design have influenced the accuracy of measurements. Previous studies reported similar limitations of IoT system components, such as low precision of GIS system [40] and inaccuracy in reporting location and the number of sensors to perform the measurements [62,83]). However, advancements in research and new technologies (e.g., remote sensing technology, computing power, distributed computing) can overcome them [13,27,37]. Besides, the costs of IoT components are gradually declining, enabling their mass distribution [84].

Once the real-time data were available in the cloud, the following step was data processing and analyses in IoT and BIM environments. The testing results indicated that the system accurately interpreted real-time data, generating updated information through distinct communication channels. Alert Microservice analysed the real-time data according to the pre-set criteria in the IoT environment, generating performance status and percentage expected lifetime information. Developing methodologies that assess building performance is a key FM challenge addressed in this study. Such information was automatically updated in the SmartLab mobile app and BIM model parameters. In addition, Alert Microservice generated notification messages on potential or current abnormalities via SmartLab and e-mail accounts based on performance status.

The historical data of Microservice summarised lighting performance data in a historical data record, provided in a .json file and modelled as a dynamic BIM parameter. As shown by the tests, a large volume of data might be generated over the lighting lifetime—particularly in rooms where the lighting is intensively used, hampering its accessibility, interpretation and support to decision-making [41,85]. Therefore, according to [86], changes in the traditional approaches will be necessary to manage extensively large and complex data sets, conducting the sector towards the emerging paradigm of big data.

The Dynamo plugin had two roles in information generation within the BIM environment. First, it populated model parameters with real-time inputs (i.e., performance status, percentage expected lifetime information, link to historical data), enriching the model with dynamic information, and analysed the performance status based on the predefined colour set rule-based, delivering visual and straightway information on lighting performance. In both environments, consistent rules were essential to transform raw data into relevant information and actionable recommendations [41].

4.4. Accessibility to Relevant Information for Decision-Making

The provision of reliable and effortlessly accessible information is essential for improvements in FM performance, particularly with the support of BIM and IoT solutions [10,40,54,80]. The prototype effectively addressed information accessibility issues. Such effectiveness can be explained by the adoption of complementary interfaces for visualising distinct tiers of information with the support of specific devices and applicable to specific maintenance activities.

The visualisation of notification messages on the SmartLab mobile app, and e-mail interfaces demonstrated the prototype’s ability to automatically detect and report current and potential failures, differentiating between emergency and non-emergency services. In addition, both interfaces delivered concise and clear text-based information on the lighting to be maintained (i.e., identification, location, and performance status level), supporting the opening of work requests in CAFM software for immediate or planned service response. SmartLab also provided clear and intuitive lighting information (i.e., identification, location, performance status level, percentage estimated lifetime), facilitating the monitoring of lighting performance in real-time.

Previous studies described the advantages of such user-friendly interfaces supported by mobile devices (i.e., smartphone, tablet) for BIM and IoT systems. For instance, mobile devices are currently available to most populations, thus becoming an essential tool for tradesmen in field works [40,84]. Besides, mobile apps do not require high technical expertise from end-users and, therefore, encourage collaboration among maintenance stakeholders [40] and increase the productivity of FM staff [13].

BIM interfaces provided clear, accurate, and updated Lighting information. The tests showed that real-time performance information was effortlessly visualised on both properties palette and Autodesk Revit 2021 model views. In addition, lighting historical data recording, modelled as a dynamic BIM parameter, was effortlessly downloaded and visualised in a spreadsheet. A similar approach was adopted by [62], who emphasised the importance of a common platform for intuitive identification of potential problems and decision management.

Besides the overall benefits of BIM as a central repository, improving the identification, visualisation, and diagnosis of problems, the introduction of real-time information moves BIM to a higher level, addressing the paradigm of digital twin [21]. By enabling the query of the current and past status of the lighting, the resulting digital twin might support short- to long-term maintenance response, facilitating the detection, visualisation, location, diagnosis, and repair of current and potential abnormalities.

4.5. Impacts of the Smart Lighting Maintenance System Prototype on Service Performance

The overall optimisation of maintenance process stages is explored according to the traditional reactive maintenance process (See Figure 1) versus the BIM and IoT-assisted predictive maintenance process, enabled by the Smart Lighting Maintenance System prototype (Figure 17). Automating functions and centralising information in the system databases led to streamlining activities, particularly in the initial and reduced stages over the predictive maintenance process.

In Stage 1, the sensor’s automatic detection of current and potential faults adds value to the maintenance process. By removing the end-user participation, the system increases the accuracy and efficiency of detection by promptly capturing variations in building component performance that might be imperceptible or even inaccessible by humans [73,87]. As stated by an interviewed maintenance expert, automatic detection would avoid the user’s bias or lack of knowledge about the event [88,89], triggering maintenance response in early days even with no end-user’s perception.

In Stage 2, the automatic report of current and potential faults and the supported feasibility analysis contribute to optimising activities [85]. Fault report is performed through notification messages via e-mail and SmartLab, thus increasing the accuracy of the information and the efficiency of the activity. As a result, it eliminates the diversity of communication channels for specific users and human-related obstacles such as loss of paper forms, imprecise or late description of faulty equipment and location, and duplication of requests [40,90,91,92,93].

The system updates real-time information in BIM and IoT databases, providing dynamic and static Lighting information for maintenance purposes. The generation of work requests is also optimised since the system prototype enables both automatic and manual input of information into the CAFM system, according to the functionalities of the software in place. Efficiency gains are expected even in the manual input due to updated information in BIM and IoT databases. As a critical activity in the maintenance process, the prioritisation of services is based on real-time lighting performance status and lighting priority level (LPL) available in the BIM and IoT databases. Such updated and standardised information supports a more agile and accurate prioritisation, mitigating practices such as personal assessment [10] and the “first in first out” method, and contributing to the distribution of resources and maintenance staff sizing for repair.

In Stage 3, the service location is automatically provided in notification messages and BIM and IoT interfaces. Field inspections can be virtually undertaken on BIM interfaces, supporting the maintenance team in checking the position of the lighting in the room in advance [80] and potential rationale for failure. Problems caused by inaccurate descriptions of fault locations are eliminated, and unnecessary visits to the field are avoided.

In Stage 4, both diagnosis and planning of repair are assisted by updated information in the system’s databases. The visualisation of all characteristics of the component in the BIM model facilitates the diagnosis [10] and the purchase of services or materials for repair and mitigates delays caused by inaccurate specification of parts to be maintained or replaced. The availability of updated historical data is a powerful tool for analysing lighting performance over time and predicting future behaviour, optimising planning activities, such as staff sizing and allocation, budget planning, and stock control [94,95]. Within a predictive approach, the FM managers could identify in advance the precise number, type, and location of damaged items automatically extracted from the smart lighting maintenance system report, optimising the available resources. Such improvements contribute to the efficiency of service repair (Stage 5), carried out with more precision and agility. In this sense, it addresses the scarcity of electricians for the maintenance of buildings and infrastructure of the university campuses, as described by the interviewed maintenance experts.

The quality of the inventory parts could also be improved since historical records evidence those underperforming items. Such benchmarking data based on the behaviour of the monitored components could justify upgrades in equipment and systems and projects of optimisation and control [10,41,96]. In the long run, the historical data can provide a rich database for predicting future behaviour, particularly with support of artificial intelligence (AI) and machine learning technologies [97], supporting the achievement of “optimum performance throughout the life span of a facility with a minimum life cycle cost” [54] (p. 436).

In Stage 6, the service check-out is optimised since the system automatically verifies the lighting performance status after repair, facilitating the execution approval and closing the request. The delivery (7) and feedback and closing requests (8) stages are eliminated since no end user’s participation is required.

The benefits of moving from a reactive to a predictive approach are expected in all organisation sectors. From a maintenance management perspective, predictive maintenance promotes significant efficiency gains, reducing both time response and labour and material costs and improving the quality of services. In [95], estimated cost-saving opportunities between 30 and 40% due to the efficient usage of staff resources and the reductions in overtime work, possible damage of secondary processes or equipment, and stock of spare parts [95].

Since labour costs represent about 70% of the overall maintenance services costs [90,98] and information-related activities might represent 12% of the time response [99], optimising FM activities through BIM and IoT solutions is critical for significant savings. For instance, compared to traditional maintenance, the time required for lamp replacements can be reduced by approximately a third only with the support of BIM due to the easy access to precise information within the model database.

Improvements in safety and satisfaction of maintenance team members and university users are also expected. The automation of functions and the centralisation of information in the system databases enable the maintenance team to anticipate risks involved in field activities, reducing the likelihood of accidents or unprotected exposure to hazardous environments. Therefore, the team members can focus on core activities [99], such as training programs and the development of standards, contributing to the efficiency of service provision. For the end-user, reduction of disruption occurrence and length can mitigate accidents in risky conditions (i.e., dark stairs or plant rooms) and the stability of activities. Reducing user participation in bureaucratic tasks (i.e., fault report and execution approval) also represents a time-saving activity that adds value to the university context.

Finally, a predictive approach can also generate significant benefits to the environment. For instance, replacing a damaged component based on its current performance condition reduces the frequency of repairs and the unnecessary generation of waste. Moreover, energy savings are achieved since the (electrical) component runs efficiently during its life cycle [95].

On the other hand, investments in technology, process, and policy issues are required to obtain such benefits. The acquisition and installation of technological components are the start point for effective improvements in service provision. Additional costs must also be considered in maintaining and operating such components, including hiring specialised services and professionals. Nevertheless, the most important investments must be related to organisational changes, which involve the upskilling of the maintenance team and the development of protocols and standards compatible with a predictive approach [10,41,90,100,101].

5. Conclusions

This article presented the development process of a BIM- and IoT-based smart lighting maintenance system prototype to support university FM sectors on decision-making. The analysis of empirical evidence contributed to knowledge both conceptually and methodologically through the characterisation of steps and decisions involved in the prototyping process and the identification of potential impacts of the prototype on maintenance management.

From such interdisciplinary and practical experience, the investigation has demonstrated the following: the necessity of collectively identifying a range of technical, functional, and FM BIM information requirements for effective smart system implementation, facilitating the communication among stakeholders and the decision-making. In addition, the importance of interoperability and scalability for the development of both physical and analytical dimensions of the system, ensuring free access to data, flexible and gradual integration among components, and consistency of data transmission; and the necessity of advances in tools and methods for measuring, assessing, and analysing building components performance, extracting useful information for decision-making. In this regard, this study evidenced that the effectiveness of BIM and IoT implementation in FM activities depends not only on the technological abilities of software and devices but also on a clear definition of procedures and standards to guide steps and decisions in both organisational and industry levels.

The findings of this study are relevant to practice and research since it enhances the comprehension of complex issues involved in the implementation of BIM and IoT solutions in FM sectors and maintenance services. The proposed protocols and models point out methodological directions to future studies. Despite focusing on the management of building lighting systems, the principles applied to the prototype development are scalable to other systems of buildings and cities. Since digital transformation in the AEC industry is still an evolving field of investigation, such advancements can support researchers and policymakers in developing instruments, guidelines, and standards for enabling smart maintenance and smart cities.

The application of the findings to practice is also relevant for improving the understanding of technological, procedural, and policy aspects involved in implementing BIM and IoT in the AEC industry. For example, knowing the most likely scenario for maintenance problems at the organisational level points out areas to be potentially improved through BIM and IoT within a predictive approach. Moreover, understanding the requirements, challenges, and expected benefits of implementing smart systems provides a more realistic picture of the necessary steps and resources. For owners and FM staff, such inputs are valuable for justifying financial and human investments (i.e., computational components, upskilling, development of procedures) and planning the digital transformation of services for a smarter provision. In this respect, this article findings contribute to improving decision-making over the lifecycle of a project and driving organisations towards BIM5.0, thus extending BIM to urban, city, aerospace and other large-scale projects.

Despite the contributions of the prototyping experience to knowledge, some limitations were identified, including a lack of consistent tools, methods, and devices for measuring building components performance and restrictions in research resources (i.e., number of variables analysed). As a result, the procedures for testing and assessing the performance of the prototype and the methods for the validation of findings were affected. In this sense, future studies might involve: (i) the implementation of the prototype in real environments, including spaces with distinct characteristics (e.g., function, size, number of users); (ii) the exploration of other computational components (e.g., BIM software, CAFM system, sensors, AI), exchange formats (i.e., IFC, COBie), and mechanisms for the integration of BIM, IoT, and FM tools (e.g., semantic web technologies) and capabilities (e.g., provision of analytical reports), towards higher effectiveness; and (iii) the external validation of the prototype by maintenance and IT experts.