Close
About
FAQ
Home
Collections
Login
USC Login
Register
0
Selected
Invert selection
Deselect all
Deselect all
Click here to refresh results
Click here to refresh results
USC
/
Digital Library
/
University of Southern California Dissertations and Theses
/
A BIM-based visualization tool for facilities management: fault detection through integrating real-time sensor data into BIM
(USC Thesis Other)
A BIM-based visualization tool for facilities management: fault detection through integrating real-time sensor data into BIM
PDF
Download
Share
Open document
Flip pages
Contact Us
Contact Us
Copy asset link
Request this asset
Transcript (if available)
Content
i A BIM-BASED VISUALIZATION TOOL FOR FACILITIES MANAGEMENT Fault detection through integrating real-time sensor data into BIM By Gelin Su Presented to the FACULTY OF THE SCHOOL OF ARCHITECTURE UNIVERSITY OF SOUTHERN CALIFORNIA In partial fulfillment of the Requirements of degree MASTER OF BUILDING SCIENCE MAY 2019 ii ACKNOWLEDGEMENTS I would like to express my deep gratitude to my parents, who have been supportive of my two-year study at USC, for giving me the chance to start this research. I really appreciate the valuable help from Professor Karen Kensek with defining and developing the topic, and encouraging me to be more creative during the research. I would also like to express my appreciation to Professor Kyle Konis and Professor Joon-Ho Choi for providing advice with their knowledge from different areas of expertise, and I am particularly grateful for the assistance given by Professor Kyle Konis, who spearheaded the TrojanSense Project and offered to give me the access to sensor data for my research. My special thanks are also extended to TrojanSense team members, especially my colleague and friend Zhengao Dong who has been setting up sensors since last year. I also wish to acknowledge the help provided by USC FMS staff. Thanks to Mr. Jose Delgado for sharing the model of Watt Hall with me. Thanks to Mr. Craig Shultenburg and Ms. Ruby Quan for exhaustive introductions to facility management systems during my visit to USC FMS. Thanks to Mr. David Adkisson from EcoDomus Inc. for having meetings with me, and for his technical assistance that acquainted me with the basics of C# programming language. iii COMMITTEE MEMBERS Karen Kensek Professor of Practice University of Southern California kensek@usc.edu Kyle Konis Assistant Professor University of Southern California kkonis@usc.edu Joon-Ho Choi Assistant Professor University of Southern California joonhoch@usc.edu iv ABSTRACT During the operation and maintenance (O&M) phase of a building, nearly 30% of its operating expenses were spent on utilities, and the majority of this expenditure belongs to energy costs (electricity and natural gas) for powering varieties of facilities and equipment. Therefore, an effective and easy-to-access system for facility management (FM) is significant in terms of both financial consideration and building performance. Building Information Modeling (BIM) technology is a powerful tool to assist FM, by integrating BIM into the FM process. One of the examples is the integration of real-time sensor data into BIM models that help with daily monitoring and fault detection of sensors. By pinpointing the location of faults in 3D models, FM personnel are able to find out the reason for fault occurrences and execute corrective maintenance or make changes to the indoor environment such as thermal condition. A BIM-based visualization tool “Adafruit IO Reader” was developed with the C# programming language in Revit Macro IDE to interface real-time Internet of Things (IoT) sensor data feeds in Autodesk Revit. Data feeds were retrieved from TrojanSense Project, which intended for providing strategies of improving thermal comfort. By executing C# codes, data feeds were retrieved from the Adafruit IO server and saved as text (TXT) files. These files were pruned and converted to comma-separated values (CSV) files, and then imported into the tool. Feeds were displayed both in tables and line graphs. By making connections between sensor data feed IDs and sensor model IDs in Revit, users could be navigated to corresponding sensors in Revit. Fault detection algorithm based on comfort zones such as ASHRAE 55-2017 helped locate sensor with abnormal values, and these sensors were highlighted with alerting colors in 3D views. Usability of the tool was tested with installed IoT sensors in Watt Hall (WAH), and the tool was able to locate faulted sensors and highlight them. The research findings contribute to the area of information visualization in facility management, and the tool can provide FM personnel with an insight into HVAC operation in terms of improving indoor thermal comfort. KEY WORDS: Building Information Modeling (BIM); IoT Sensors; Fault detection; Visualization; Facilities management and operation HYPOTHESIS Adafruit IO Reader can integrate BIM models with real-time sensor data and can find sensors with loss of values or faulted values in BIM models. RESEARCH OBJECTIVES • Design the architecture and interfaces of Adafruit IO Reader with C# programming language in Revit Macro IDE; • Design the workflow that connects IoT sensors, Adafruit IO Reader, and BIM models; • Assign a local file repository to store real-time data that can be synchronized with most recent data on the server; • Design the main program of Adafruit IO Reader that navigates users to sensor models in Revit, with visualized sensor data information and other supplementary information such as photographs of ambient environment surrounding IoT sensors. • Validate tool usability and tool features by a case study of Watt Hall; v TABLE OF CONTENTS TABLE OF CONTENTS ACKNOWLEDGEMENTS ......................................................................................................... ii COMMITTEE MEMBERS ........................................................................................................ iii ABSTRACT .................................................................................................................................. iv TABLE OF CONTENTS ............................................................................................................. v TABLE OF FIGURES ............................................................................................................... viii 1. INTRODUCTION............................................................................................................... 11 1.1 Building information modeling (BIM) ............................................................................................. 11 1.2 Facility management (FM) ............................................................................................................... 13 1.3 Leveraging BIM for FM ................................................................................................................... 13 1.3.1 Computerized maintenance and management system (CMMS) ............................................... 14 1.3.2 Building automation system (BAS) .......................................................................................... 15 1.3.3 Engineering document management system (EDMS) .............................................................. 15 1.3.4 Integration software ................................................................................................................... 16 1.4 Sensors, sensor data, and sensor measurements ............................................................................... 18 1.4.1 Introduction of sensors .............................................................................................................. 18 1.4.2 Work with sensor data ............................................................................................................... 20 1.4.3 Sensor fault detection ................................................................................................................ 22 1.5 Manage sensor data feeds: Adafruit IO ............................................................................................ 23 1.5.1 Feeds ......................................................................................................................................... 23 1.5.2 Representational State Transfer (REST) API ............................................................................ 24 1.6 Integration of BIM and sensor data .................................................................................................. 24 1.7 Visualization ..................................................................................................................................... 25 1.8 Revit programming ........................................................................................................................... 28 1.8.1 Revit API ................................................................................................................................... 28 1.8.2 Revit Macro IDE ....................................................................................................................... 30 1.8.3 Dynamo ..................................................................................................................................... 31 1.9 Software development methodology ................................................................................................ 32 1.10 Comma-separated values (CSV) format ......................................................................................... 33 1.11 Summary ......................................................................................................................................... 35 2. BACKGROUND RESEARCH .............................................................................................. 36 2.1 Understanding the framework of BIM for FM ................................................................................. 36 2.1.1 Case study #1: Northumbria University (Kassem et al. 2015) .................................................. 36 2.1.2 Case study #2: Carnegie Mellon University (Yang and Ergan 2015) ....................................... 37 2.1.3 Case study #3: University of Southern California (Teicholz 2013) .......................................... 38 2.2 Integration of Sensor data into BIM ................................................................................................. 39 2.2.1 Introduction ............................................................................................................................... 39 2.2.2 Sensor reading ........................................................................................................................... 40 2.2.3 Sensor metadata......................................................................................................................... 41 2.2.4 Building information ................................................................................................................. 42 2.3 An example of BIM-BAS integration: Dasher 360 .......................................................................... 42 2.3.1 Introduction ............................................................................................................................... 42 2.3.2 Evaluation of Dasher 360 .......................................................................................................... 44 2.4 Fault detection algorithms ................................................................................................................ 44 2.4.1 Statistical generation model (SGM) (Sallans et al. 2006) ......................................................... 44 vi 2.4.2 Adaptive-neuro fuzzy inference system (ANFIS) (Liu et al. 2011) .......................................... 45 2.4.3 Other advanced algorithms ........................................................................................................ 45 2.5 Summary ........................................................................................................................................... 45 3. METHODOLOGY ................................................................................................................. 47 3.1 Overall introduction of the workflow ............................................................................................... 47 3.1.1 Preparation ................................................................................................................................ 47 3.1.2 Tool development ...................................................................................................................... 50 3.1.3 Validation of usability ............................................................................................................... 52 3.2 Detailed workflow of tool development ........................................................................................... 53 3.2.1 Section #1: Data retrieval and pruning ...................................................................................... 53 3.2.2 Section #2: Fault definition ....................................................................................................... 57 3.2.3 Section #3: Sensor model visualization ..................................................................................... 59 3.3 Summary ........................................................................................................................................... 63 4. PROGRAM DEVELOPMENT ............................................................................................. 64 4.1 Files and user settings ....................................................................................................................... 64 4.1.1 Data retrieval, pruning and synchronization ............................................................................. 64 4.1.2 Save customized settings ........................................................................................................... 65 4.2 Data display and visualization .......................................................................................................... 67 4.2.1 Data tables and plots ................................................................................................................. 67 4.2.2 Full and partial tables / plots ..................................................................................................... 69 4.2.3 All values and faulty values ...................................................................................................... 70 4.2.4 Navigation to sensor models ..................................................................................................... 70 4.2.5 On-site photographs .................................................................................................................. 74 4.3 Comfort zones................................................................................................................................... 75 4.3.1 Comfort zone presets ................................................................................................................. 75 4.3.2 Color schemes ........................................................................................................................... 75 4.4 Summary ........................................................................................................................................... 76 5. CASE STUDY OF WATT HALL ......................................................................................... 77 5.1 Hardware .......................................................................................................................................... 77 5.2 Software ............................................................................................................................................ 78 5.2.1 3D model and 3D views ............................................................................................................ 78 5.2.2 Preparation for running the program ......................................................................................... 78 5.2.3 Main interface of Adafruit IO Reader ....................................................................................... 80 5.3 Case study part #1 – Files and user settings ..................................................................................... 81 5.3.1 Data retrieval, pruning and synchronization ............................................................................. 81 5.3.2 Save customized settings ........................................................................................................... 83 5.4 Case study part #2 – Data display and visualization ........................................................................ 84 5.4.1 Data tables and plots ................................................................................................................. 84 5.4.2 Full and partial tables / plots ..................................................................................................... 84 5.4.3 All values and faulty values ...................................................................................................... 86 5.4.4 Navigation to sensor models ..................................................................................................... 86 5.4.5 On-site photographs .................................................................................................................. 89 5.5 Case study part #3 – Comfort zones ................................................................................................. 90 5.5.1 Comfort zone presets ................................................................................................................. 90 5.5.2 Color schemes ........................................................................................................................... 90 5.6 Summary ........................................................................................................................................... 91 6. DISCUSSION AND FUTURE WORK ................................................................................. 92 6.1 Discussion of results ......................................................................................................................... 92 vii 6.1.1 Examination of tool features ..................................................................................................... 92 6.1.2 Evaluation of current workflow ................................................................................................ 94 6.1.3 Limitations ................................................................................................................................ 94 6.2 Future work....................................................................................................................................... 95 6.2.1 Responding speed improvement ............................................................................................... 95 6.2.2 Code improvement .................................................................................................................... 95 6.2.3 Flexibility and customization .................................................................................................... 96 6.2.4 Potential of embedding in FM platforms .................................................................................. 96 6.3 Conclusion ........................................................................................................................................ 96 REFERENCES ............................................................................................................................ 97 APPENDIX A ............................................................................................................................ 100 A.1 Program launcher ........................................................................................................................... 100 A.2 Form1 – Main interface ................................................................................................................. 107 A.3 Form2 – Date Filter ....................................................................................................................... 113 A.4 Form3 – Comfort Zones ................................................................................................................ 115 viii TABLE OF FIGURES Figure 1.1 2D and 3D: The floor plan (upper) and the Revit model (lower) of Watt Hall.................................................................. 11 Figure 1.2 Integration of architectural, structural, and MEP models of Jill and Frank Fertitta Hall (JFF) in EcoDomus FM ......... 12 Figure 1.3 The lifecycle of a building ..................................................................................................................................................... 12 Figure 1.4 An example of FM systems and linkages in a BIM for FM framework ............................................................................. 14 Figure 1.5 Menkes Tower (left) and the schematic diagram of primary chiller water system in EBI (right) .................................... 15 Figure 1.6 Document exchange process in Meridian Portal .................................................................................................................. 16 Figure 1.7 Check product documentation in EcoDomus PM ................................................................................................................ 16 Figure 1.8 BIM-BAS integration in EcoDomus FM .............................................................................................................................. 17 Figure 1.9 Monitor design changes in BIM 360 Design ........................................................................................................................ 17 Figure 1.10 A 3D view in iPad version of BIM 360 Glue, a collaboration software for constructability and clash detection......... 18 Figure 1.11 The juxtaposition of 3D model view and 2D plan view in YouBIM (Hunt and Betancur 2015) .................................. 18 Figure 1.12 An infrared sensor (left) and a microscopic sensor (right) ................................................................................................ 19 Figure 1.13 ONSET HOBO data logger connected to a mobile phone ................................................................................................ 19 Figure 1.14 Original data file of an IoT sensor installed in USC Watt Hall ........................................................................................ 20 Figure 1.15 Line plot of past temperature data in Los Angeles ............................................................................................................ 21 Figure 1.16 Line plot of temperature fluctuation at Watt Hall Building Science Corner .................................................................... 21 Figure 1.17 Line plot of past temperature data from an IoT sensor in USC Watt Hall ....................................................................... 21 Figure 1.18 Types of sensor faults: (a) bias, (b) drift, (c) complete failure, and (d) precision degradation (Liu et al. 2011) .......... 22 Figure 1.19 Define “normal” and “faulty” values based on comfort zones ......................................................................................... 22 Figure 1.20 Types of “faults” explained with a psychometric chart (based on Lechner, 2000) ......................................................... 23 Figure 1.21 Data feeds from an IoT sensor (Dong, 2019) ..................................................................................................................... 23 Figure 1.22 Adafruit IO REST API specification .................................................................................................................................. 24 Figure 1.23 The workflow diagram of the case study ............................................................................................................................ 25 Figure 1.24 The data visualization of the case study (Chen et al. 2014) .............................................................................................. 25 Figure 1.25 The example of scientific visualization: A rendering image of a visit center .................................................................. 26 Figure 1.26 The example of information visualization: Illuminance level in the visit center ............................................................. 26 Figure 1.27 Temperature monitoring at Engemann Student Health Center ......................................................................................... 27 Figure 1.28 Boiler status monitoring at Engemann Student Health Center ......................................................................................... 27 Figure 1.29 Alarm interface ..................................................................................................................................................................... 28 Figure 1.30 Replace materials by batch processing in a Revit plugin (Polynine Studio, 2018) ......................................................... 28 Figure 1.31 The hierarchy of namespace, class and method (left) and the syntax of ZoomToFit method (right) ............................. 29 Figure 1.32 Adding references (left) and namespaces (right) to Visual Studio ................................................................................... 29 Figure 1.33 Add-in manifest .................................................................................................................................................................... 30 Figure 1.34 The interface of Revit Macro IDE ...................................................................................................................................... 30 Figure 1.35 Parametric soccer stadium design with Dynamo ............................................................................................................... 31 Figure 1.36 Parameters sliders (left) and Dynamo code overview (right)............................................................................................ 32 Figure 1.37 Parametric façade design ..................................................................................................................................................... 32 Figure 1.38 Open the same CSV file in Notepad (upper) and Excel (down) ....................................................................................... 34 Figure 1.39 The juxtaposition of tabular data and line plot in HOBOware Pro ................................................................................... 35 Figure 2.1 Comparison between current workflow (upper) and BIM-based workflow (lower) (Kassem et al., 2015) .................... 36 Figure 2.2 Integrated BIM provides FM personnel with various information (Kassem et al., 2015) ................................................ 37 Figure 2.3 Integrated Multi-view HVAC Information Visualizer (Yang and Ergan 2015) ................................................................ 37 Figure 2.4 BIM-FM framework adopted by USC FMS ........................................................................................................................ 38 Figure 2.5 The location of an inline fan and maintenance manual in EcoDomus (Kensek, 2015) ..................................................... 38 Figure 2.6 Schematic diagram of an air handler from Honeywell BAS system (Teicholz, 2013) ..................................................... 39 Figure 2.7 Working interface of building fire control system (Shiau and Chang, 2014) .................................................................... 40 Figure 2.8 The crane navigation system with a monitor and an adjustable arm (Lee et al. 2012) ...................................................... 40 Figure 2.9 SensorMap – a sensor data publishing platform by Microsoft (Wang et al. 2015) ........................................................... 42 Figure 2.10 The user interface of Autodesk Dasher 360 ....................................................................................................................... 43 Figure 2.11 Sensors, sensor list and data plots in Dasher 360 .............................................................................................................. 43 Figure 2.12 Sensor data values (blue) and corresponding log-likelihood (red) (Sallans et al. 2006) ................................................. 44 Figure 2.13 Sample sensor data for test (left) and SPE index (right) (Liu et al. 2011) ....................................................................... 45 Figure 3.1 Methodology and design workflow ...................................................................................................................................... 47 Figure 3.2 Preparation .............................................................................................................................................................................. 48 Figure 3.3 The application level macro “NewReadAdafruit” in the Macro Manager ......................................................................... 48 Figure 3.4 Read sensor data from Honeywell system in RDS API ...................................................................................................... 49 Figure 3.5 Tool development ................................................................................................................................................................... 50 Figure 3.6 Concept imagery of tool interface ......................................................................................................................................... 51 Figure 3.7 Combo box ............................................................................................................................................................................. 52 Figure 3.8 Concept imagery of data table and line plot ......................................................................................................................... 52 ix Figure 3.9 Validation of usability............................................................................................................................................................ 52 Figure 3.10 Detailed workflow of tool development with the feature checklist .................................................................................. 53 Figure 3.11 Data retrieval and pruning ................................................................................................................................................... 53 Figure 3.12 The Username and Active Key (AIO Key) for author....................................................................................................... 54 Figure 3.13 The feed information page that records information about all feeds ................................................................................ 54 Figure 3.14 The original data file that records sensor data values and related information ................................................................ 55 Figure 3.15 The second step – reorganizing attributes and values........................................................................................................ 56 Figure 3.16 The third step – converting Zulu Time into Pacific Time ................................................................................................. 56 Figure 3.17 Fault definition ..................................................................................................................................................................... 57 Figure 3.18 Loss of data values (red rectangle) in “value” column ...................................................................................................... 57 Figure 3.19 Psychometric chart with the ASHRAE 55 comfort zone (Lechner, 2000) ...................................................................... 58 Figure 3.20 Data values out of range with color schemes ..................................................................................................................... 58 Figure 3.21 Sensor model visualization .................................................................................................................................................. 59 Figure 3.22 Watt Hall ............................................................................................................................................................................... 59 Figure 3.23 A section of Watt Hall ......................................................................................................................................................... 60 Figure 3.24 IoT sensors (left, middle) and ESP32 board (Right).......................................................................................................... 60 Figure 3.25 Locations of sensor installation in Revit and their photographs ....................................................................................... 61 Figure 3.26 The interface for submitting users’ feedback in “TrojanSense” app (left) and the campus map in “TrojanSense” project with users’ feedback results (right) (Dong, 2019) ..................................................................................................................... 61 Figure 3.27 The relationship diagram describing how data feeds, sensor ID and sensor models are connected ............................... 62 Figure 3.28 Get sensor model ID in Revit .............................................................................................................................................. 62 Figure 4.1 Retrieve data feeds from Adafruit IO Server ....................................................................................................................... 64 Figure 4.2 Prune data feeds by removing unnecessary items ................................................................................................................ 65 Figure 4.3 Create CSV files ..................................................................................................................................................................... 65 Figure 4.4 Code for the “Synchronization Completed” dialog box ...................................................................................................... 65 Figure 4.5 The interaction between configuration file and main program ........................................................................................... 65 Figure 4.6 Validate temperature range and RH range ........................................................................................................................... 66 Figure 4.7 Write customized comfort zone settings to the configuration file ...................................................................................... 66 Figure 4.8 Read customized comfort zone settings from the configuration file .................................................................................. 66 Figure 4.9 Prepare for loading data table ................................................................................................................................................ 67 Figure 4.10 Define the file path – 1/2 ..................................................................................................................................................... 67 Figure 4.11 Define the file path – 2/2 ..................................................................................................................................................... 68 Figure 4.12 Generate data table ............................................................................................................................................................... 68 Figure 4.13 Generate line plot ................................................................................................................................................................. 68 Figure 4.14 Validate date range............................................................................................................................................................... 69 Figure 4.15 Different row filters to be selected ...................................................................................................................................... 69 Figure 4.16 Apply the row filter .............................................................................................................................................................. 70 Figure 4.17 Switch between all values and only faulty values .............................................................................................................. 70 Figure 4.18 Macros that navigate users to sensor models ..................................................................................................................... 71 Figure 4.19 The first step – Declare variables ........................................................................................................................................ 71 Figure 4.20 The second step (1 of 2) – Reset color schemes ................................................................................................................ 71 Figure 4.21 The second step (2 of 2) – Apply a new color scheme ...................................................................................................... 72 Figure 4.22 Different view scales with the sensor model at the center ................................................................................................ 72 Figure 4.23 The third step – zoom out the view ..................................................................................................................................... 73 Figure 4.24 Zoom out by getting “zoom corners” ................................................................................................................................. 73 Figure 4.25 The fourth step – initialize main program .......................................................................................................................... 74 Figure 4.26 Load on-site photographs .................................................................................................................................................... 74 Figure 4.27 An example of “Room Photo” (left) and “Sensor Photo” (right)...................................................................................... 74 Figure 4.28 Text boxes and comfort zone presets .................................................................................................................................. 75 Figure 4.29 Apply a comfort zone to data tables ................................................................................................................................... 75 Figure 4.30 Apply color schemes to data tables ..................................................................................................................................... 76 Figure 5.1 An IoT sensor ......................................................................................................................................................................... 77 Figure 5.2 Sensor locations in Watt Hall ................................................................................................................................................ 77 Figure 5.3 Watt Hall 3D models (1-3) and IoT sensor model (4) ......................................................................................................... 78 Figure 5.4 Program files .......................................................................................................................................................................... 78 Figure 5.5 The path of “AppHookup” folder ......................................................................................................................................... 79 Figure 5.6 Macro security alert ............................................................................................................................................................... 79 Figure 5.7 Run a macro in Revit ............................................................................................................................................................. 79 Figure 5.8 The result of running macro “A_Watt_Hall_Building_Science_Corner” .......................................................................... 80 Figure 5.9 The main interface .................................................................................................................................................................. 80 Figure 5.10 Watt Hall sensor list ............................................................................................................................................................. 81 Figure 5.11 Synchronizing sensor data (Upper – Results; Lower – Steps and clicks) ........................................................................ 82 x Figure 5.12 The “Synchronization Completed!” dialog box ................................................................................................................. 82 Figure 5.13 Temperature data file for Watt Hall Building Science Corner .......................................................................................... 82 Figure 5.14 Pruned sensor data files in TXT and CSV format ............................................................................................................. 83 Figure 5.15 Synchronizing sensor data ................................................................................................................................................... 83 Figure 5.16 Data tables and line plots ..................................................................................................................................................... 84 Figure 5.17 Display settings .................................................................................................................................................................... 85 Figure 5.18 Date Filter ............................................................................................................................................................................. 85 Figure 5.19 Full and partial tables / plots ............................................................................................................................................... 85 Figure 5.20 All values and faulty values ................................................................................................................................................ 86 Figure 5.21 Select a macro and go to the view of the corresponding sensor model ............................................................................ 86 Figure 5.22 3D model and information for sensor in Watt Hall Building Science Corner ................................................................. 87 Figure 5.23 3D model and information for sensor in Watt Hall Upper Rosendin ............................................................................... 87 Figure 5.24 3D model and information for sensor in Watt Hall Lower Rosendin ............................................................................... 88 Figure 5.25 3D model and information for sensor in Watt Hall 212 .................................................................................................... 88 Figure 5.26 3D model and information for sensor in Watt Hall B1...................................................................................................... 89 Figure 5.27 On-site photographs ............................................................................................................................................................. 89 Figure 5.28 Set a preset comfort zone ..................................................................................................................................................... 90 Figure 5.29 Applying different comfort zones to data tables ................................................................................................................ 91 Figure 6.1 The “bridge” – Adafruit IO Reader put together information from multiple places ......................................................... 92 Figure 6.2 The integration of sensor data and BIM through Adafruit IO Reader ................................................................................ 93 Figure 6.3 Comparison of different sensor data files (Chen et al. 2014) .............................................................................................. 94 Figure 6.4 Prune data feeds by removing unnecessary items ................................................................................................................ 95 11 1. INTRODUCTION This chapter introduces building information modeling (BIM), facility management (FM) and the application of the two combined in the architecture, engineering, and construction (AEC) industry. It then gives an overview of sensor, sensor data, and its integration into BIM. In addition, major concepts in BIM and sensor data integration, including visualization, Revit programming, and software development methodologies are also introduced with examples to show how these concepts are used in practice. 1.1 Building information modeling (BIM) According to the definition by US National Building Information Model Standard Project Committee, BIM is “a digital representation of physical and functional characteristics of a facility” (NBIMS-US, 2014). This digital representation (BIM model) is rich in data and information which can be shared for multiple purposes, such as energy simulation, clash detection, cost evaluation, and facility operations and management. Unlike 3D modeling that only describes the geometry of the objects, building information models are based on components (like doors, walls, sensors, etc.) (Kensek, 2014). Traditional building design was dependent on 2D technical drawings such as elevations and sections in computer- aided design (CAD) software. AutoCAD developed by Autodesk was, and still is, the dominant 2D design software in the AEC industry, but the industry has been moving from CAD to BIM in recent years (Huang, 2017). Problems with 2D drawings, such as the loss of information about vertical dimension in 2D floor plans, or the potential incompatibility of the same component in different views (like an object in floor plan view is missing in its corresponding elevation view), can be solved by 3D representations with better legibility (Figure 1.1). Figure 1.1 2D and 3D: The floor plan (upper) and the Revit model (lower) of Watt Hall (Provided by USC Facility Management Services) 12 This 3D digital representation benefits not only designers, but also engineers working with systems including mechanical, electrical, and plumbing (MEP) engineers, heating, ventilation and air conditioning (HVAC) engineers, etc. With BIM, virtual models of complicated pipes and duct systems can be designed. Moreover, BIM also provides chances of integrating models to check the coordination and clashes between different areas of expertise, promoting a cooperative and integrated design workflow (Figure 1.2). Figure 1.2 Integration of architectural, structural, and MEP models of Jill and Frank Fertitta Hall (JFF) in EcoDomus FM (Provided by EcoDomus Inc.) Virtual models helps a great deal with improving the efficiency during designing phase, but the concept of BIM is far more than just virtual models. BIM is an inclusive and collaborative process that involves “a large group of stakeholders from design and construction to operations and maintenance” and “encourage the sharing of data, knowledge, responsibility, risk and reward” (Kensek, 2014). Leading enterprises in AEC industry employ BIM technologies, not only to develop virtual models of buildings before they are built, but also to form a reliable basis for decisions with the help of models during building lifecycle – existing from earliest conception to demolition (NBIMS-US, 2016) (Figure 1.3). These decisions are concerned with subsets of BIM, including but not limited to scheduling, budget, building performance, and facility management applications. Figure 1.3 The lifecycle of a building These various subsets of BIM introduce a key idea of BIM – dimensions. The terminology “nD” is used to define the multidimensional capacity of BIM (Eastman et al. 2011). By reaching higher dimensions, more considerations besides the 3D models per se are involved. For example, 4D models link construction activities to time schedules and 3D models to produce a simulation of construction progress. Other higher dimensions include 5D (cost), 6D (operation), 7D (sustainability) and even 8D (safety) (Smith, 2014). Going beyond 3D has become a trend in modern AEC industry to keep track on building workflow. For example, sophisticated commercial software products such as Autodesk Navisworks enables AEC professionals holistically review integrated models with stakeholders such as 13 the architects, engineers, contractors, and consultants during preconstruction (Navisworks, Autodesk, 2018) . Clash detection, coordination, 5D analysis, and design simulation in Navisworks provide comprehensive support for management of constructability, time, and costs. The process of integration contributes to more completed information, and as a result, a better control over project outcomes (Navisworks, Autodesk, 2018). 1.2 Facility management (FM) The International Organization of Standardization (ISO) defines facilities management (FM) as the “organizational function which integrates people, place and process within the built environment with the purpose of improving the quality of life of people and the productivity of the core business (ISO 41011:2017 Facility Management).” The term “facility” refers to something that is built, installed or established to serve a purpose (International Facility Management Association, 1998). It is generally considered as managing tangible assets necessary for a group or an organization (European Facility Management Data Standard, 2007). Typical examples of tangible assets include buildings, lighting system, heating, ventilation and air conditioning (HVAC) system, furniture, and other specified equipment and appliances. The management of tangible assets alone, however, does not cover all the main ideas about FM. The question of how to serve an organization, in most cases, is equal to that of how to serve the people in the organization. Tangible assets and people in a facility constitute two major areas of FM: “hard FM” and “soft FM” (IFMA “What is facility management?”, 2018). The former deals with space and infrastructure such as the maintenance of building, mechanical, electrical and plumbing (MEP) system, and furniture, whereas the latter focuses more on issues related to work psychology and occupational physiology, such as cleaning, security, mail and delivery service, and catering (Table 1.1). Table 1.1 Two main areas of facility management (IFMA “What is facility management?”, 2018.) Hard FM Space and infrastructure Soft FM People and organization • Building fabric maintenance • Air conditioning maintenance • Decoration & refurbishment • Lift & escalator maintenance • M&E plant maintenance • Fire safety system maintenance • Plumbing & drainage • Minor project management • … • Cleaning • Recycling • Security • Pest control • Handyman services • Grounds maintenance • Waste disposal • Internal plants • … Facility managers (FMs) have the responsibility to ensure that FM services can be implemented in a smooth and efficient manner. The competence of thinking about problems both strategically and operationally is desirable. The strategic aspect involves helping clients understand the potential impact of their decisions on the facility, while the operational aspect is related to day-to-day maintenance and upgrades that affect occupant comfort and costs (“The Roles and Responsibilities of a Facilities Manager”, 2018). 1.3 Leveraging BIM for FM A prominent characteristic that BIM and FM share is a huge amount of data. FMs need to deal with them to keep the function of a building on track and to implement FM services, with the assistance of some kind of tool that gives easy access to necessary information. There are intrinsic synergies between BIM and FM (Hosseini et al. 2018). Moreover, the multidimensional capacity of BIM enables it to store information from FM systems and tools, thus leading to new dimensions added to 3D BIM models. The process of attaching new dimensions, including time, cost, operation, sustainability and safety, helps the integration of FM information into 3D BIM. By such an integration, a BIM-FM framework can be expected as the prerequisite and guideline for developing FM tools. These can focus on several specified phases, or cover all the phases over the building lifecycle. 14 There are some BIM for FM applications before or during the erection of buildings. For example, a project team uses Navisworks to detect clashes between systems in design phase or to monitor building progress in construction phase. The biggest contribution of BIM for FM, however, lies in its long-term competence of providing FM services in the operation and maintenance (O&M) phase. The duration of O&M phase spans 30 years or even more, and the cost of building O&M makes up 75%-85% of the total cost, which imposes considerable influence on and offering possibilities of huge cost saving to the industry (Matarneh et al. 2018). Therefore, for the sake of both energy savings and reduced costs in the long run, an efficient BIM-based tool for FM services, especially hard FM services is necessary. Developing such a tool requires the outright coalescence between BIM and FM, which has yet to be accomplished due to the scarcity of relevant workable solutions (Hosseini et al. 2017). The coalescence allows more space for interoperability by building bidirectional links of data and information between FM systems in a BIM-FM framework. Dispersed systems in a FM framework include, but not limited to computerized maintenance and management system (CMMS), building automation system (BAS), engineering document management system (EDMS), and integration software. To gather information from all those systems above and BIM models, an integration software is necessary to serve as the center of the whole framework. This integration software provides FMs with a visualized interface and linkage from/to other dispersed systems (Figure 1.4). Figure 1.4 An example of FM systems and linkages in a BIM for FM framework 1.3.1 Computerized maintenance and management system (CMMS) CMMS enables facility personnel to spend less time on entering and updating data manually and to concentrate on providing better facility service. Some of main functions of CMMS include generating different service requests, managing work orders, keeping track on resources for executed jobs, and providing control into ongoing maintenance activities (Parzanezhad and Dimyadi 2014). The Facilities Asset Management Information System (FAMIS) developed by Accurent is a proven commercial example of CMMS. A successful application of FAMIS is its contribution to mass work order processing in Anoka County, Minnesota, where facility work orders had been handled with paper documents and phone calls. Such a disorganized system resulted in a low percentage of work order completion (66%). To improve the quality of customer service, FAMIS and its featured automated maintenance process was introduced, and technicians were equipped with mobile devices, so they have more time in field to engage with clients (Anoka County Case Study, Accurent, 2018). Return on investment (ROI) analysis showed a 31% increase of work order completion. 15 1.3.2 Building automation system (BAS) A building automation system (BAS) or building management system (BMS), is a computer-based control system that controls and monitors the building's mechanical and electrical equipment (Building management system, 2018). There is a large number of records of temperature, humidity, flow rate, pressure, power, control signals, status of equipment stored in BAS database (Xiao and Fan, 2014). Modern BAS systems are able to collect more granular levels of facility data, and the connection between BAS and BIM helps FMs better streamline management and decision-making. An example of commercial BAS is Honeywell’s Enterprise Buildings Integrator (EBI) system, a facility management platform that helps reduce operating costs by integrating multiple building control systems (Building management system, 2018). Menkes Tower (Figure 1.5 left), located in Toronto, Canada, employed EBI system to put control of building systems at fingertips through a centralized graphical interface, which enables FM managers to monitor system operations from a single location (Honeywell Case Study, 2012). Across the Menkes Tower, there are more than 50 aspects of integration between systems, including HVAC (Figure 1.5 right), lighting control, access control, video surveillance, parking control, elevator control, and fire alarm, etc. (Honeywell Case Study, 2012). Figure 1.5 Menkes Tower (left) and the schematic diagram of primary chiller water system in EBI (right) (Retrieved from: https://www.ebi.honeywell.com/PDF1/honeywell-hbs-building%20integration- 25%20york%20street%20toronto-case%20study.pdf) 1.3.3 Engineering document management system (EDMS) EDMS is a solution for the management of engineering documents and drawings. Although the documents usually originate from multiple sources, for example, different kinds or versions of CAD applications, they all own metadata that can be shared and they have a longer document lifecycle. Engineering documents and drawings may change and be revised for many times, so they must be carefully managed to ensure that on-site project teams have access to the most up-to-date and accurate information (Engineering Document Management, 2018). Meridian, another product developed by Accurent, gives solutions to engineering document management and proved its success in Huntsman Corporation, a global manufacturer and marketer of chemicals. For safeguarding and improving control of infrastructure documents, information management solution provided by Meridian was implemented (Huntsman Case Study, Accurent, 2018). By integrating a Meridian solution with AutoCAD, SAP PM and Microsoft Office, Huntsman’s asset-related technical information are readily accessible to contractors, CAD engineers, and maintenance engineers (Figure 1.6). 16 Figure 1.6 Document exchange process in Meridian Portal (Retrieved from: https://www.accruent.com/resources/brochures/meridian-portal) 1.3.4 Integration software Integration involves connecting systems through a common interface and ensuring systems do not conflict with each other (Building Integration, 2018). Integration software has the capability of combining information from various types of tools, including BIM software and all the FM systems mentioned previously. The purpose of combining and integrating these dispersed systems is to make sure that all the information is contained and conveniently located in a centralized location (Hunt and Betancur, 2015). Currently many integration software products are cloud-based, so anyone assigned with a username and a password has access to the centralized information. Access from mobile devices such as cellphones or tablets gives brand-new solution to FM services and assistance for on-spot maintenance work. Commercial integration software products include EcoDomus, Autodesk BIM 360, and YouBIM. 1.3.4.1 EcoDomus series EcoDomus provides AEC professionals with a series of products, most popular among them being EcoDomus PM and EcoDomus FM (Figure 1.7, Figure 1.8). EcoDomus PM focuses on the usage of BIM and lean processes for facility data management during new construction or building renovation (EcoDomus PM, 2015). EcoDomus FM supports real-time integration of BIM model with BAS (such as Honeywell, Siemens, Johnson Controls, etc.), with CMMS (such as ARCHIBUS, FAMIS, etc.), and even with Geographical Information Systems (GIS, such as Google Earth, etc.). As a powerful data repository, the data can be always kept up to date across all applications and systems (EcoDomus FM, 2015). Figure 1.7 Check product documentation in EcoDomus PM (Retrieved from: http://ecodomus.com/products/ecodomus-pm/) 17 Figure 1.8 BIM-BAS integration in EcoDomus FM (Retrieved from: http://ecodomus.com/products/masonry-style/) 1.3.4.2 Autodesk BIM 360 series BIM 360 is a series of cloud-base applications that improves project delivery with a wide range of information supporting decision-making throughout the whole lifecycle of projects (Hunt and Betancur, 2015). Up-to-date project information can be easily shared with project team members and displayed on different type of devices. The interoperability of BIM 360 connects people, information and workflows on construction projects, which enables team members to see the whole picture and keep projects on the right track (Autodesk BIM 360, 2018). More specified BIM 360 products intended for professionals from diverse areas of expertise are available for multiple project phases. Some of them include BIM 360 Design, BIM 360 Build, and BIM 360 Glue, etc. (Figure 1.9, Figure 1.10). Figure 1.9 Monitor design changes in BIM 360 Design (Retrieved from: http://blogs.autodesk.com/anztechteam/2018/04/16/bim-360-design/) 18 Figure 1.10 A 3D view in iPad version of BIM 360 Glue, a collaboration software for constructability and clash detection (Retrieved from: https://www.forconstructionpros.com/construction-technology/project-management/blog/11309218/autodesk- bim-360-glue-goes-mobile-with-ipad-app) 1.3.4.3 YouBIM Different from the versatility of BIM 360 in project design and construction, YouBIM focuses more on facility management during post-construction phases similar to EcoDomus FM. This application provides easy and user- friendly navigation through 3D models, and corresponding 2D floor plan views are linked with models to give users a better presentation of visualization (Figure 1.11) (Hunt and Betancur, 2015). YouBIM supports the import of models from multiple programs including Revit and Navisworks, and its work order module helps FM managers to distribute and manage work orders smoothly (Main Features, YouBIM, 2017). Figure 1.11 The juxtaposition of 3D model view and 2D plan view in YouBIM (Hunt and Betancur 2015) 1.4 Sensors, sensor data, and sensor measurements The section gives a brief introduction to the definition, user and classification of electronic sensors. It also gives an overview of sensor data, purposes of sensor analytics, and sensor fault detection. 1.4.1 Introduction of sensors The term “sensor” is also called “transducer” and they have often been used as synonyms, and The American National Standards Institute (ANSI) standard MC6.1 defines a sensor as “a device which provides a usable output in 19 response to a specific measurand (National Research Council, 1995)”. In this definition, an output is an “electrical quantity”, and a measurand is “a physical quantity, property, or condition which is measured (National Research Council, 1995).” Sensors are ubiquitous in daily life, but people are not aware of them most of the time. They can be touch-sensitive sensors installed in any kind of buttons such as elevator buttons or infrared sensors (Figure 1.12 left) placed at the top of automatic doors to detect the passage of people and open the door. Sensors also have wide application in scientific researches, and manufacturing, including automobiles, airplanes and robots, etc. Technological progresses make possible sensors with microscopic scales (Figure 1.12 right) and able to sense and store more accurate data. Figure 1.12 An infrared sensor (left) and a microscopic sensor (right) Retrieved from http://www.tech-faq.com/infrared-sensors.html and https://www.trendhunter.com/trends/tiny-chip-sensors There are many methods to divide sensors into different types. Although finely subdivided hierarchal schemes are developed for the need of academic researches, simple taxonomy such as the physical quantity a sensor measures (temperature, humidity, pressure, etc.) or the mode of input (digital or analog) are referred to and used in practice (White, 1987). Another classification method, which also belongs to the afore-mentioned simple taxonomy, is based on the connectivity of sensors to the other devices or online data repositories. Some early-stage sensors or data loggers like ONSET HOBO UX100, require the installation of data software, and thus the acquisition and management of data is time-consuming. In contrast, recent sensors are equipped with the function of data transmission. For example, ONSET HOBO MX1101 transmits temperature and relative humidity (RH) data wirelessly to mobile devices via Bluetooth Low Energy (BLE) technology (ONSET, 2018) (Figure 1.13). And sensors based on Internet of Things (IoT) are able to send data to the I/O server such as Adafruit IO at regular intervals. Users can manipulate sensor data files on the server more conveniently with a valid username and password. Figure 1.13 ONSET HOBO data logger connected to a mobile phone (Retrieved from: https://www.hobodataloggers.com.au/mx1101) 20 1.4.2 Work with sensor data Sensor data is the output of sensors that responds to a specified kind of measurand (input) from the ambient environment. Sensors give data, but they also bring challenges given the overwhelming volume of data. The original data itself is merely some values and strings stored in data repositories and not easily meaningful at first sight (Figure 1.14). Figure 1.14 Original data file of an IoT sensor installed in USC Watt Hall Therefore, processing and analyzing the data, which is also called “sensor analytics,” is the key to having a better insight into the underlying information hidden in the data. One of the main purposes of sensor analytics is to find trends and patterns. Graphical presentations of data is helpful in understanding how the data fluctuates and if the fluctuation is haphazard or periodic. By reading the trends and patterns, researchers can not only figure out what happened and what is happening, but also predict the change of data in the future. For example, by analyzing and plotting past data from a temperature sensor installed in a Stevenson screen at a weather station, researchers can know how the temperature changed and predict how the future trend and fluctuation pattern might be in following days (Figure 1.15). The same process of analysis can be done for temperature data collected by an IoT sensor installed indoors (Figure 1.16). 21 Figure 1.15 Line plot of past temperature data in Los Angeles (Retrieved from: https://www.timeanddate.com/weather/usa/los-angeles/historic) Figure 1.16 Line plot of temperature fluctuation at Watt Hall Building Science Corner (From 12/02/2018 to 12/13/2018) Another purpose of sensor analytics is to find out anomalies. By examining deviations from a pre-established setpoint, people have a better understanding of what is not in good condition or out of control (Figure 1.17). This is significant for proactively preventing equipment failure, especially on those occasions with human safety issues such as healthcare and manufacturing facilities. For example, an alarm at a nurse station is connected to an intensive care unit (ICU) and it will go off when a patient’s blood pressure drops. Or warning information is generated for troubleshooting and maintenance when a part of heating, ventilation and air conditioning (HVAC) system does not function properly (IoT Agenda, sensor analytics). Figure 1.17 Line plot of past temperature data from an IoT sensor in USC Watt Hall Losses of values indicate the malfunction of the sensor 22 1.4.3 Sensor fault detection The purpose of sensor fault detection is to identify faults, and pinpoint the location and type of them. The “type of faults”, in the context of control engineering, refers to abnormalities associated with the performance of a sensor per se, and they can be divided into four groups: bias, drift, complete failure, and precision degradation (Figure 1.18) (Liu et al. 2011). Methods for sensor fault detection requires the construction of algorithms based on intense mathematical calculation and reasoning. Some examples include Bayesian belief network (BBN) (Mehranbod et al. 2005), neural network, and fuzzy reasoning algorithm (Liu et al. 2011). Figure 1.18 Types of sensor faults: (a) bias, (b) drift, (c) complete failure, and (d) precision degradation (Liu et al. 2011) Hollow circles – normal sensor measurements, filled dots – faulty sensor measurements One thing these methods have in common is that the definition of “faults” can be described as the deviation from normal sensor measurements, which indicates an abnormal working status of sensors due to hardware malfunction or failure. However, there is another interpretation on “faulty” sensor measurements, based on the concept of thermal comfort rather than the performance of sensor hardware. In the context of indoor thermal comfort, “faults” are detected on the grounds of comfort zones. Some main standards of thermal comfort and comfort zones include American Society of Heating Refrigeration and Air Conditioning Engineers (ASHRAE) and International Standardization Organization (ISO). As an example, RH data from one of the data feeds collected is examined with the comfort RH range (20%-80%) defined by ASHRAR 55-2017. Any RH values lower than 20% or higher than 80% will be defined as “faulty” and not desired for good thermal comfort (Figure 1.19). The same rule can be applied to temperature as well. Figure 1.19 Define “normal” and “faulty” values based on comfort zones 23 Types of “faults”, when explained with a comfort zone and a psychrometric chart, are linked with how people feel about the thermal condition in the space where s/he is in. In this context, there can be up to eight types of faults. For example, “hot and dry” “cold and humid”, etc. (Figure 1.20). Figure 1.20 Types of “faults” explained with a psychometric chart (based on Lechner, 1991) 1.5 Manage sensor data feeds: Adafruit IO Adafruit IO is a free cloud-based service that primarily serves to display, store and retrieve real-time data. It is compatible with both hardware and software such as Arduino and Python. With Adafruit IO, users can keep their projects connected to the Internet or other internet-enabled devices. 1.5.1 Feeds Feeds are central to Adafruit IO. They work as repositories of both sensor data uploaded by users and metadata (Figure 1.21). Metadata is like the “note” of sensor data. For example, the date and time when a piece of sensor data information is created, or GPS coordinates (longitude, latitude and elevation) where this piece is from. Figure 1.21 Data feeds from an IoT sensor (Dong, 2019) Data feeds can be added, deleted, downloaded and exported as CSV or JSON files for analysis. Furthermore, they can be shared. Depending on the size of the group with which a user plans to share his/her data, fine-tuned sharing and privacy controls can be applied to allow and restrict access to data feeds. For example, members in a research 24 group can get access to data by validating group leader’s user name and randomly generated “AIO Key” (which will be discussed in Chapter 3) to keep data feeds away from outsiders. 1.5.2 Representational State Transfer (REST) API REST API, also called Adafruit IO HTTP API, provides another access to data feeds using any mainstream programming language, or hardware compatible with HTTP protocol (Figure 1.22). This access does not require an account, while supporting manipulation of data feeds including but not limited to query, feed creation, updating, deletion. Specification documents, with code examples written in Python, are available at Adafruit IO website. Figure 1.22 Adafruit IO REST API specification (Retrieved from: https://io.adafruit.com/api/docs/#) 1.6 Integration of BIM and sensor data With the advent of “smart building” technology, more and more buildings have been equipped with intelligent building automation systems (BAS). In a BAS system, several types of sensors are needed to continuously acquire a large amount of data (Liu and Akinci, 2009). Real-time sensor data helps with evaluating building performance and data-driven decisions related to facility operation and management (Suprabhas and Dib, 2016). The employment of BIM-and-sensor-data integration is not confined to buildings. It also applies to other structures that require daily monitoring and management, such as bridges and dams. One of the strategies to integrate BIM and sensor data is to attach real-time data accumulated in sensors to geometric and spatial information extracted from BIM model (Suprabhas and Dib, 2016). Such a “dynamic” BIM model goes beyond a static source of information that comprises only limited design and construction data. Through this dynamic BIM model, facility managers will be able to visualize and monitor the status of sensors and facilities (Chen et al. 2014). Problems can also be detected and located immediately. Dynamic BIM models have the potential to minimize the cost on facility restoring, and lowering the possibility of abnormal conditions that jeopardize the comfort and safety of building occupants. In addition, when documentation of data is needed, or when assessing the performance of both facilities and their managing personnel, the data saved in the BIM model will be of importance (Chen et al. 2014). An example of integrating of BIM and sensor data is a case study on real time infrastructure sensor, which was carried out by researchers in Virginia Polytechnic Institute and State University. The case study studied combining temperature sensor data and bridge deck model to evaluate the performance of deck de-icing system. Since Revit does not support the direct storage of data, the research team took advantage of Revit Application Programming Interface (API) and wrote an external plugin to make connections between the model and sensor data. With this 25 external plugin, data was imported into Revit in the form of schedules, and data visualization and statistical analyses were realized in separate windows (Figure 1.23). Figure 1.23 The workflow diagram of the case study Line plots record the fluctuation of temperature data collected by different sensors, and bar charts were used to generate the histogram of average temperatures for a specific sensor in a specific month (Figure 1.24). Figure 1.24 The data visualization of the case study (Chen et al. 2014) 1.7 Visualization The term “visualization,” by definition, means “the representation of an object, situation, or set of information as a chart or other image” (Oxford Dictionary). From early stage of initial concepts to the completion and even to the phase of operation and maintenance, different visualization strategies are employed and tailored to needs of clients. For example, the comparison of possible options at design stage, or the check of service integration and interoperability during operation (Bouchlaghem et al. 2005). Based on the aspect of an object that will be visualized, visualization can be divided into two main categories: scientific visualization (Figure 1.25) and information visualization (Figure 1.26). The former puts emphasis on visualizing tangible objects, while the latter focuses on visualization of abstract numeric or nominal data (Card et al 1999, Yang and Ergan 2014). The visualization of tangible spatial and geometrical information, such as walls, ceilings, duct and electrical systems, corresponds to scientific visualization. On the other hand, the visualization of semantic information, such as intangible data sets and high-dimensional data belongs to the category of information visualization (Yang and Ergan 2014). 26 Figure 1.25 The example of scientific visualization: A rendering image of a visit center Figure 1.26 The example of information visualization: Illuminance level in the visit center FM usually involves the visualization of both special/geometrical and semantic information. However, the weight put on these two categories of information is not equal. Since facility management occurs during post-construction phases where the spatial modification to building components is relatively unlikely, the focal point of visualization shifts to semantic information. Building components in O&M phases, to a larger extent, serve as hosts that store semantic information related to them. Some photographs of Honeywell EBI system employed by USC FMS could serve as the example of visualization in FM. The combination of the floor plan of Engemann Student Health Center and temperature data collected from sensors provides FM managers with information about the current temperature in every room (Figure 1.27). 27 Figure 1.27 Temperature monitoring at Engemann Student Health Center The schematic diagram tells how HVAC components are connected and how they interact with each other. Real- time data, such as temperature and flow (gallon per minute) were attached to components to monitor if they are working properly (Figure 1.28). Figure 1.28 Boiler status monitoring at Engemann Student Health Center In case of equipment failures, an alarm interface that lists all failures detected in facilities over the campus is available for FM managers’ reference. Alarms have different priorities so the most urgent ones could always be dealt with at first. The alarm information on this interface is totally text-based, so it is not easy to tell the location of failures at first glance (Figure 1.29). 28 Figure 1.29 Alarm interface 1.8 Revit programming Revit allows users to add new features to its existing functions. These new features can be plugged into the software by coding line by line in Revit API with Microsoft Visual Studio, in Revit Macro development environment, or by coding graphically in Dynamo. 1.8.1 Revit API Revit Application Programming Interface (API) is a tool to develop various plugins. It features the combination of BIM parametric modeling and programming functions. Users can take advantage of this interacting programming method to design and manipulate Revit elements through customized algorithms and computational logics. One of the benefits of using Revit API is that it frees users from repetitive manual operation with automatic batch processing developed for particular functions (Yang et al. 2017). Simple plug-ins are not difficult to create, and many offices have developed them to make certain BIM tasks automated. For example, a plugin called “The Find and Replace Materials” allows designers to find assigned materials in a Revit document and replace them with other materials (Polynine Studio, 2018). Multiple materials can also be selected to be changed to a single material with just a few clicks, thus eliminating most of the manual processing and saving time (Figure 1.30). Figure 1.30 Replace materials by batch processing in a Revit plugin (Polynine Studio, 2018) Since Revit API requires some knowledge of programming and includes many unique features, Autodesk provided users with the Revit Software Development Kit (SDK), which includes a series of helpful documents, sample code, and projects to help users better understand what can be done with Revit API. Revit SDK gives exhaustive description about functions and syntax of namespaces, classes and methods available in Revit API. A namespace is a collection of specified classes, a class includes multiple methods, and a method 29 contains a series of executable statements. Users need to have a knowledge of this hierarchy and the syntax of statements in methods so that properly coded statements can be translated into manipulation of Revit elements. For example, if a developer wants to zoom in to an element, he or she will need to write lines of code following the syntax of ZoomToFit Method in UIView Class and Autodesk.Revit.UI namespace (Figure 1.31). With the abundance of namespaces, classes and methods, users are given more possibilities to develop more powerful plugins and to be in better charge of elements even in complicated Revit projects. Figure 1.31 The hierarchy of namespace, class and method (left) and the syntax of ZoomToFit method (right) There is a wide range of programming languages that are supported by Revit API, including C#, Visual Basic (VB), C++ and Python. C# is the most frequently used programming language in Revit API, and the majority of the sample files in Revit SDK folder are written in C# using Visual Studio (Huang, 2017). When coding for a new plugin in Visual Studio, one of the key steps is to add necessary references. “RevitAPI” and “RevitAPIUI” are indispensable in most cases, and both of these files are in DLL format. DLL is the abbreviation of “dynamic-link library”, and DLL files contain information required for a particular program to run. The purpose of adding references to Visual Studio is to declare these Revit API-related namespaces, and to ensure that all classes and methods under these namespaces can be used for plugin development (Figure 1.32). Figure 1.32 Adding references (left) and namespaces (right) to Visual Studio DLL files also plays central role in plugin (or add-in) manifest files. External commands and applications needs to be registered via a “.addin” manifest file. In this file users need to name the plugin and tell Revit the full path of the plugin assembly file in DLL format (Figure 1.33). This is generated after the plugin code is successfully compiled in 30 Visual Studio. Completed manifest files are used to invoke plugins when Revit starts, and each assembly file is a valid registration for only one plugin. Figure 1.33 Add-in manifest 1.8.2 Revit Macro IDE Revit Macro offers an integrated development environment (IDE) that resembles Visual Studio to allow users to carry out the development (Figure 1.34). A significant difference between Visual Studio and Revit Macro IDE is that the latter requires neither the manual attachment of references to the project, nor the manifestation or registration of external programs. As a result, users does not need to switch between software, which makes testing and debugging more efficient. Another difference lies in how plugins written in standard Revit API and Revit Macro IDE are opened in Revit. Revit API-based programs can create ribbon panels, ribbon item and dropdown menu items in “Add-ins” tab control. On the other hand, these features are not available for Revit Macro IDE-based applications, which can be opened only from Macro Manager. Figure 1.34 The interface of Revit Macro IDE Each macro is a part of a module. There are two kinds of modules in Revit Macro IDE: application-level modules and project-level modules. The former are written to be useful in any Revit document, while the latter are intended for a specific project file and cannot be opened from other projects. The programming languages supported by Revit macro IDE are similar to those in Visual Studio. C#, VB.NET, Ruby and Python are popular choices for building macros. 31 Most macros are designed to help users save time by automating repetitive and predictive tasks or by expediting the process of searching some specified elements (Autodesk, About Macros, 2018). General examples of macros include: a) Locating and extracting Revit content to external files; b) Refining geometry or parameters; c) Importing and exporting file formats. 1.8.3 Dynamo Dynamo is an open source visual programming tool that makes use of the Revit API in a graphic and visualized format. Coding in Dynamo features connecting nodes (commands) with lines. Customized nodes can be obtained by downloading packages, or by directly developing Python scripts. Compared to text-based programming in Visual Studio or in Revit Macro IDE, Dynamo is more friendly to beginners with no programming experience. This feature makes Dynamo a tool not good at complicated and advanced tasks, but an ideal choice for dealing with easy and intermediate tasks (such as automating repetitive work). Some key functions of Dynamo include parametric modeling and parametric geometry analysis. For example, there is a case where a soccer stadium with elliptic façade was modeled (Figure 1.35). Numeric parameters, including those controlling the façade shape, the floor height, and the height of deck tread, can be changed by manipulating sliders (Figure 1.36). By adjusting parameters with sliders, the case provides solution to view quality issues and helps with the design of a stadium consistent with FIFA requirements. Figure 1.35 Parametric soccer stadium design with Dynamo 32 Figure 1.36 Parameters sliders (left) and Dynamo code overview (right) Dynamo also allows the interaction between building components and parameters. For example, the performance of building façades can be evaluated with Dynamo (Figure 1.37). The blue lines indicates the direction from which sunlight comes. Façade units, when lit by the sun, behaves differently based on the amount of sunlight they received. On the east side, units that are directly exposed to light, so they close to block it out and to reduce solar radiation, while on the west side, units are not directly lit, so they open up to compensate for the lack of natural lighting in the morning. In this case, Dynamo connected parameters with geometry, and give designers better understanding of how building components respond to ambient environment. Figure 1.37 Parametric façade design 1.9 Software development methodology To manage software development process efficiently, appropriate methodology that works best for the project at hand must be examined. Typical development methodologies in software industry includes waterfall development, rapid application development (RAD), and agile development. 33 The waterfall development methodology is considered a traditional and rigid linear method that consists of multiple sequential phases. There are generally five phases: requirement definition, design, implementation, verification, and operation and maintenance. Any phase in this method will not happen unless the preceding phase is 100% complete, and traditionally, there is no process or chance for developers of going back to modify the completed part in the project (Software Integrity, 2018). Different from waterfall development methodology, RAD features iterative and incremental delivery of model to the client (SDLC - RAD Model, 2018). This iterative process of developing and feedback allow developers quickly adjust to shifting needs in the constantly changing industry and market (Daud et al. 2010). Due to the uncertainty of needs and requirements, RAD is effective for only projects with knowledgeable and highly skilled developers in the application area (Software Integrity, 2018). The term “agile development methodology” includes several methods, in which extreme programming (XP) is considered widely used among all agile methods (Qureshi, 2012). Like RAD, XP is also an iterative process. It was “proposed based on ideas and practices from previously proposed process models” to reduce the time and costs for developing small projects in small teams (Pressman 2005, Beck 1999). By finding and fixing bugs and defects early on, the multiple iterations help developers improve efficiency (Software Integrity, 2018). 1.10 Comma-separated values (CSV) format A comma-separated value (CSV) file is a special format for text files, in which commas are used to separate numeric and nominal values. It is a widely supported common data exchange format in business and scientific research settings. Different from the definition, CSV files in practice is not a single, well-defined format, and they may refer to any files that (Shafranovich 2005, Comma Separated Values (CSV) Standard File Format 2014): a) Consist of plain text using a character set such as ASCII, Unicode, etc.; b) Consist of records (in most cases one record per line)` c) With the records divided into fields separated by delimiters such as tab, comma, or semicolon; d) The sequence of fields in every record is identical. Notepad and Excel are usually used to open CSV files. The data downloaded from TrojanSense project and processed by the author are displayed as an example. In Notepad, fields are separated by commas. When the same file is opened in Excel, commas are no longer visible, but all data fields have been already in their positions (Figure 1.38). Commas (or other delimiters) tell Excel where every field starts and ends to generate a data table ready for further data analysis and visualization. 34 Figure 1.38 Open the same CSV file in Notepad (upper) and Excel (down) CSV files works well in terms of moving tabular data between multiple software that inherently operate on incompatible formats, and retrieving data recorded by external devices such as sensors (Shafranovich 2005). For example, temperature and relative humidity data stored in a HOBO data logger can be imported into HOBOware Pro, a program that allow users to view, graph and analyze data (Figure 1.39). The program also supports the export of data in several formats including CSV, XLS and TXT, which paves the way for further analyses and researches in other programs. 35 Figure 1.39 The juxtaposition of tabular data and line plot in HOBOware Pro (Retrieved from: https://images-na.ssl-images-amazon.com/images/I/81RLqSXLBHL.pdf) There are some limitations to CSV files. The uniformity of field number in records could be disturbed when the field data contains comma or line-breaks. One of the solutions to the problem is to surround fields with quotation marks, but this brings about a new problem of dealing with field data that already contains quotation marks. To put an end to the delimiter problem, tab-separated value (TSV) files are introduced, in which data fields are separated by tabs instead of commas. 1.11 Summary The chapter introduced some basic concepts of BIM and FM, and how they are combined to make greater contribution during post-construction phases in buildings. It also gave an overview of typical dispersed systems in a complex BIM-FM framework with examples. The integration of BIM and sensor data is linked with and must be based on a wide spectrum of technical concepts and issues ranging from sensors, visualization, programming, software development methodology, and file format. Past research on these aspects will be discussed in Chapter 2. 36 2. BACKGROUND RESEARCH This chapter provides an overview on past researches and case studies of the application of BIM for FM. A BIM-FM framework requires the exchange of information between BIM models and dispersed information systems. In these systems, the chapter focuses mainly on BAS (or BMS), and the integration of its real-time data into BIM models. 2.1 Understanding the framework of BIM for FM The value of BIM application in FM lies in that BIM improves the current manual process of information handover, contributes to more accurate and accessible FM data, and more efficient work order execution (Kassem et al. 2015). However, BIM for FM faces challenges ranging from methodologies, shortage of knowledge about implementation requirement and BIM expertise in FM industry (Kassem et al. 2015). In addition, people do not know enough about the value of BIM for FM due to the lack of real-life cases. Different BIM for FM strategies can be mapped out based on various FM needs proposed by clients. As a result, the framework of BIM for FM differs, and factors such as modeling requirements, BIM-FM interoperability and deployment of dispersed information systems should be considered separately for every single project. This section introduces some case studies of BIM application for FM, with a focus on what information systems are integrated and how BIM interacts with these systems. 2.1.1 Case study #1: Northumbria University (Kassem et al. 2015) Northumbria University is located in Newcastle upon Tyne, UK. The case study started in 2010 and lasted for five years. In the investigation of the University’s information system, it was found that the drawings and information were stored in two different repositories, which resulted in extra workload for manual updates. Scanned elevations, sections, and photos for verifying construction details were also saved in separate environments (Figure 2.1 upper). Dealing with all sources of information was time-consuming and requires attention of FM personnel. Figure 2.1 Comparison between current workflow (upper) and BIM-based workflow (lower) (Kassem et al., 2015) BIM was introduced to simplify FM workflow and reduce the need for technicians. FM personnel do not need to switch between software since these sources are integrated into Revit (Figure 2.1 lower). The use of Revit made possible the automatic and instant update of schedules, elevations and sections, 3D models and renderings. In this case, Revit worked as a hub of information from other systems, and it also provided reliable source of various presentations of information (Figure 2.2). 37 Figure 2.2 Integrated BIM provides FM personnel with various information (Kassem et al., 2015) 2.1.2 Case study #2: Carnegie Mellon University (Yang and Ergan 2015) Researchers from Carnegie Mellon University developed an integrated multi-view visualizer for interfacing HVAC information to support troubleshooting of HVAC-related problems (Figure 2.3). In this visualizer developed with Java, users are exposed to a total of eight modules that collects information from a wide range of information systems. The visualizer integrated floor plan view (d), 3D model view (f) and schematic diagram view with text annotations of sensor data from BAS (e). This combination provides clear representation of the location of HVAC components and helps with the real-time monitoring of their working status. By selecting any components from the list (c), information [(d) (e) and (f)] of the corresponding components will be displayed. The visualizer also supported the management of text-based work order information. In work order context (a), users can specify problem type and problem spatial scope. Information about HVAC system type and control system type is also available. In the complaints log (b), new work orders for the currently displayed component can be created and historical work orders are available for examining the past performance of the component. Figure 2.3 Integrated Multi-view HVAC Information Visualizer (Yang and Ergan 2015) 38 2.1.3 Case study #3: University of Southern California (Teicholz 2013) Facility management in USC is one of the best examples that showcases the links and exchanges of information between systems (Figure 2.4). EcoDomus FM serves as the center of the BIM-FM framework, integrating information from BIM and other systems including CMMS, BAS, EDMS and Computer-Aided Facility Management (CAFM) System. Figure 2.4 BIM-FM framework adopted by USC FMS For example, the 3D view shows the position of an inline fan and highlights it with green. General information about this fan originally resided in CMMS is displayed on the right. And at the same time, the operation and maintenance manual of the fan, which is stored in EDMS, is shown on the same interface as the 3D model and equipment information (Figure 2.5). There is also a BAS-related pane designed for displaying conditional data conventionally managed by the BAS (Figure 2.6). Examining information and data through an integrated interface saves time since FM personnel does not need to switch repeatedly from one system to another. Such integration also helps FM personnel get more comprehensive knowledge about components, and gives technical support to them in case troubleshooting or maintenance work is necessary. Figure 2.5 The location of an inline fan and maintenance manual in EcoDomus (Kensek, 2015) 39 Figure 2.6 Schematic diagram of an air handler from Honeywell BAS system (Teicholz, 2013) 2.2 Integration of Sensor data into BIM The section briefly introduces the role of BIM in integrating sensor data, and focuses on three types of information needed for the integration: sensor data, sensor metadata, and building information. Past research projects and examples follow the main concepts are also given. 2.2.1 Introduction An increasing number of modern buildings have become more intelligent with the help of building automation system (BAS), which acquiring data from numerous sensors. Sensor data, if appropriately used, can be beneficial in terms of assessing building and facility performance and as a result, supporting the decision-making process during the operation and maintenance of a building. However, analyzing sensor data alone does not contribute much to understanding facility condition, since data makes far more sense when they are analyzed in a “context” (Liu and Akinci, 2009). This context can be provided by spatial information from building information models, which enables a visualized and integrated way of data analysis. For instance, by integrating into BIM models data from temperature sensors installed in HVAC systems, FM managers can look for discrepancies between temperatures in adjacent rooms to detect system faults (Teicholz, 2001). BIM is a powerful tool for managing building information during a complete lifecycle. Attempts of integration BIM with various sensing technologies and devices are made in past research projects regarding multiple areas in building automation (Riaz et al. 2014). For example, temperature, humidity, and energy consumption sensors were used to implement post occupancy evaluation (POE) and real-time energy performance in a residential building (Ozturk et al. 2012). Data retrieved from fire sensors were utilized for establishing a fire alarm management system to determine the authenticity of fire alarms and to prevent disturbance because of false alarms (Figure 2.7) (Shiau and Chang, 2014). 40 Figure 2.7 Working interface of building fire control system (Shiau and Chang, 2014) The integration of sensor data with BIM is not confined to indoor environments. An example of such integration is the application of RFID and GPS sensors for building a fusion model that estimates locations of tools, equipment and materials in construction projects (Razavi and Haas, 2009). A second example is the use of load sensors in a crane navigation system where the position of lifted objects are displayed in the context of a building and surroundings. Meanwhile, real-time data is collected through sensors and video cameras (Figure 2.8) (Lee et al. 2012). Figure 2.8 The crane navigation system with a monitor and an adjustable arm (Lee et al. 2012) Information needed for decision-making may differ according to characteristics of projects, but it generally can be divided into three types: sensor reading, sensor metadata, and building information (Liu and Akinci, 2009). 2.2.2 Sensor reading Sensor readings are a series of data ordered by a particular rule, mostly by time. The structure of a reading could vary a lot, but some key attributes such as sensor ID, reading ID, data value, and time stamps are always required. Other attributes besides these key attributes are supplementary, and it is up to users to determine whether they should be integrated into BIM models or pruned. For example, a sensor reading downloaded from Adafruit IO contains up to 11 attributes (Table 2.1). Attributes in bold and italic, such as “id”, “value”, “feed_id” and “created_at”, are four key attributes that are indispensable for the integration into BIM. 41 Table 2.1 Attributes in an IoT sensor reading Attributes Explanation “ id ” “ v a lu e ” “ fe e d _ i d ” “feed_key” “ c re a ted _ a t” “location” “lat” “lon” “ele” “created_epoch” “expiration” The ID for current line of sensor reading. The sensor data value. The ID for the feed. A “feed” is a plain text file consisting of data values and other attributes for a single measurand. The feed key. A unique string used by users to get access to the feed. The timestamp recording when this sensor reading is created. The location where the sensor is installed. The latitude at which the sensor is installed. The longitude at which the sensor is installed. The elevation (height) at which the sensor is installed. Another form of timestamp. The expiration time of current line of sensor reading. One of the main challenges of sensor data readings is the overwhelming increase of data in a short period of time. Therefore, a reliable data repository or a database (online or local) is necessary for the recording and query of data (Liu and Akinci, 2009). However, there is always a limit of capacity for the amount of data that comes into the repository, so a common practice is to discard past readings and replace them with most recent ones. This explains why there is an attribute called “expiration” in Table 2.1. In Adafruit IO, a sensor recording can be kept for a maximum of 30 days. 2.2.3 Sensor metadata Sensor metadata can be considered as descriptions of data, or “data about data” (Dawes et al. 2008). It provides necessary information for sensor discovery and data processing (Liu and Akinci, 2009). Sensor Metadata generally falls into four categories (Dawes et al. 2008): a) Experiment centric static information: experiment background and the phenomena measured by the sensor network; b) Sensor centric static information: background information for sensors including type (temperature, humidity, CO 2, pressure, etc.) and where they are; c) Dynamic sensor information: information about sensor status (working in or out of order, no power or completely broken, etc.); d) Dynamic data quality information – information about data quality when a continuous variable is required. A main purpose of sensor metadata is to easily keep track of anomalies. One case of interpreting faults is used to accentuate the importance of metadata documentation. When faulty values are detected in data analysis, researchers want to find out the sensor that is responsible for these abnormal data values. To locate the correct sensor, a database of sensor metadata including sensor serial number and other categories of supporting metadata can be developed. Such a database works well especially when a lot of sensor of the same type are at the same position in space. A past research project on it is the development of sensor metadata repository (SMR) and its integration with Microsoft SensorMap, a platform for publishing, browsing, and searching for sensor data based on a geospatial interface (Dawes et al. 2008). Points of real-time sensor data are distributed on the map based on the location where sensors are installed. At the same time, users can take advantage of the “time traveler” feature in SensorMap to select any point of time and see sensor data at that point. SensorMap also allows users to share and publish real-time data and metadata from their sensors so the data can be searched on the map (Microsoft Research Blog, 2019). Different types of sensors can be distinguished with different icons (Figure 2.9). 42 Figure 2.9 SensorMap – a sensor data publishing platform by Microsoft (Wang et al. 2015) 2.2.4 Building information “Building information” here refers to spatial information in “building information models” as a means of 3D visualization, and semantic information in “building information modeling” that helps describe a process (Tse et al. 2005). Traditional design stresses on graphic presentation of components in a virtual 3D space, but information that represents deeper elements of component characteristics is likely to be overlooked. For example, when considering a mechanical equipment, some engineers tend to focus on only its geometrical or spatial information such as its dimensions or where it was installed in the building model. However, there are more pieces of historical and predictive information for the equipment about when it was installed, the estimated time of replacement, or the anticipated energy performance, etc. (The information in BIM, NBS, n.d.). By combining some particular properties of building components with physical geometry, varieties of models can be created for analysis and performance evaluation of different aspects. A model can be analyzed for fire strategy if walls, windows, and doors in a BIM model consistently include fire resistance properties (The information in BIM, NBS, n.d.). The same walls, windows, and doors, however, can store thermal properties including R-value, U-factor or solar heat gain coefficient (SHGC) as well. The combination of BIM models and these properties provides necessary information for simulations of energy consumption and performance. Semantic information embedded in building elements gives support to their versatility in analyses covering a wide range of subjects and to more efficient and visualized facility management during phases of operation and maintenance. 2.3 An example of BIM-BAS integration: Dasher 360 The section begins with an introduction and investigation of Autodesk Dasher 360, a BIM-based platform that integrates sensor location records and sensor data into 3D models. The interface and main functions of Dasher 360 provides information about what should be achieved in Adafruit IO Reader and what features not available in Dasher 360 can be added to the Reader. 2.3.1 Introduction There are many digital tool for designers to evaluate the building performance, such as Sefaire Architecture, Green Building Studio, and IES Virtual Environment (VE). But they are mostly intended for simulating performances during the design phase of the building instead of monitoring real-time performances for a building in operation. In addition, these simulation tools are not ideal for providing adequate real-time information for reducing energy consumption, and adjusting indoor environment to respond to the changing patterns and thermal comfort needs of occupants. 43 Dasher 360 developed by Autodesk helped bridge the gap (Autodesk Dasher 360, 2018). It is an ongoing Autodesk research project featuring the integration of BIM and BAS (or BMS). The introduction of BAS data makes BIM a tool that can be used throughout the whole lifecycle. The first step of integration is to install networked sensors in working spaces. Different types of sensors measuring temperature, humidity, CO 2 concentration, light intensity and sound level were placed in working spaces. Location of sensors were then translated into the position of sensor families in Revit so BIM models with sensor models became available. Finally, models and sensor data values are integrated and can be accessed by users on a web-based interface (Figure 2.10). In Dasher 360, users can choose any sensor both from the sensor list and the model. When choosing a sensor from the list, users can click on the sensor name to examine the historical data values in a line plot. When choosing from the model, users need to point the cursor to the sensor (which is represented by a dot) to check the value. By clicking on the “Go To Sensor” button next to the sensor name, users can be navigated to where the sensor is installed in the model (Figure 2.11). Figure 2.10 The user interface of Autodesk Dasher 360 Figure 2.11 Sensors, sensor list and data plots in Dasher 360 44 2.3.2 Evaluation of Dasher 360 Overall, as an ongoing research project, Dasher 360 presented an excellent integration of BAS data into BIM by locating multiple types of sensors in the model, and by appending real-time sensor data to these models. Dasher also provided a full sensor list and quick navigation to desired sensor models with one click. The dominant means of visualizing sensor data in Dasher 360 is line plots, which is easy for FM managers to read the fluctuation of data values. However, there are still some room for Dasher 360 to improve. A major limitation is that it only visualizes data and put data into line plots, but there seems to be a lack of alert information related to potential problems with sensors and data. For example, the loss of a large amount of data values observed in March 2015 should be paid attention to by giving warnings, either somewhere on the main interface or in the sensor list, in order to figure out the cause of this data value loss (Figure 2.11). These warnings are important in terms of reminding users of sensor malfunctions during real-time data monitoring and provide information for locating and fixing problematic sensors. To achieve this feature, Dasher 360 may need to introduce some algorithms for fault detection to differentiate faulty values from normal values to give FM managers a better insight into the optimization of indoor environmental indices for better thermal comfort and energy savings. 2.4 Fault detection algorithms Fault detection has successfully played its role in many engineering domains including automotive and industrial manufacturing for decades, but its application in AEC industry is still under development (Bonvini et al. 2014). Real-time data in buildings need to be monitored to ensure the proper function of facilities and equipment. At the same time, however, detecting anomalies among data sets and problematic behaviors associated with them is also indispensable. 2.4.1 Statistical generation model (SGM) (Sallans et al. 2006) Different strategies and algorithms for fault detection and alarm generation were proposed by past researchers. A straightforward implementation of fault detection is realized by taking advantage of a “statistical generation model (SGM)” proposed in a research related to BAS. First, a model is constructed based on normal behavior. Then, parameters in this normal behavior model is optimized with a maximum likelihood algorithm. With this optimized model, incoming values are examined and compared to this model. “Logarithm likelihood” or “log-likelihood” is the key to the SGM model since it determines whether a value is normal or faulty (Figure 2.12). Every value in the SGM model has its log-likelihood of appearance. A value will be considered as faulty if this log-likelihood falls below a specific threshold. Figure 2.12 Sensor data values (blue) and corresponding log-likelihood (red) (Sallans et al. 2006) Faulty values register as abrupt falls of low log-likelihood 45 2.4.2 Adaptive-neuro fuzzy inference system (ANFIS) (Liu et al. 2011) Another method of fault detection is called “Adaptive-neuro fuzzy inference system (ANFIS)”, in which neural network learning algorithms and fuzzy reasoning are used. In ANFIS method, a squared prediction error (SPE) index is invented to detect sensor faults by calculating the deviances of measured values from predicted values. When ANFIS method is used, SPE index can be calculated with the following formula: 𝑆𝑃 𝐸 𝐴 𝑁𝐹𝐼𝑆 = | 𝑦 𝑚 − 𝑦 𝑝 | 2 where y m stands for measured values and y p for predicted values. To test the fault detecting ability of ANFIS method, researchers introduced a complete sensor fault of 100 μg/m 3 to a PM 10 sensor from the 80 th sample (Figure 2.13 left). Test result showed that the SPE index increased quickly and exceeded the threshold value marked by the red line (Figure 2.13 right). This result indicates that large deviances of measured values from predicted values happened starting the 80 th sample, and the sensor is not working properly. It can also be observed that the SPE index values fluctuates intensely as soon as the fault was introduced, with some values fall back to below the threshold value. These values after the 80 th sample and below the line are incorrect results, because they indicate that the sensor is working properly, which is contradictory to the fact. Therefore, a limitation of this method is the accuracy of results. Figure 2.13 Sample sensor data for test (left) and SPE index (right) (Liu et al. 2011) 2.4.3 Other advanced algorithms Besides SGM and ANFIS method, there are also a great variety of more advanced fault detection algorithms. These advanced algorithms are more robust and accurate, and usually involve the application of machine learning and/or artificial intelligence. There is an algorithm that features the “prediction-correction” process, during which an updated estimation of system state is provided every time a new measurement is available (Bonvini et al. 2014). In addition, machine learning can be combined with a probabilistic model of prediction produced as a result of Gaussian process regression to detect malfunctions in HVAC systems (Every et al. 2017). 2.5 Summary This chapter introduced the role of BIM for FM with three case studies. “Integration” is a key concept in BIM for FM. In all these cases, there is always a platform or an interface that integrate information. BIM software such as Revit, FM software such as EcoDomus, and even an independently developed application can serve as the hub for gathering information from other systems such as CMMS, EDMS, BAS, etc. Among these systems, BAS is important because it contains numerous amount of data. Strategically integrating the data into BIM is able to largely benefit the evaluation of building performance and support the decision-making during operations and maintenance. A typical example of such BIM-BAS integration is Dasher 360 developed by Autodesk. Dasher 360 collects data from a wide range of sensors including temperature, RH, CO 2 concentration, sound level and light intensity sensors. 46 Dasher 360 gives excellent support to the visualization of sensor data information with graphs and quick navigation to sensors in the BIM model, but the lack of sensor fault detection is a main limitation. These advantages and drawbacks of Dasher 360 will give some inspiration to the development of Adafruit IO Reader, which will be presented in Chapter 3. Fault detection are achieved by developing algorithms. Some of them are quite simple and straightforward, such as statistical generation model (SGM) based on logarithm likelihood and Adaptive-neuro fuzzy inference system (ANFIS) based on squared prediction error (SPE) index. However, these algorithms sometimes may lead to incorrect results. Advanced algorithms using machine learning and/or artificial intelligence are more ideal for tasks that requires correctness. 47 3. METHODOLOGY This chapter introduces the overall workflow from preparation, tool development to validation of usability, and how cloud-based platform (Adafruit IO Server), hardware (IoT sensors) and software (Autodesk Revit including the Macro Manager) are connected and used to develop Adafruit IO Reader. The background of the case study, process of retrieving and processing sensor data feeds, and building the relationship between these feeds and sensor models are analyzed in detail in the tool development section. 3.1 Overall introduction of the workflow There are three phases to the workflow: preparation, tool development, and validation of usability (Figure 3.1). Adafruit IO Reader works as a Revit plugin that integrates IoT sensor data and BIM to visualize sensor data and navigate users to corresponding sensors in Revit. Figure 3.1 Methodology and design workflow 3.1.1 Preparation The section introduces development methodology, developing environment and programming language adopted for coding Adafruit IO Reader. It also gives an overview of past methodologies and the reason why they were discarded. 3.1.1.1 Development method and environment The first step for preparing tool development is to determine the methodology that best fits the size of the program (Figure 3.2) . 48 Figure 3.2 Preparation Based on the characteristics of different development methodologies, the most traditional linear waterfall model was chosen for the tool development. The requirements and needs for developing this tool are not as prone to change as those in projects with long duration and high complexity. In addition, the size of group involved in the development process is quite limited, so it might be exaggerated to take advantage of development methodologies that are more suitable for middle or big scale projects. The code that supports the visualization tool were developed in Revit Macro IDE. An application level macro is more desirable to ensure that the tool can be opened in more than one Revit session (Figure 3.3). A second reason for choosing Revit Macro IDE is that all necessary references have been loaded automatically when a new macro is created. Furthermore, the steps of manual manifestation and registration for those plugins made with Visual Studio are nonexistent if a developer opts to do the programming in Revit Macro IDE. C#, one of the most widely used programming language, was used to develop the interfaces and underlying logics of the tool. Figure 3.3 The application level macro “NewReadAdafruit” in the Macro Manager 3.1.1.2 Trial and error – past approaches Sensor data and 3D models are two key items necessary for tool development. Before proceeding to coding work, it must be ensured that a) The data can be acquired for a relatively long period of time; and b) The models, and every single element that comprises them, can be manipulated (for example: applying color fill / outline or changing material, etc.) by codes. 49 Prior to the most recently adopted method of retrieving data from Adafruit IO server and its API, and manipulating model elements in Revit, some different methods were tried but all of them proved to be technically challenging or even infeasible due to access authorization, software architecture or file format. For example, when working on data retrieval, a remote data services (RDS) API was provided to acquire sensor data (Figure 3.4). This RDS API is managed by USC FMS and is able to check a wide variety of information besides sensor data such as alarm information and alarm priority in HVAC systems. However, this API has restrictions on access authorization, and as a result an application to FMS staff for registering user IP address is required. This did not work well for implementing research on campus since the IP address of the network services changes frequently. Adding multiple IP addresses is cumbersome and impractical for FMS staff since nobody has the idea about what the next IP address will be. In addition, the duration of access provided by FMS is limited (usually no more than one month). Figure 3.4 Read sensor data from Honeywell system in RDS API Provided by USC FMS and David Adkisson (EcoDomus Inc.) Several attempts to deal with models proved not successful as well. Initially the idea for tool development was to make a Windows Presentation Foundation (WPF) or Windows Form (WF) application in Visual Studio that displays both 3D models and sensor data linked to these models. To do this, models must be first imported from Revit in FBX format (the only format that Revit exports and Visual Studio reads). Problems of compatibility happened after FBX models are imported into Visual Studio, and no solution led to “manipulatable models in application interface” (Table 3.1). Table 3.1 Attempts to import 3D models into tool interface created by Visual Studio Plan Revit Import Result Visual Studio Plan A FBX model → IMPORT FAILED → WF application Plan B FBX model → IMPORT FAILED → WPF application Plan C FBX model → IMPORT SUCCEEDED → Visual Studio Model Viewer → IMPORT FAILED → WF application This issue with compatibility is not limited to Visual Studio. It also happened in EcoDomus. Although 3D models can be exported from EcoDomus, they cannot work with any other applications due to their file format – ECD. It is a proprietary file format for the company, therefore it is not an ideal format to work with. The failures resulted in several major changes of methodology at the beginning of the research, but finally they led to the use of Adafruit IO for data retrieval and Revit for model display. The advantage of working with these tools lies in the prolonged and easy accessibility to raw data, and the easiness of interacting with model elements through codes. 50 3.1.2 Tool development This section introduces how specific pieces of information including sensor data and 3D models are collected. Some information or methods for collecting information are discarded with the reason explained. Main features to be achieved are also defined, which reveals some clues to tool interface design highly dependent on these features. 3.1.2.1 Work with data and models Since the tool development focuses on the integration of real-time sensor data into BIM models, both of these need to be collected before coding. The collection requires working with various equipment and programs, and collected items can then be used to develop the application with necessary features (Figure 3.5). Figure 3.5 Tool development The collection of data depends on the “connections” between hardware, cloud-based platform, and software. These connections guarantee successful transmission of sensor data and is the basis of tool development. Two types of connection can be found in the developing process. A unidirectional connection exists between Beacon sensors (hardware) and Adafruit IO Server (cloud-based platform). Sensors collect data, and upload them to the Server. In contrast, the interaction between the cloud-based platform and software is bidirectional. Adafruit IO Reader (Software) developed with Macro IDE in Revit initiates requests for synchronization to retrieve data from the Server, and at the same time, the Server provides data files by downloading them to a local folder and importing to Adafruit IO Reader. Note that not all data from the Server are necessary. For example, IoT sensors in the research collect real-time temperature, relative humidity (RH) and voltage data. However, researchers might want to focus only on those measurands that are directly associated with the ambient environment. Therefore, in this case, only temperature and RH data values were collected. These values are combined with pre-defined parameters including setpoints and comfort zone ranges (threshold values) to generate alerts when there are sensors that fault. The acquisition of the building information models is quite straightforward (provided by USC FMS), but the main concern is to put them in an environment that allows the manipulation of models with codes. This can be easily achieved by Macro IDE. The visualized developing environment not only helps with making an application that integrates sensor data into BIM, but also supports namespaces and methods in Revit API, allowing the interaction of users with model elements. After real-time sensor data and BIM were in their places, the development of interfaces and windows followed. Based on the defined requirements, there were nine main features to be coded, and they were divided into three categories: 51 Files and user settings 1) Read sensor data file from Adafruit IO server and save them in a designated local folder; 2) Save customized options by writing to and reading from a configuration file (INI file) to ensure that they will not lose when the program is relaunched; Data display and visualization 3) Display the data in both data tables and plots; 4) Tables and plots in 3) can be switched between “full” mode and “partial” mode based on a time range set by the user; 5) Tables in 3) can be switched between “all values” mode and “faulty values only” mode; 6) Navigate tool users to sensors with faulty values and highlight their positions in BIM models; 7) Attach sensor photographs that match the sensor model; Comfort zone 8) Set temperature and RH comfort zone to define “normal” and “faulty” values; 9) Highlight loss of values and/or values out of comfort zone (“faulty” values) with different color schemes in data tables; The detailed methodology of tool development, including the access to REST Web API and the algorithm of fault definition, is introduced in section 3.2. 3.1.2.2 Interface design The interface design of the tool should feature the interaction between BIM and visualized sensor data. A concept imagery describes the final output of the tool interface. This provides a better understanding of how the tool will look like and what can be done with it (Figure 3.6). Figure 3.6 Concept imagery of tool interface The menu bar items concentrate on commands related to sensor data files or settings of indoor environment parameters for fault detection (Figure 3.6 (a)). For example, commands such as synchronizing sensor data with Adafruit IO server, or clearing all currently displayed data tables can be found in File dropdown menu. The setting of comfort zones, let it be an ASHRAE or ISO comfort zone, or even a customized one, can be found in Edit menu. 52 Since there are multiple IoT sensors used during tool development and case study, it is necessary to switch from a sensor to another one to check their working status. This was achieved by putting a combo box with the name of the places where the sensors are installed (Figure 3.6 (b), Figure 3.7). Every time a sensor is selected, the Revit element ID of the sensor updates (Figure 3.6 (c)). Data tables and plots are refreshed, and users are re-navigated to the 3D sensor view in Revit. Figure 3.7 Combo box The presentation of sensor data tables and plots it the key part of the tool. Tab controls that allow users to switch between data table and corresponding line plot were designed to take up most of the space on the interface (Figure 3.6 (e)). Based on the definition of comfort zone in menu bar, faulty values beyond the comfort zone can be highlighted with colors indicating if the value is too high or too low (Figure 3.8). Figure 3.8 Concept imagery of data table and line plot Shortcut buttons serve as quick accesses to key features such as data synchronization, table / plot refresh (Figure 3.6 (d)). The number of shortcut buttons is subject to change as the tool development progresses. 3.1.3 Validation of usability During the post-development phase, the usability of completed tool was evaluated. IoT sensors in Watt Hall (WAH) were used as a case study (Figure 3.9). Figure 3.9 Validation of usability The main evaluation items included the following: a) The connections of cloud-based platform (Adafruit IO Server) with hardware (IoT sensors), and software (Adafruit IO Reader) are effective through validating synchronizations of data with the Server; b) All features and functions coded (1-10 in Section 3.1.2.1) work properly as expected and/or produce correct outputs. Only under the circumstances where both items are checked and considered successful can Adafruit IO Reader be deemed effective, or usable. 53 3.2 Detailed workflow of tool development The tool developments is feature-oriented and can be divided into three sections: data retrieval and pruning, fault definition, sensor model visualization (Figure 3.10). Features in Adafruit IO Reader were realized either using information from only one section (e.g. feature #1 – #4, #6 – #9), or combining information from multiple sections (e.g. feature #5). Figure 3.10 Detailed workflow of tool development with the feature checklist 3.2.1 Section #1: Data retrieval and pruning The first section concentrates on building the “hardware-platform-software” connection for data retrieval and pruning (Figure 3.11). Figure 3.11 Data retrieval and pruning IoT sensors update data at a regular interval of 15 minutes. All data are stored on Adafruit IO Server, and users can sign in with a valid username and password on the Adafruit IO homepage to get access to data, but this can also be achieved without signing in. The strategy is to do an HTTP query to get data feeds with a specified username and AIO key (Figure 3.12). This key is a combination of randomly generated numbers and lower-case letters, and can be found on the user dashboard and regenerated for security consideration (for example, when this key is known by someone who should not have known it). 54 Figure 3.12 The Username and Active Key (AIO Key) for author Part of the key is intentionally blacked out With the username and the AIO key, a query that gets all available feeds from the user can be as simple as a URL in web browsers, like this: https://io.adafruit.com/api/v2/{username}/feeds?X-AIO-Key={AIO key} On this feed information page, all feed IDs and feed keys for current user are available (Figure 3.13). Figure 3.13 The feed information page that records information about all feeds The string “key” is highlighted And a query that gets all data from a feed looks like this. Every feed in Adafruit IO is assigned a unique feed key that can be used to check real-time data in this feed. https://io.adafruit.com/api/v2/{username}/feeds/{feed key}/data?X-AIO-Key={AIO key} After replacing the strings in the braces with a valid username, feed key and AIO key, users will be led to the data feed file. It includes not only data values, but also information about the data ID, feed ID, feed key, created time, created epoch and expiration time (Figure 3.14). 55 Figure 3.14 The original data file that records sensor data values and related information In addition to checking out information about all feeds or feed data values, there are also a great amount of commands that make changes to feeds, such as inserting, replacing and deleting, etc., as long as the username, feed key and AIO key are provided. This simplicity of authentication allows more user to get access to and manipulate data without signing up for an Adafruit IO account, and improves the efficiency of sharing data within a research group. However, this simple retrieval of data requires that everyone involved takes confidentiality very seriously. In case the key is accidentally given away to non-group members, the research advisor or group leader can generate a new key to make the previous one invalid. The original data files were downloaded from Adafruit IO Server and saved as CSV files by executing C# codes in Revit Macro IDE (see Appendix A). But these CSV files need to be pruned before they are imported into the Adafruit IO Reader. The process can be divided into three main steps: prune, reorganize, and translate date and time. The first step of pruning is to reduce redundancy. The file contains many secondary attributes that do not have values (null) or are not relevant to the needs of the Adafruit IO Reader (Figure 3.14). The tool should omit all supplementary information and focus on only primary attributes, including “value”, “feed_id” (feed ID) and “created_at” (the time when the value is created). Table 3.2 The first step – pruning attributes in CSV files Before pruning After pruning “id” “value” “feed_id” “feed_key” “created_at” “location” “lat” “lon” “ele” “created_epoch” “expiration” “value” “feed_id” “created_at” The second step is to reorganize these files to make sure the information can be displayed in correct positions when they are opened with Excel. In the CSV files after the first step, attributes and their numeric or nominal values are in 56 pairs and this formation applies to the whole file from the first to the last line. Therefore, all the attributes should appear only in the first line as the header of data tables (Figure 3.15). The rest of the file belongs to values that corresponds to attributes. Square brackets (“[]”), braces (“{}”), and quotation marks (") were completely removed from data files. BEFORE [{"value":"75.38","feed_id":886572,"created_at":"2018-11-25T01:50:34Z"}, {"value":"75.38","feed_id":886572,"created_at":"2018-11-25T01:35:32Z"}, {"value":"75.38","feed_id":886572,"created_at":"2018-11-25T01:20:24Z"}, {"value":"75.56","feed_id":886572,"created_at":"2018-11-25T01:05:21Z"}, {"value":"75.56","feed_id":886572,"created_at":"2018-11-25T00:50:13Z"}, ... AFTER value,feed_id,created_at 75.38,886572,2018-11-25T01:50:34Z 75.38,886572,2018-11-25T01:35:32Z 75.38,886572,2018-11-25T01:20:24Z 75.56,886572,2018-11-25T01:05:21Z 75.56,886572,2018-11-25T00:50:13Z ... Figure 3.15 The second step – reorganizing attributes and values The first few lines are used as examples The third step is to work with time and date. Because the time recorded in these data files are based on Zulu Time or Greenwich Mean Time (GMT), which is 8 hours ahead of Pacific Time in Los Angeles, all the hour values need to be subtracted by 8 to do the time zone conversion (add 16 to hour values and subtract day value by 1 if hour values is less than 8), and get all “T” and “Z” removed by replacing them with spaces (Figure 3.16). The sensors do not know that they are in Los Angeles or where they are located in the building. They need to be told this. BEFORE (Zulu Time) value,feed_id,created_at 75.38,886572,2018-11-25T01:50:34Z 75.38,886572,2018-11-25T01:35:32Z 75.38,886572,2018-11-25T01:20:24Z 75.56,886572,2018-11-25T01:05:21Z 75.56,886572,2018-11-25T00:50:13Z ... AFTER (Pacific Time) value,feed_id,created_at 75.38,886572,2018-11-24 17:50:34 75.38,886572,2018-11-24 17:35:32 75.38,886572,2018-11-24 17:20:24 75.56,886572,2018-11-24 17:05:21 75.56,886572,2018-11-24 16:50:13 ... Figure 3.16 The third step – converting Zulu Time into Pacific Time All the steps above are realized by a C# function in Adafruit IO Reader (see Appendix A). CSV files after pruning are ready to be imported into the tool and displayed in both tables and line plots. In addition, these files will be 57 connected to sensor models in Revit to achieve the goal of visualization through combining real-time sensor data and 3D models. 3.2.2 Section #2: Fault definition The second section deals with fault definition. Two types of faults are considered in the tool development: loss of data values and values out of ranges (Figure 3.17). Figure 3.17 Fault definition “Loss of data values” means there is no valid temperature or RH data at a specific point of time. This results in a “nan” (no value, Figure 3.18) in a data table and it is often related to hardware glitches or battery power issues. Figure 3.18 Loss of data values (red rectangle) in “value” column “Values out of ranges ” indicates the existence of abnormal sensor data values. The definition of “ranges ” is based on ASHRAE 55-2017 comfort zone, in which temperature ranges from 68 ℉ to 78 ℉, and RH ranges from 20% to 80% (Figure 3.19). Besides ASHRAE 55-2017, ISO 7730 can also be used for defining ranges. All data values that do not fall in these ranges are treated as “faulty ” and result in colored cells in data tables on the main interface (Figure 3.20). 58 Figure 3.19 Psychometric chart with the ASHRAE 55 comfort zone (Lechner, 1991) Figure 3.20 Data values out of range with color schemes Orange – higher than the maximum; light blue – lower than the minimum In addition to ASHRAE and ISO comfort zones, users are free to customize these own comfort zones to fit the needs of thermal comfort in different places. However, there is a problem with customized comfort zones. Manually set numeric values will be reset to default values after the program is restarted. Therefore, an extra configuration file that stores these values is required to save customized settings. Customized values are written to this file from comfort zone dialog box in the tool, and they can be read from the file to replace default values when the same dialog box shows up. Introducing the configuration file reduces repetitive typing work, which renders Adafruit IO Reader more user-friendly. 59 3.2.3 Section #3: Sensor model visualization The third section focuses on various visualization strategies, including 3D models with color schemes and on-site photographs (Figure 3.21). This visualized information was combined with data files to finally accomplish the main goal of Adafruit IO Reader: to integrate real-time sensor data into BIM. In this section, a case study is needed for the integrating process. Figure 3.21 Sensor model visualization 3.2.2.1 Models and sensors for the case study Watt Hall, the headquarter of School of Architecture and School of Arts, was selected as the case study building (Figure 3.22). The five-story building covers a net area of 67,855 square feet, with three stories above ground and one underground with a mezzanine (Figure 3.23). Figure 3.22 Watt Hall 60 Figure 3.23 A section of Watt Hall (Provided by USC FMS) The sensor product for collecting data is ASAIR AM2302 IoT sensor (Figure 3.24 left, middle). They were appended to 3D-printed shells and connected to ESP32 boards. ESP32 is a low cost and low power system on a chip microcontroller with Wi-Fi and Bluetooth modules. These sensors collect temperature, relative humidity, and voltage data. Figure 3.24 IoT sensors (left, middle) and ESP32 board (Right) Five IoT sensors are installed in different locations in Watt Hall for data collection (Figure 3.25). These sensors are originally installed by a researcher from a project named TrojanSense (Figure 3.26). In this project, real-time sensor data are collected and analyzed along with occupants’ expected thermal status to establish a data-driven comfort model that lends credibility to adjusting HVAC systems (Dong, 2019). Temperature and RH data in Watt Hall third floor southeast corner (building science corner), Upper Rosendin (two sensors), Watt 212, and Watt B1 was gathered and at the same time uploaded to Adafruit IO server. With the approval from the leader of TrojanSense project, the access to sensor data feeds on the server was granted for the development of Adafruit IO Reader. 61 Figure 3.25 Locations of sensor installation in Revit and their photographs Figure 3.26 The interface for submitting users’ feedback in “TrojanSense” app (left) and the campus map in “TrojanSense” project with users’ feedback results (right) (Dong, 2019) 3.2.2.2 Relationships between data feeds and sensor models “Connections” exist in the development workflow to link hardware, cloud-based platform and software (See Section 3.1.2.1). Here, another type of “relationships” was introduced to describe how data feeds and sensor models in Revit are related. Fox example, data feeds collected by The IoT sensor in Watt Hall Building Science Corner and the corresponding sensor model are bound together with such a relationship (Figure 3.27). 62 Figure 3.27 The relationship diagram describing how data feeds, sensor ID and sensor models are connected The relationship between the sensor and data feeds is a many-to-one relationship. That is to say, a data feed belongs to only one sensor, while a sensor has more than one data feed. Every IoT sensor takes up to three feeds: temperature, RH, and voltage, and every data feed is assigned a unique feed ID, which means if the feed ID is known, the sensor that holds this feed can be found as a result. The relationship between the sensor ID and sensor model is one-to-one. A sensor ID belongs only one sensor model, and a sensor model is assigned only one sensor ID. The feed IDs and the feed keys are obtained from the feed information page (Figure 3.13), and the sensor IDs can be acquired after sensor models are made in Revit (Figure 3.28). Note that the uniqueness of sensor ID is limited to the current Revit project file. For example, there is only one sensor model with an ID “1304799” in this project, but there might be another sensor with the same ID “1304799” in any other projects. With the “feed-sensor” relationship built, sensor data feeds can be attached to sensor models. Data feeds with loss of values or “faulty” values defined by comfort zones resulted in red shape outline that highlighted the sensor (Figure 3.27). Highlighted sensors always appear in pairs with corresponding data tables. By this combination, both numerical and visualized information of faults can be provided. Figure 3.28 Get sensor model ID in Revit Currently information about five IoT sensors is available in Adafruit IO Reader in Watt Hall (Table 3.3). Voltage data is not considered since it is not a measurand that directly associated with the ambient. Three more sensors might be set up in the future and users should be able to add these to the tool. Table 3.3 Information about IoT sensors in Watt Hall Sensor Name Sensor ID Feed IDs Feed key Watt Hall Building Science Corner 1304799 Temperature 886572 node-13.temp RH 886573 node-13.humid Watt Hall Upper Rosendin 1304568 Temperature 882272 node-7.temp RH 882273 node-7.humid Watt Hall Lower Rosendin 1305148 Temperature 882314 node-8.temp RH 882315 node-8.humid Watt Hall 212 1304930 Temperature 886566 node-11.temp RH 886567 node-11.humid Watt Hall B1 1305363 Temperature 874783 node-3.temp RH 874784 node-3.humid 63 3.3 Summary This chapter introduced the overall workflow from preparation, tool development to validation of usability with a case study of Watt Hall. “Connections” and “relationships” are two key concepts that should be emphasized throughout the whole workflow. Adafruit IO Server connects hardware and software. As a cloud-based platform, it plays the central role of collecting data from IoT sensors (hardware) and offering a source of data that can be accessed through REST API for tool (software) development. IDs, including feed IDs and Revit element IDs, built the many-to-one relationship between multiple data feeds and the single sensor model to which these data feeds belong. Developed Adafruit IO Reader should help with integrating real-time sensor data feeds into BIM, and locate the locations of sensors with loss of values or “faulty” values based on defined comfort zones. The tool provides both numerical and visualized information for managing indoor thermal comfort, together with comfort zone customizations to enhance the tool flexibility. With the Watt Hall case study, the validation of tool usability focuses mainly on examining the afore-mentioned “connections” and “relationships,” and tool features based on them. Key features such as data synchronization and visualization, comfort zone definition by presets, warning generation and navigation to sensor models constitute the basis of the tool. New features including customization of comfort zones and manipulation of data tables / plots provide more flexibility. Program development of tool features will be analyzed in detail in Chapter 4, and the source code is available in Appendix A. 64 4. PROGRAM DEVELOPMENT With sensor data feeds collected and tool features defined, this chapter gives an explanation to how Adafruit IO Reader is developed with source codes. The tool development is made up by coding multiple features and are organized by files and user settings, data display and visualization, and comfort zones. These features were programmed in the Revit Macro IDE and are explained individually in this chapter. They were assembled together to achieve the completed form of Adafruit IO Reader. The entire code is in Appendix A. A case study is given in Chapter 5. 4.1 Files and user settings This section introduces the development process of features related to retrieving, pruning, and synchronizing sensor data feeds, and saving customized user settings. 4.1.1 Data retrieval, pruning and synchronization The retrieval of data feeds used a for loop that repetitively downloads a total of ten data feeds. A string “CurrentTxtFile” is defined to indicate the data feed that the program is currently downloading from the Server. By adding one to integer variable “FileCounter” every time the loop was executed, the content of “CurrentTxtFile” string changed, and consequently, a new data feed was downloaded until the end of the loop (Figure 4.1). Data feeds downloaded from the Server were saved to a local folder, whose address was defined by a string “RealTimeRepository”. In the download URL, a valid username and AIO key are necessary to get the access to files on the Server. Figure 4.1 Retrieve data feeds from Adafruit IO Server Sensitive data is intentionally blacked out Feeds need to be pruned before importing into Adafruit IO Reader. The three-step pruning process is done by removing unnecessary items from the original data feeds (Figure 4.2). All the removals are done with replacing commands. The first step was to remove square brackets and braces from data feeds. Left square brackets and braces were simply removed, while right square brackets and braces were replaced with commas, line breaks (“\n”), or a null character (only at the last line). The second step was to remove attribute names and keep attribute values. Note that on the sixth line in Part 2 in Figure 4.2, some attribute names and values were removed altogether since there are no values (null) for these attributes. In the third step, a regular expression was used to remove values for the attribute “created_epoch”. This expression searches the whole data feed file for strings that start with “15” and end up with “Z”, and replace them with null characters. 65 Figure 4.2 Prune data feeds by removing unnecessary items By writing all replacements into TXT files, the pruning ended. Pruned data in TXT files were then transferred to newly generated CSV files to be imported into Adafruit IO Reader (Figure 4.3). Figure 4.3 Create CSV files The synchronization, in essence, is a process of downloading and pruning data feeds. Synchronization can be executed manually by users for unlimited times, during which any existing files are overwritten to ensure that only the most up-to-date copy of data feeds is stored. Code for a dialog box indicating that data feeds are synchronized with the latest version on the Server is available right after the loop (Figure 4.4). Figure 4.4 Code for the “Synchronization Completed” dialog box 4.1.2 Save customized settings By default, any customized settings made in the program will be lost after the program is closed and then relaunched. Therefore, an external configuration file is required to write customized settings to and retrieve these settings from. The file was named “Customized Comfort Zones.txt” and stored in the program folder. Bidirectional arrows indicates how data travels between the configuration file and main program (Figure 4.5). Figure 4.5 The interaction between configuration file and main program 66 In the main program, text boxes serve to input customized comfort zone threshold values. These values, however, need to be checked to decline invalid ranges if they exist. For both temperature and RH ranges, the minimum (low) value cannot be higher than the maximum (high) value. In addition, the program also checks for blank text boxes and reminds users to input a value. Figure 4.6 Validate temperature range and RH range After the validation of values, four public static strings were defined to fetch customized comfort zone threshold values from the text boxes and write them into the configuration file. These values were separated by line breaks rather than commas, which means there is one value in a line (Figure 4.7). Note that the string “ComfortRepository” defined the folder where the file is in. When combined with the file name, a file path was formed. Figure 4.7 Write customized comfort zone settings to the configuration file Reading customized settings from the file to the Adafruit IO Reader was done by using “Skip Method” (Figure 4.8). “Skip(0)” means to not to skip any line and retrieve the first data in the file, which is the minimum (low) value of temperature comfort zone. Accordingly, “Skip(1)” means to skip one line and obtain the second data. The process was repeated until all four comfort zone threshold values were imported to the program. Figure 4.8 Read customized comfort zone settings from the configuration file 67 By sending values between the main program and the configuration file, customized settings are maintained no matter how many times the program is closed and relaunched. Since the interaction between the program and the file is bidirectional, the values can be changed in either place. 4.2 Data display and visualization This section focuses on features associated with displaying sensor data feeds and having these feeds and sensor models visualized in Revit. Additional information such as on-site photographs are also available as supplements. 4.2.1 Data tables and plots The process of loading data feed tables and line plots belongs to a single function “LoadDgv()”. There are two tables to be loaded: temperature and RH. These tables are input to temperature data grid view (DGV) and RH DGV respectively. A temperature data feed table is introduced as the example. Before the table is loaded, some work has to be done to make preparation for importing tables: reset filters, dispose and refresh data table, and load data table (Figure 4.9). In Part 1, all filters that pick out only a portion of data from the table were reset to ensure that a full data feed table can be loaded into the temperature DGV. A temperature line plot also became viewable with the table loaded. Part 2 defined the local folder from where the CSV file were read to generate the data table and line plot and disposed existing contents from the DGV. This is important because if an updated new table are loaded without disposal, they will be appended to the existing table, which should be overwritten. The DGV were then refreshed and ready to make space for a new data table. The table is read-only and does not allow any editing. Part 3 is the beginning of loading the data table by retrieving a corresponding CSV file from the designated file path. Figure 4.9 Prepare for loading data table The file path, defined by a string called “SensorInfoPath”, is composed of three parts: the string “RealTimeRepository” (folder name), text in the sensor combo box, and a portion of file name with the file extension (Figure 4.10). Figure 4.10 Define the file path – 1/2 68 By combining these parts, a temperature data table can be generated based on the loaded CSV file. Text in the combo box is changeable, in order to load different temperature data tables (Figure 4.11). Figure 4.11 Define the file path – 2/2 With the file path retrieved, the temperature data table is ready to be written into the DGV. In Part 1, the program firstly imported the table header and created all columns by a for loop. Then rows were added to import data records. Part 2 set the width of columns to fit the contents in cells, and disabled manual sorting of data so that data records are sorted by a chronological order, with the most recent data on the top (Figure 4.12). Figure 4.12 Generate data table The loaded temperature data table was used to generate the line plot. Data values and timestamps were placed on Y axis and X axis respectively. The minimum temperature value was set to 40 ℉ to reduce blank space in the plot. X axis was reversed so that the most recent data can be consistently on the right side (Figure 4.13). Figure 4.13 Generate line plot 69 Note that the code introduced in this section is for loading the temperature data table and generating the temperature line plot. The code dealing with RH is not introduced since it follows the same structure and logic as temperature code from Figure 4.5 to Figure 4.9, with only some minor adjustments in terms of variable names. 4.2.2 Full and partial tables / plots The feature allows users to set a date range to filter data and focus on only a particular portion. It was set in a separate window named “Date Filter”. Users can fill in either start date or end date, or both of them, by choosing year (2018-2019), month (01-12), and day (01-31) from combo boxes. Before filtering data, the validity of inputs must be checked to guarantee the correctness of outputs. For example, when none of the checkboxes is checked, the program reminds users to check at least one of them to set the date range. Similar to checking customized comfort zone threshold values, the date range set also need to be checked. The program does not allow a “start year” later than an “end year,” since it is not a valid range (Figure 4.14). The same process applies to month and day as well, and the code has been omitted for conciseness. Figure 4.14 Validate date range With the validity of date range examined, the program returns one of the three strings – “DateRangeSE” “DateRangeS” and “DateRangeE”, depending on the boxes checked in Date Filter window (Figure 4.15). Another string named “DateRange” was defined to receive the value from one of the aforementioned strings. “DateRange” serves as the filter to pick out all rows with timestamps that belong to the defined date range (Figure 4.16). Figure 4.15 Different row filters to be selected 70 Figure 4.16 Apply the row filter Line plots also reflect the change brought by the date filter, displaying only the data values within the date range. Code for generating partial line plots and full line plots shares the identical structure (See Figure 4.13). 4.2.3 All values and faulty values Toggling between all values and only faulty values was achieved with a checkbox and by using a straightforward “if-else” structure (Figure 4.17). If the box is checked, the program will pick out only faulty values defined by the currently used comfort zone and highlight them with proper color schemes (See Figure 3.20 in Section 3.2.2). When there is only faulty values in the data table, line plots become temporarily unavailable. If no faulty value is detected, the program returns a blank data table with only headers. When users uncheck the box, rows with normal values are no longer filtered, and line plots become visible once again. Note that switching from one sensor to another will reset any filters in the program, including the date filter and faulty value filter. Figure 4.17 Switch between all values and only faulty values 4.2.4 Navigation to sensor models Five macros named after the locations where the corresponding IoT sensors were installed are made available for interacting with 3D sensor models in Revit (Figure 4.18 Left). The execution of every single macro is composed of four steps: declare variables, reset previous color schemes and set new ones, zoom out the view, and launch the main program (Figure 4.18 Right). In this section, the first macro “A_Watt_Hall_Building_Science_Corner” is used as the example for code analysis. The rest of the macros share the same structure, with slight differences in terms of variable values. 71 Figure 4.18 Macros that navigate users to sensor models The first step is the declaration of variables (Figure 4.19). “Form1” was defined as the “Mainform” for opening main program and loading data tables and plots in the fourth step. Necessary public static strings were given values to load relevant CSV files and on-site photographs. The most important work done in this step is to define the currently active Revit project and view with commands in UiApplication Class and UiView Class respectively. These Revit API commands are useful in terms of applying sensor model color schemes and adjusting views in the second and third step. Figure 4.19 The first step – Declare variables The second step does two things. One aims to reset sensor model color schemes (Figure 4.20 and Figure 4.21). This was achieved with a function named “G_Reset”, in which a “for” loop that was executed five times. Each time the borderline color of a sensor model is reset to default value – black (Figure 4.20). Figure 4.20 The second step (1 of 2) – Reset color schemes 72 Another one applies a new color scheme to the sensor model after resetting color schemes with “G_Reset” (Figure 4.21). Red color was chosen to highlight the sensor model. At the end of this step, the view was zoomed in to fit the size of sensor model with “ShowElements” method. However, there is a problem with this method: the view is zoomed in too close to the sensor model, which leaves out the building elements surrounding the model and makes users unable to tell where the sensor was installed in the building (Figure 4.22 Left). To resolve this, the third step was introduced to zoom out the view for an appropriate view scale that contains enough information to locate the sensor model (Figure 4.22 Right). Figure 4.21 The second step (2 of 2) – Apply a new color scheme Figure 4.22 Different view scales with the sensor model at the center The third step is the highlight of the macro. Here, the view was zoomed out by using “GetWindowRectangle” and “GetZoomCorners” Method (The Building Coder, 2012). With these methods, the rectangle boundary of current 3D view is defined, together with two adjacent corner points along the length of this rectangle boundary (Figure 4.24 Upper). The position of these two points are named “p” and “q” respectively. The distance between point “p” and “q” equals to “v” (which is the length of the view boundary), and the position of “center” (which is middle point of “p” and “q”) was calculated with the following formula: 𝑐𝑒 𝑛 𝑡𝑒𝑟 = 𝑝 + 0 . 5 × 𝑣 = 𝑝 + 0 . 5 × ( 𝑞 − 𝑝 ) = 𝑝 + 𝑞 2 To zoom out the view, it is necessary to multiply the rectangle boundary length of original view (“v”) by a coefficient larger than 1. The modified “v” value serves as the amount of offset from the “center” to both left and right side to define the rectangle boundary length of the zoomed out new 3D view. Depending on the location of sensor models, the zoom out coefficients range from 5 to 20 to ensure that sufficient building elements besides the sensor models are shown for users to check where sensors are. 73 Figure 4.23 The third step – zoom out the view Figure 4.24 Zoom out by getting “zoom corners” (Upper – the original view; Lower – the zoomed out view) 74 The fourth step is the initialization of the main program (Figure 4.25). The default ASHRAE 55-2017 comfort zone was written to the program. Then, the code for opening the main program interface and loading data tables / plots associated with the sensor model was executed using strings and variables defined in the first step (See Figure 4.19). Figure 4.25 The fourth step – initialize main program By executing codes for all these four steps, the macro resulted in a 3D view with sensor model, accompanied with the Adafruit IO Reader interface providing real-time sensor data values from the server. 4.2.5 On-site photographs Similar to loading CSV files, on-site sensor photographs were loaded into Adafruit IO Reader by combining three strings: file path, file name and file extension (Figure 4.26). There are two types of photo taken for every sensor. One is “Room Photo” that shows the environment and facilities in the selected location, while the other is “Sensor Photo” that gives a close-up view of the sensor (Figure 4.27). These two photos are always loaded simultaneously into the main interface. Figure 4.26 Load on-site photographs Figure 4.27 An example of “Room Photo” (left) and “Sensor Photo” (right) Photos taken at Watt Hall Upper Rosendin 75 4.3 Comfort zones This section explains features related to setting comfort zones, applying color schemes to data values based on comfort zones for highlighting faulty values, and working with advanced comfort zone options. 4.3.1 Comfort zone presets Comfort zones in Adafruit IO Reader are divided into two categories: preset comfort zones and customized comfort zones. Since setting customized comfort zones requires saving and loading data from external files, this feature was put into “files and user settings” categorization and introduced in Section 4.1. To avoid ambiguity of definition, the “comfort zones” explained in this section refer to “preset” ones. Since comfort zone threshold values can be decimals (for example, “73.4” in ISO 7730 standard), it is not practical to use the way of choosing start date and end date with combo boxes (See Figure 4.15). Instead, text boxes were used for manually inputting values rounded to one decimal place. However, these text boxes are only enabled when setting customized comfort zones (See Section 4.1.2). When choosing preset comfort zones, threshold values in text boxes are protected by disabling text editing. This was achieved by a function named “DisableBoxes”, before giving values to variables defining comfort zones (Figure 4.28). Figure 4.28 Text boxes and comfort zone presets Strings (“LT” “HT” “LH” “HH”) were defined to take values from text boxes. If the customized comfort zone was not selected, the program would apply the current comfort zone to data tables without writing these values to the configuration file. Otherwise the program would execute the last two code lines in Figure 4.7 and do the writing. Figure 4.29 Apply a comfort zone to data tables 4.3.2 Color schemes The code for applying color schemes is included in a function named “ColorScheme”. This function is executed at multiple places in the program by simply referring to its name, rather than copying and pasting full code in this function. The code in “ColorScheme” function was separated into two parts that share the identical structure but with different variable names. Part 1 works for temperature data table, while Part 2 for RH table (Figure 4.30). Threshold values from comfort zone window were retrieved and converted from strings to decimals for comparison. The process was done by comparing data values row by row against threshold values (both maximum and minimum). If the value that is currently being compared is higher than the maximum threshold value, the cell that 76 holds this value will be colored orange. If the value is lower than the minimum threshold value, then cyan (light blue) will be used. The comparison was repeated for 1,000 times to scan one data table and apply color schemes. Figure 4.30 Apply color schemes to data tables 4.4 Summary The features of Adafruit IO Reader were categorized according to their functions. Features related to files and user settings dealt with retrieving, pruning, and synchronizing sensor data feeds, together with saving customized comfort zone settings to an external file. Features associated with data display and visualization solved problems including generating data tables and line plots, and manipulation of data feeds such as filtering data to check out values at fault or within a specified date range. The key feature is the navigation to sensor models in Revit, which plays the role of connecting BIM and real- time sensor data. In addition to data feeds and virtual models, on-site photographs helped with supplementing more information to achieve better visualization. Features regarding comfort zones focused on both preset and customized comfort zones. With comfort zones defined, color schemes could be used on data tables to tell faulty values from normal ones. Different comfort zones are also possible to be applied to sensors in different locations with diverse thermal comfort requirements. The small units achieving specific features were assembled to achieve the completed form of Adafruit IO Reader. The full code is available in Appendix A. The results based on the C# code were tested in a case study of Watt Hall. This is described in Chapter 5. 77 5. CASE STUDY OF WATT HALL This chapter starts with an introduction of hardware system used, then explains the interface of the Adafruit IO Reader (abbreviated “Reader”) and the results produced by the C# code developed in Chapter 4. Using a case study of Watt Hall, this chapter serves to validate the tool’s usability and accuracy by examining if the main features of the program work properly and give expected outcomes. 5.1 Hardware The hardware used in the case study were developed by the TrojanSense team. They consist of ASAIR AM2302 IoT sensors powered by AA batteries and connected to Arduino ESP32 board with a Wi-Fi and Bluetooth microcontroller (Figure 5.1). Figure 5.1 An IoT sensor Sensors were attached to the outside of the 3D-printed shells. Batteries supplied power to ESP32 boards and microcontrollers. These parts were put into the shells and installed under a studio desk in Watt Hall, in the Building Science corner (Figure 5.2.1), on a fire alerting device in Upper Rosendin (Figure 5.2.2), on the staircase connecting Lower and Upper Rosendin (Figure 5.2.3), under the desk in Watt Hall 212 (Figure 5.2.4), and on the wall in Watt Hall B1 (Figure 5.2.5). Figure 5.2 Sensor locations in Watt Hall 78 5.2 Software This section describes the model used for the case study, how to run Adafruit IO Reader in Revit, and the functions of the main parts of the Reader. 5.2.1 3D model and 3D views The Revit model was provided by USC FMS. 3D views of 3 rd floor, 2 nd floor and basement were used (Figure 5.3.1 – 5.3.3). The opacity of some building elements and the viewing angles are adjusted to ensure that sensor models are visible. The model of IoT sensors were created as a Revit family to be added to the model based on “Sensor Photos” and measurement of sensor dimensions (Figure 5.3.4). Figure 5.3 Watt Hall 3D models (1-3) and IoT sensor model (4) 5.2.2 Preparation for running the program To work with Adafruit IO Reader, the first step is to get program files and copy them to the specified folder. The project file “Adafruit IO Reader.zip” can be downloaded from GitHub (https://github.com) by searching “Adafruit IO Reader Ver. 0.5”. This is a zipped file that contains the following (Figure 5.4): Figure 5.4 Program files 1) Folders a) The module and all macros (NewReadAdafruit); b) The folder for storing on-site photographs (Pictures); c) The folder for storing real-time data (Real-Time); 79 2) Files a) The configuration file where threshold values of the customized comfort zone are stored (Customized Comfort Zone.txt); b) The Revit Family file of IoT sensor model (IoT Sensor.rfa); c) The Revit Family file of Watt Hall model (Watt Hall.rvt). The folder holding module and macros (NewReadAdafruit) need to be copied to the “AppHookup” folder intended for external Revit plugins (Figure 5.5). The version of Revit used may vary on different computers. Figure 5.5 The path of “AppHookup” folder With the module and macro file in the right place, the Revit Model is ready to be opened. Select “Watt Hall.rvt” to load the model. When the model is loaded, a dialog box will appear, notifying users of the potential security issues with macros (Figure 5.6). Choose “Enable macros for this document” or they will not be running. Figure 5.6 Macro security alert The program is started with Macro Manager in Revit, which can be found near the right end in “Manage” ribbon. First, select “Application” tab control and any macro from A to E. Then, click on “Run” button to run the selected macro (Figure 5.7). Here as an example, the macro “A_Watt_Hall_Building_Science_Corner” was chosen. Figure 5.7 Run a macro in Revit 80 Running the macro brings up the highlighted sensor model in a 3D view and the main interface of Adafruit IO Reader with real-time sensor data retrieved from the server (Figure 5.8). There are a wide range of features available on the interface, and they will be introduced in following sections with step-by-step tutorials. Figure 5.8 The result of running macro “A_Watt_Hall_Building_Science_Corner” 5.2.3 Main interface of Adafruit IO Reader Most of the space on the main interface window is used for data table view panels and line plot view panels visualizing sensor data. The interface is currently comprised of 12 functional modules (Figure 5.9). Figure 5.9 The main interface 81 1) Menu bar items: Menu commands related to synchronizing sensor data with Adafruit IO server, clearing data display on the interface, editing thermal comfort zone and file path for storing sensor data files; 2) Sensor list: A combo box containing five IoT sensors installed in Watt Hall (Figure 5.10). By selecting any sensor from the list, the program automatically load temperature and RH data files and display them in view panels. At the same time, the program takes users to the selected sensor model and zoom in to the view of that sensor; Figure 5.10 Watt Hall sensor list 3) Revit element ID: Every sensor model in Revit is assigned a six-digit Revit element ID. This is used in source code to create the many-to-one relationship between data feeds and a sensor model; 4) Update data: A shortcut button for synchronizing sensor data with data feed stored on Adafruit IO server; 5) Reset filter: A temporary button for developer’s testing and debugging only. This will be removed in future versions; 6) Temperature tab control: Switch between temperature data table and line plot; 7) Temperature view panel: Display temperature data table (by default) and line plot; 8) RH tab control: Switch between RH data table and line plot. 9) RH view panel: Display RH data table (by default) and line plot; 10) Room photo: Display the photo of the room where the sensor is installed; 11) Sensor photo: Display the close-up view of the sensor; 12) Display settings: The settings related to manipulating data tables such as filter values according to start and/or date, or the status of values (faulty or normal). 5.3 Case study part #1 – Files and user settings The first part of program feature test focuses on features related data files including retrieving from the server, pruning original data sets, and synchronizing data with the server. The connection between the main program and external configuration file is also examined. All features from Section 5.3 to 5.5 are accompanied with figures with results (how features look on the main interface) and step-by-step instruction for making use of these features. 5.3.1 Data retrieval, pruning and synchronization Sensor data is not automatically synchronized with the latest version on the server. It must be done manually either from menu bar or the shortcut button on the interface. The average time spent on data syncing in the tool is approximately 8 seconds per time, so it is not ideal to make tool users wait by synchronizing data every time the program is launched. To synchronize data, simple click on “Sync All Data” command in “File” menu bar (Figure 5.11 Lower). And then a dialog box will pop up reminding users that the synchronization has been successfully completed (Figure 5.12). By synchronizing, sensor data in tables is updated. The change can be read from the fifth column (“created_at”) that sensors read every 15 minutes (Figure 5.11 Upper). Temperature and RH data are not combined to create a single table but displayed in two separate tables, due to the slight difference of timestamps. For example, the latest record of temperature data was created at 08:04:37 on Dec. 6, 2018, but the corresponding latest RH data was created one second later. Such differences happen from time to time, making the combination of data impractical. 82 Figure 5.11 Synchronizing sensor data (Upper – Results; Lower – Steps and clicks) Figure 5.12 The “Synchronization Completed!” dialog box In the background (what the user does not see), sensor data files downloaded from Adafruit IO Server were saved as TXT files and pruned to eliminate unnecessary information. TXT files after pruning were saved again as CSV files, with an additional column named “status” that indicates if the value is treated as normal or faulty (Figure 5.13). TXT and CSV files are stored in the same folder, but only CSV files will be loaded to the tool (Figure 5.14). Figure 5.13 Temperature data file for Watt Hall Building Science Corner 83 Figure 5.14 Pruned sensor data files in TXT and CSV format 5.3.2 Save customized settings The bidirectional interaction between the configuration file and Adafruit IO Reader can be used for customized comfort zones. The program reads the customized setting from the file and displays the setting in the Comfort Zone window, where users are free to adjust the threshold values for new settings. To make use of customized settings, click on “Comfort Zone…” command in “Edit” menu bar. Then, select “Customize…” from the “Preset” combo box, and disabled text boxes are enabled. At the same time, current threshold values of the customized comfort zone is read from the configuration file. In the next step, users are free to set their own new threshold values for the customized comfort zone. When “OK” button is clicked, the program writes the most recent setting back to the configuration file, and replaces the older setting (Figure 5.15). Taking advantage of external files saves customized settings and protect them from being lost when the main program is restarted. Figure 5.15 Synchronizing sensor data 84 5.4 Case study part #2 – Data display and visualization The second part tests features related to displaying, visualizing, and manipulating data. It also shows how data sets interact with 3D models in Revit. 5.4.1 Data tables and plots To load data tables and line plots, simply choose any sensor from the “Sensor” combo box on the main interface (Figure 5.16 Lower). Data tables and line plots take most of the space on the interface, and they serve as the basis of other program features. Data tables in Adafruit IO Reader share the same layout as those CSV files that can be opened with Excel (Figure 5.16 Upper left). The most recent 1,000 data values are available in both data tables. This is the amount of data for approximately 15 days. Past values older than 15 days will be erased and replaced by new values to dispose space for storage. Line plots, as a more visualized presentation, are generated based on data values in the second column (Figure 5.16 Upper right). Users can switch between tables and graphs with tab controls at the upper left corner of view panels (See Figure 5.9). Both data tables and line plots can be manipulated by different display settings to allow users to focus on a specified portion of data. These settings will be introduced in following sections. Figure 5.16 Data tables and line plots (Upper left – Data tables; Upper right – Line plots; Lower – Steps and clicks) 5.4.2 Full and partial tables / plots Manipulation of data tables is completed by “Display Settings” on lower right corner of the main interface (Figure 5.17). One of the settings is named “Date Filter.” Sometimes, there may be a time range of interest where data values need special attention. Adafruit IO Reader provides a date filter that allows users to focus on only an excerpt from the full table. Either start date or end date, or both dates can be used for setting a range (Figure 5.18). 85 Figure 5.17 Display settings Figure 5.18 Date Filter To apply the date filter, select “Setup…” in “Display Settings”. Enable at least one from “Start Date” and “End Date”, and then set the date range. Click on “OK”, and the data table will be updated to display only data values within the range (Figure 5.15 Lower). The filter works on not only to data tables, but also line plots. With such a filter, the line plot view looks like “zoomed in”, enabling the observation of data fluctuation in a more legible manner with a smaller scale (Figure 5.19 Upper). Figure 5.19 Full and partial tables / plots (Upper left – Full; Upper right – Partial; Lower – Steps and clicks) 86 5.4.3 All values and faulty values Another “Display Setting” is named “Faulty Values Only”. To enable this, users just need to check the “Faulty Values Only” box in “Display Settings” (Figure 5.20 Lower). This feature was designed for users to quickly locate faulty values defined by the current comfort zone at work. All values within the comfort zone are filtered out by this setting. A blank data table indicates that all values recorded are considered normal (Figure 5.20 Upper right). When “Faulty Values Only” box is checked, line plots will be temporarily unavailable since the appearance of faulty values is, in most cases, sporadic rather than continuous. Such data values with little or completely no chronological continuity are not sufficient for generating line plots. Figure 5.20 All values and faulty values (Upper left – All values; Upper right – faulty values only; Lower – Steps and clicks) 5.4.4 Navigation to sensor models The feature is realized by selecting one of the macros from “A” to “E” in “Application” tab control (Figure 5.21). When “Run” button is clicked, Revit will begin to execute codes in the selected macro and switch current view to the sensor model associated with this macro (Figure 5.22 to Figure 5.26). Meanwhile, the main interface will show up, providing a wide range of information including sensor data value tables, line plots, currently working comfort zone, etc. Users can also take advantage of features introduced in previous sections, such as “Display Settings,” to manipulate the display of data. Figure 5.21 Select a macro and go to the view of the corresponding sensor model 87 Figure 5.22 3D model and information for sensor in Watt Hall Building Science Corner Figure 5.23 3D model and information for sensor in Watt Hall Upper Rosendin 88 Figure 5.24 3D model and information for sensor in Watt Hall Lower Rosendin Figure 5.25 3D model and information for sensor in Watt Hall 212 89 Figure 5.26 3D model and information for sensor in Watt Hall B1 5.4.5 On-site photographs For every sensor in the list, “Room Photo” and “Sensor Photo” (See Section 4.3.1 for definitions) are displayed next to data tables. These photographs were stored in a separate folder, and they can be updated by replacing files at any time. Photographs are tied up with data tables, so every time a sensor is chosen from the combo box and corresponding data tables loaded, these photographs will show next to tables (Figure 5.27). Figure 5.27 On-site photographs (Upper – Photographs; Lower – Steps and clicks) 90 5.5 Case study part #3 – Comfort zones The third part validates the proper function of features related to preset comfort zones, color schemes, and advanced comfort zone strategies. 5.5.1 Comfort zone presets The comfort zone options define an acceptable range for data values that can be considered as “normal.”.To set a comfort zone, click on “Comfort Zone…” command in “Edit” menu bar. In the dialog box, pick any preset comfort zone except “Customize…”. Two major standards of thermal comfort zone, ASHRAE 55-2017 and ISO 7730 (including summer and winter), are provided in the tool for needs in different indoor environment. Note that text boxes for threshold values are not enabled for editing when choosing presets. Click on “OK” to apply the selected comfort zone to data tables (Figure 5.28). Figure 5.28 Set a preset comfort zone Thredshold values for ASHRAE and ISO comfort zones are read from psychometric charts and saved as presets (Table 5.1). There are also some test options for testing and debugging and will be removed in later versions. Table 5.1 Comfort zone presets Preset Low Temp. ( ℉) High Temp. ( ℉) Low RH (%) High RH (%) ASHRAE 55-2017 66 84 20 80 ISO 7730 – Summer 73.4 78.8 30 70 ISO 7730 – Winter 68 75.2 30 70 Test Option 1 68 72 20 80 Test Option 2 72 78 20 80 Cu st o m ize … Set by users 5.5.2 Color schemes The feature does not require any click of mouse. It is associated with the definition of comfort zones. With a comfort zone set, data values can be categorized as “too high” “normal” or “too low.” Color schemes are assigned to these three kinds of values. Values higher than the maximum threshold value are marked with orange, while those lower than the minimum are colored with light blue. By applying color schemes, users can easily distinguish “faulty” values and when these values occurred, which can help with figuring out the reason for faults. Switching from one comfort zone to another one will have effect on the categorization of values. This effect indicates that the definition of “faults” in the tool can be quite flexible. Running the program with ASHRAE and ISO presets led to different output applied to exactly same set of data. Some “normal” values in ASHRAE standard become “faulty” when evaluated by ISO standard (Figure 5.29). 91 Figure 5.29 Applying different comfort zones to data tables 5.6 Summary The case study of Watt Hall proved that main features of Adafruit IO Reader achieved their functionality. The connection of cloud-based platform, hardware, and software was accomplished through the process of data retrieval, pruning, and synchronization. Data tables provided users with information on historical changes of sensor data values. In addition to data, various strategies of visualization were employed, such as line plots, on-site photographs, 3D building models and sensor models, to achieve the design goal of integrating real-time data into BIM. Comfort zones in Adafruit IO Reader can be defined both by presets and customization, with the configuration file saving user settings. Further discussion about some limitations of the Adafruit IO Reader and possible future work will be covered in Chapter 6. 92 6. DISCUSSION AND FUTURE WORK This chapter discusses how the current workflow performed during the development of Adafruit IO Reader, together with some limitations of the workflow and the software. The chapter also proposes measures of improvement to deal with existing limitations and shows the future potential of Adafruit IO Reader as a prototype to be further developed into a more advanced product assisting facility operation and management. 6.1 Discussion of results This section summarizes the performance of tool features and the current workflow. Limitations of the development methodology and the software are also examined to guide in improvements for future versions. 6.1.1 Examination of tool features Adafruit IO Reader, as a Revit plugin, provides users with interfaces that integrate real-time IoT sensor data feeds stored on Adafruit IO server into BIM models. By putting together information from different sources, the tool works as a “bridge” between sensors and data feeds on the cloud, navigating users to sensor models in Revit while loading data feeds to the main interface from the server (Figure 6.1, Figure 6.2). Figure 6.1 The “bridge” – Adafruit IO Reader put together information from multiple places 93 Figure 6.2 The integration of sensor data and BIM through Adafruit IO Reader Adafruit IO Reader is composed of nine main features separated into three categories. These features are examined with the case study of Watt Hall, and their performances are recorded as follows (Table 6.1). Most of the features performed satisfactorily by always producing desired outputs, except for some minor issues with the navigation to sensor models. Table 6.1 The summary of Adafruit IO Reader features (Features in bold are considered key features) CATEGORY FEATURE DESCRIPTION PERFORMANCE File and user settings Data retrieval, pruning and synchronization Download sensor data feeds from Adafruit IO server, eliminate redundancy in them, and update them to get the most recent feeds 5* Customized settings Set a comfort zone where the low and high threshold values of temperature and RH are defined by users 5 Data display and visualization Data tables and plots Provide sensor data information through both data tables and line plots. Temperature and RH data are displayed separately 5 Full mode and partial mode Enable users to filter data by setting a date range to focus on a specified portion of data 5 All values and faulty values Enable users to switch between the full data tables and data tables with only faulty values defined by comfort zones 5 Navigation to sensor models Zoom in to 3D views in Revit to indicate the location of IoT sensors in Watt Hall 4** On-site photographs Displays “Room Photos” indicating the space where sensors are installed, and “Sensor Photos” indicating where sensors exactly are in the space 5 Comfort zones Comfort zone presets Provide a list from which a preset comfort zone can be applied to data tables as gauges of sensor data values (normal or faulty) 5 Color schemes Highlight faulty values in data tables with different colors (orange – too high, light blue – too low) 5 ** The performance results are measured by scores from 1 (Poor, never successfully run) to 5 (Excellent, always successfully run) ** Sometimes Revit does not zoom in to 3D views but to 2D floor plans instead, so this feature still needs improvement 94 6.1.2 Evaluation of current workflow During the development of Adafruit IO Reader, the workflow follows the linear “waterfall development methodology” in software development. The process of this method works well with small-scale projects. Once the required features for such a project are defined, the designing and coding work can be divided into multiple small parts, each of which realizes one single feature of the program. However, the development process is not only about lines of writing C# code for generating software interfaces in Revit Macro IDE. It also requires the interaction with contents stored on the cloud-based platform and local external files to fill necessary information into software interfaces. Therefore, a “connection” were built between the software (Adafruit IO Reader) and the platform (Adafruit IO server) to achieve the requests and retrievals of information. There is also another “connection” between the platform and IoT sensors, but this part is out of the research scope and done by a peer researcher. The implementation of Watt Hall case study proved the validity of the development workflow based on the platform-software “connection.” With this workflow, data feeds on the server can be successfully loaded to Adafruit IO Reader interfaces, and they are always ready to be manually synchronized with the most up-to-date version on the server for unlimited times. 6.1.3 Limitations Despite that the nine main features worked properly, there is still plenty of room for improvement for the Adafruit IO Reader. The biggest limitation lies in the installation of IoT sensors and the influence on availability of data feeds. Amongst the five sensors in Watt Hall, only one at Building Science Corner was plugged in, while another four are powered by AA batteries. A possible explanation for doing so is that the wiring between sensors and sockets will reveal the locations of sensors and expose them to the risk of being taken away. Taking advantage of solar energy is ideal in terms of sustainability, but it is impractical in indoor settings without daylighting (Dong, 2019). Given that AA batteries were used for powering most of the sensors in Watt Hall, the replacement of batteries becomes a serious issue. If the replacement stops, the sensors will eventually out of power and stop collecting data. In addition, because the installation of IoT sensors, the storage and management of data feeds are originally intended for TrojanSense project, the sensors are likely to be collected back to the project leader without any prior notification. In short, the development of Adafruit IO Reader is highly subject to the schedule of TrojanSense group, since it accesses data from the TrojanSense project. Another problem derived from the previous one is the limitation of the data feed pruning algorithm. The current pruning algorithm is solely designed for sensor data files generated by ASAIR IoT sensors and retrieved from Adafruit IO servers (Figure 6.3 Right). In case of processing data files generated by other types of sensor, it is likely that some necessary information may be erroneously pruned, which will lead to data files with disordered formatting. Figure 6.3 Comparison of different sensor data files (Chen et al. 2014) 95 The third limitation is that the sensor management is accessible only through adding Revit Family (RFA) files of sensor model to Watt Hall model and through editing source code. These approaches are far too complicated for users new to Revit and C#, and lacks efficiency when a large amount of sensor models and corresponding information need to be added to or deleted from the model. Adafruit IO Reader currently collects a total of 10 data feeds (both temperature and RH feeds) for five sensors. Managing sensors and data feeds of this amount is still possible by manual editing of codes, but a brand-new and automated approach for sensor management should be taken into account before Adafruit IO Reader can deal with more sensors. 6.2 Future work This section introduces possible directions and measures for addressing existing limitations and expand functionalities of Adafruit IO Reader. Metrics such as speed, efficiency, flexibility, and portability are discussed. 6.2.1 Responding speed improvement A research indicated that people will get distracted from the current workflow if the responding time of software exceeds 10 seconds (Nielsen, 1993). Downloading data files from the Adafruit IO server and reading them into the tool takes time, and this time of waiting for responding becomes even longer when more sensors are added to the tool, or when the size of data files increase. Currently, the average responding time spent on synchronizing 10 data feeds is approximately 8.25 seconds. 6.2.2 Code improvement The source code of Adafruit IO Reader can be run without any compiler errors, but it still has room for improvement. For example, the code of current data file pruning algorithm features a process of “subtraction” – which means gradually eliminating unnecessary items from the original data files by replacing them with blanks, commas or line breaks to generate new data files (Figure 6.4). For every line in a single data file, 14 replacements are needed. This will reflect to a total of 140,000 replacements for 10 data files with 1000 lines in each. As mentioned in 6.2.1, executing these 140,000 replacements takes quite long (on the verge of distracting users from the workflow). Figure 6.4 Prune data feeds by removing unnecessary items A second data file pruning algorithm featuring “addition” instead of “subtraction” may help. By extracting only necessary items from the original data files, and putting them together to get new data files, there can be a potential decrease of responding time for synchronization. This decrease will contribute to more efficient workflow, and improve the user experience of Adafruit IO Reader. Code improvement helps not only with shortening the responding time, but also with reducing repetitions and improving conciseness. For example, there are a series of customized public void functions where the code are almost identical but only with discrepancies in terms of variable names. These identical and repetitive parts could be combined to run the program with less code and consequently, smaller source code files. 96 6.2.3 Flexibility and customization Currently, the Adafruit IO Reader accesses data feeds from other projects, and the developer do not have the initiative on managing all data feeds. Setting up sensors based on Adafruit IO Reader users’ own needs will let them get more control. In addition, more efficient and user-friendly interfaces can be developed for more flexible sensor model and sensor data management, which may include new features including adding new sensors, deleting idle or broken sensors, assigning different temperature and RH ranges for different sensors, etc. 6.2.4 Potential of embedding in FM platforms Adafruit IO Reader works as a Revit plugin, and all existing features except data feed synchronization were performed on local computers. These features could be integrated into presently used web- or cloud-based facility management platforms such as Autodesk 360 or EcoDomus. The synergy of features from these platforms and Adafruit IO Reader will provide FM managers with more comprehensive information about facilities and equipment in a building, supporting both quotidian monitoring work and, when necessary, corrective maintenance work (troubleshooting). 6.3 Conclusion Based on the installation of IoT sensors and setup of the account on Adafruit IO server done by TrojanSense group (led by Prof. Kyle Konis), the research served as an extension of the TrojanSense project by introducing software (Revit and Adafruit IO Reader) for downloading, analyzing, and visualizing information stored in sensor data feeds. Overall, combining their previous research with this additional work, a complete and feasible workflow featuring the “connection” between hardware (IoT sensors), cloud-based platform (Adafruit IO server), and software was achieved. With Adafruit IO Reader, sensor data feeds can be integrated into Revit models. The combination of visualized sensor data and sensor models were evaluated by a case study of Watt Hall, and the result showed that Adafruit IO Reader is able to achieve the integration by navigating users to sensor models, while providing corresponding sensor data information that is open to customized manipulation through various display settings. The findings of the research is of value for FM managers in terms of supporting with visualized user interfaces decision-making processes especially related to HVAC systems and thermal comfort. Adafruit IO Reader could be a prototype for developing more sophisticated products that help the data management in FM, or it could be integrated into currently used FM platforms to better streamline workflows with more exhaustive information during regular management work and troubleshooting work. 97 REFERENCES "About Macros." Autodesk. Accessed March 18, 2019. https://knowledge.autodesk.com/support/revit- products/learn-explore/caas/CloudHelp/cloudhelp/2018/ENU/Revit-Customize/files/GUID-EFF4E5A3-16EB- 4CB4-AD6A-5EEE823CCE76-htm.html "Adafruit IO REST API (v2.0.0)." Adafruit. Accessed March 18, 2019. https://io.adafruit.com/api/docs/ "Anoka County Case Study." Accurent. Accessed March 6, 2019. https://www.accruent.com/resources/case- studies/anoka-county-case-study "App of the Week: Autodesk BIM 360 Glue." Accessed March 18, 2019. https://www.forconstructionpros.com/construction-technology/project-management/blog/11309218/autodesk- bim-360-glue-goes-mobile-with-ipad-app "Autodesk BIM 360." Autodesk. Accessed March 6, 2019. https://www.autodesk.com/bim-360/ "Autodesk Dasher 360." Autodesk. Accessed March 18, 2019. https://dasher360.com/ "BIM 360 Design." Autodesk. Accessed March 24, 2019. https://blogs.autodesk.com/anztechteam/2018/04/16/bim- 360-design/ "Building management system." Wikipedia. Accessed March 6, 2019. https://en.wikipedia.org/wiki/Building_management_system "C# Programming Tutorial Visual Studio." Accessed March 24, 2019. https://www.youtube.com/playlist?list=PLS1QulWo1RIZrmdggzEKbhnfvCMHtT-sA "Case study – Huntsman." Accurent. Accessed March 6, 2019. https://www.accruent.com/resources/case- studies/huntsman "Comma Separated Values (CSV) Standard File Format." Accessed March 18, 2019. http://edoceo.com/utilitas/csv- file-format "Determining Thermal Comfort Using a Humidity and Temperature Sensor." AZO sensors. Accessed March 6, 2019. https://www.azosensors.com/article.aspx?ArticleID=487 "EcoDomus FM." EcoDomus. Accessed March 6, 2019. http://ecodomus.com/products/masonry-style/ "EcoDomus PM." EcoDomus. Accessed March 6, 2019. http://ecodomus.com/products/ecodomus-pm/ "Empowering Facility Professionals Worldwide." International Facility Management Association. Accessed March 6, 2019. https://www.ifma.org/ "Engineering Document Management – Meridian." Accurent. Accessed March 6, 2019. https://www.accruent.com/solutions/engineering-document-management/engineering-document-management- meridian "Facilities management development in Europe." ResearchGate. Accessed March 6, 2019. https://www.researchgate.net/publication/249920398_Facilities_management_development_in_Europe "Find and replace materials." Polynine Studio. Accessed March 18, 2019. http://www.polyninestudio.com/findreplacematerialsrevit.html "HOBO Bluetooth Temp/RH Data Logger - MX1101." ONSET. Accessed March 6, 2019. https://www.hobodataloggers.com.au/mx1101 "HOBOware." ONSET. Accessed March 18, 2019. https://images-na.ssl-images- amazon.com/images/I/81RLqSXLBHL.pdf Beck, K. (1999). Embracing change with extreme programming. Computer, (10), 70-77. "Honeywell Case Study – The Power of Integration: New Toronto Commercial Tower Pushes the Envelope in Intelligent Building Design." Honeywell. Accessed March 6, 2019. https://www.ebi.honeywell.com/PDF1/honeywell-hbs-building%20integration- 25%20york%20street%20toronto-case%20study.pdf "Infrared Sensors." Tech-FAQ. Accessed March 18, 2019. http://www.tech-faq.com/infrared-sensors.html "ISO 41011:2017." International Organization for Standardization. Accessed March 6, 2019. https://www.iso.org/standard/68167.html "Life-Saving Microscopic Sensors." Accessed March 18, 2019. https://www.trendhunter.com/trends/tiny-chip- sensors "Main Features." YouBIM. Accessed March 6, 2019. http://www.youbim.com/main_features/ "Meridian Portal: Project Collaboration in the Cloud." Accurent. Accessed March 18, 2019. https://www.accruent.com/resources/brochures/meridian-portal "National BIM Standard – United States." APEC Meeting Document Database. Accessed March 6, 2019. http://mddb.apec.org/Documents/2013/SCSC/WKSP5/13_scsc_wksp5_007.pdf "Navisworks features." Autodesk. Accessed March 6, 2019. 98 https://www.autodesk.com/products/navisworks/overview "Past Weather in Los Angeles – Graph." Accessed March 18, 2019. https://www.timeanddate.com/weather/usa/los- angeles/historic "SDLC – RAD Model." Accessed March 18, 2019. https://www.tutorialspoint.com/sdlc/sdlc_rad_model.htm "sensor analytics." IoT Agenda. Accessed March 6, 2019. https://internetofthingsagenda.techtarget.com/definition/sensor-analytics "SensorMap Delivers Real-Time Data on the Go." Microsoft Research Blog. Accessed March 18, 2019. https://www.microsoft.com/en-us/research/blog/sensormap-delivers-real-time-data-go/ "The Building Coder – UIView and Windows Device Coordinates." Jeremy Tammik. Accessed March 18, 2019. https://thebuildingcoder.typepad.com/blog/2012/06/uiview-and-windows-device-coordinates.html "The information in BIM." NBS. Accessed March 18, 2019. https://www.thenbs.com/knowledge/the-information-in- bim "The Roles and Responsibilities of a Facilities Manager." Strategy and Management Services, Inc. Accessed March 6, 2019. https://getsamsnow.com/blog-post/roles-responsibilities-facilities-manager/ "Top 4 software development methodologies." Synopsys. Accessed March 18, 2019. https://www.synopsys.com/blogs/software-security/top-4-software-development-methodologies/ "Visualization." Oxford Dictionary. Accessed March 18, 2019. https://en.oxforddictionaries.com/definition/visualization "What is Facility Management?" International Facility Management Association. Accessed March 6, 2019. https://www.ifma.org/about/what-is-facility-management Bonvini, M., Sohn, M. D., Granderson, J., Wetter, M., & Piette, M. A. (2014). Robust on-line fault detection diagnosis for HVAC components based on nonlinear state estimation techniques. Applied Energy, 124, 156- 166. Bouchlaghem, D., Shang, H., Whyte, J., & Ganah, A. (2005). Visualisation in architecture, engineering and construction (AEC). Automation in construction, 14(3), 287-295. Card, M. (1999). Readings in information visualization: using vision to think. Morgan Kaufmann. Chen, J., Bulbul, T., Taylor, J. E., & Olgun, G. (2014). A case study of embedding real-time infrastructure sensor data to BIM. In Construction Research Congress 2014: Construction in a Global Network (pp. 269-278). Daud, N. M. N., Bakar, N. A. A. A., & Rusli, H. M. (2010, June). Implementing rapid application development (RAD) methodology in developing practical training application system. In 2010 International Symposium on Information Technology (Vol. 3, pp. 1664-1667). IEEE. Dawes, N., Kumar, K. A., Michel, S., Aberer, K., & Lehning, M. (2008, December). Sensor metadata management and its application in collaborative environmental research. In 2008 IEEE Fourth International Conference on eScience (pp. 143-150). IEEE. Dong, Z. (2019). Exploring Participatory Sensing and the Internet of Things to Develop Data-Driven Thermal Comfort Models on the USC Campus. Eastman, C., Teicholz, P., Sacks, R., & Liston, K. (2011). BIM handbook: A guide to building information modeling for owners, managers, designers, engineers and contractors. John Wiley & Sons. Hosseini, M. R., Roelvink, R., Papadonikolaki, E., Edwards, D. J., & Pärn, E. (2018). Integrating BIM into facility management: Typology matrix of information handover requirements. International Journal of Building Pathology and Adaptation, 36(1), 2-14. Huang, L. (2018). Revit Plugins for Electrical Engineering Improvements in Buildings: Lighting Power Density and Electrical Equipment Placement. Kassem, M., Kelly, G., Dawood, N., Serginson, M., & Lockley, S. (2015). BIM in facilities management applications: a case study of a large university complex. Built Environment Project and Asset Management, 5(3), 261-277. Kensek, K. (2015). BIM guidelines inform facilities management databases: a case study over time. Buildings, 5(3), 899-916. Kensek, K. M. (2014). Building information modeling. Routledge. Lechner, N., & Heating, C. (1991). Lighting: Design Methods for Architects. John Wiley& Sons. Lee, G., Cho, J., Ham, S., Lee, T., Lee, G., Yun, S. H., & Yang, H. J. (2012). A BIM-and sensor-based tower crane navigation system for blind lifts. Automation in construction, 26, 1-10. Liu, H., Huang, M., Janghorban, I., Ghorbannezhad, P., & Yoo, C. (2011, October). Faulty sensor detection, identification and reconstruction of indoor air quality measurements in a subway station. In 2011 11th International Conference on Control, Automation and Systems (pp. 323-328). IEEE. Liu, X., & Akinci, B. (2009). Requirements and evaluation of standards for integration of sensor data with building 99 information models. In Computing in Civil Engineering (2009) (pp. 95-104). Matarneh, S. T., Danso-Amoako, M., Al-Bizri, S., Gaterell, M., & Matarneh, R. (2018, July). Developing an interoperability framework for building information models and facilities management systems. In Creative Construction Conference 2018 (pp. 1018-1027). Diamond Congress Ltd. Mehranbod, N., Soroush, M., & Panjapornpon, C. (2005). A method of sensor fault detection and identification. Journal of Process Control, 15(3), 321-339. National Research Council. (1995). Expanding the vision of sensor materials. National Academies Press. Nielsen, J. (1993). Response times: the three important limits. Usability Engineering. Ozturk, Z., Arayici, Y., & Coates, S. P. (2012). Post occupancy evaluation (POE) in residential buildings utilizing BIM and sensing devices: Salford energy house example. Parsanezhad, P., & Dimyadi, J. (2013). Effective facility management and operations via a BIM-based integrated information system. Pressman, R. S. (2005). Software engineering: a practitioner's approach. Palgrave Macmillan. Qureshi, M. R. J. (2012). Agile software development methodology for medium and large projects. IET software, 6(4), 358-363. Razavi, S. N., & Haas, C. (2009). A data fusion model for location estimation in construction. ‖. In Proc, the International Symposium for Automation and Robotics in Construction (ISARC). Riaz, Z., Arslan, M., Kiani, A. K., & Azhar, S. (2014). CoSMoS: A BIM and wireless sensor based integrated solution for worker safety in confined spaces. Automation in Construction, 45, 96-106. Sallans, B., Bruckner, D., & Russ, G. (2006, August). Statistical detection of alarm conditions in building automation systems. In 2006 4th IEEE International Conference on Industrial Informatics (pp. 257-262). IEEE. Shafranovich, Y. (2005). Common format and MIME type for comma-separated values (CSV) files. Shiau, Y. C., & Chang, C. T. (2012). Establishment of fire control management system in building information modelling environment. In The 1st International Conference on Software Technology. Smith, P. (2014). BIM & the 5D project cost manager. Procedia-Social and Behavioral Sciences, 119, 475-484. Suprabhas, K., & Dib, H. N. (2016). Integration of BIM and utility sensor data for facilities management. In Computing in Civil Engineering 2017 (pp. 26-33). Teicholz, E. (2001). Facility design and management handbook. McGraw Hill Professional. Teicholz, P. (Ed.). (2013). BIM for facility managers. John Wiley & Sons. Torres Betancur, J. D., & Hunt, K. D. (2016). Innovative Uses of BIM for Facility Management. Tse, T. C. K., Wong, K. D. A., & Wong, K. W. F. (2005). The utilisation of building information models in nD modelling: a study of data interfacing and adoption barriers. Journal of information technology in construction (ITcon), 10(8), 85-110. Van Every, P. M., Rodriguez, M., Jones, C. B., Mammoli, A. A., & Martínez-Ramón, M. (2017). Advanced detection of HVAC faults using unsupervised SVM novelty detection and Gaussian process models. Energy and Buildings, 149, 216-224. Wang, F., Hu, L., Zhou, J., & Zhao, K. (2015). A survey from the perspective of evolutionary process in the internet of things. International Journal of Distributed Sensor Networks, 11(3), 462752. White, R. M. (1987). A sensor classification scheme. IEEE Transactions on ultrasonics, ferroelectrics, and frequency control, 34(2), 124-126. Xiao, F., & Fan, C. (2014). Data mining in building automation system for improving building operational performance. Energy and buildings, 75, 109-118. Yang, X., & Ergan, S. (2014). Evaluation of visualization techniques for use by facility operators during monitoring tasks. Automation in Construction, 44, 103-118. Yang, X., & Ergan, S. (2015). Design and evaluation of an integrated visualization platform to support corrective maintenance of HVAC problem–related work orders. Journal of Computing in Civil Engineering, 30(3), 04015041. Yang, X., Koehl, M., & Grussenmeyer, P. (2017). PARAMETRIC MODELLING OF AS-BUILT BEAM FRAMED STRUCTURE IN BIM ENVIRONMENT. International Archives of the Photogrammetry, Remote Sensing & Spatial Information Sciences, 42. 100 APPENDIX A A.1 Program launcher /* * Created by SharpDevelop. * User: gelin * Date: 11/8/2018 * Time: 9:06 PM * * To change this template use Tools | Options | Coding | Edit Standard Headers. */ using System; using Autodesk.Revit.UI; using Autodesk.Revit.DB; using Autodesk.Revit.UI.Selection; using System.IO; using System.Collections.Generic; using System.Linq; // File Path: C:\ProgramData\Autodesk\Revit\Macros\2018\Revit\AppHookup namespace NewReadAdafruit { [Autodesk.Revit.Attributes.Transaction(Autodesk.Revit.Attributes.TransactionMode.Manual)] [Autodesk.Revit.DB.Macros.AddInId("4E5A91BC-719B-4083-93D3-BF1801EAD552")] public partial class ThisApplication { private void Module_Startup(object sender, EventArgs e) { } private void Module_Shutdown(object sender, EventArgs e) { } #region Revit Macros generated code private void InternalStartup() { this.Startup += new System.EventHandler(Module_Startup); this.Shutdown += new System.EventHandler(Module_Shutdown); } #endregion #region Main Program public void F_Main_Program() { using(var form = new Form1()) { // Set comfort zone to ASHRAE 55-2017 Form3.LT = "68"; Form3.HT = "78"; Form3.LH = "20"; Form3.HH = "80"; // Show Form1 from Revit Macro form.ShowDialog(); } } #endregion #region Reset color schemes public void G_Reset() { Document doc = this.ActiveUIDocument.Document; UIDocument uidoc = this.ActiveUIDocument; // Highlight the sensor by element ID or by picking from the 3D view. ElementId ResetId = new ElementId(1304799); for (int ColorReset = 0; ColorReset <= 4; ColorReset++) 101 { if (ColorReset == 0) {ResetId = new ElementId(1304799);} if (ColorReset == 1) {ResetId = new ElementId(1304568);} if (ColorReset == 2) {ResetId = new ElementId(1305148);} if (ColorReset == 3) {ResetId = new ElementId(1304930);} if (ColorReset == 4) {ResetId = new ElementId(1305363);} OverrideGraphicSettings ResetOgs = new OverrideGraphicSettings(); ResetOgs.SetProjectionLineColor(new Autodesk.Revit.DB.Color(0,0,0)); using (Transaction t = new Transaction(doc,"Set Element Override")) { t.Start(); // Apply color scheme to the selected element. doc.ActiveView.SetElementOverrides(ResetId, ResetOgs); // Zoom to fit. //uidoc.ShowElements(id); t.Commit(); } } } #endregion #region Sensor 1: Watt Hall Building Science Corner public void A_Watt_Hall_Building_Science_Corner() { #region Declare variables Form1 Mainform = new Form1(); Form1.RealTimeRepository = @"E:\USC\2018 Fall\ARCH692a\Tool Development\Object\Real-time\"; Form1.PicRepository = @"E:\USC\2018 Fall\ARCH692a\Tool Development\Object\Pictures\"; Mainform.SelectSensor.Text = "Watt Hall Building Science Corner"; Document doc = this.ActiveUIDocument.Document; UIDocument uidoc = this.ActiveUIDocument; View view = doc.ActiveView; UIView uiview = null; IList<UIView> uiviews = uidoc.GetOpenUIViews(); #endregion #region Reset color schemes and set new ones G_Reset(); ElementId ColorSchemeId = new ElementId(1304799); OverrideGraphicSettings NewOgs = new OverrideGraphicSettings(); NewOgs.SetProjectionLineColor(new Autodesk.Revit.DB.Color(255,0,0)); using (Transaction t = new Transaction(doc,"Set Element Override")) { t.Start(); doc.ActiveView.SetElementOverrides(ColorSchemeId, NewOgs); uidoc.ShowElements(ColorSchemeId); t.Commit(); } #endregion #region Zoom out foreach(UIView uv in uiviews) { if(uv.ViewId.Equals(view.Id)) { uiview = uv; break; } } Rectangle rect = uiview.GetWindowRectangle(); IList<XYZ> corners = uiview.GetZoomCorners(); XYZ p = corners[0]; XYZ q = corners[1]; XYZ v = q - p; XYZ center = p + 0.5 * v; v *= 10; // Zoom out if bigger than 1; Zoom in if smaller than 1 102 p = center - v; q = center + v; uiview.ZoomAndCenterRectangle(p,q); #endregion #region Initialize main program // Set comfort zone to ASHRAE 55-2017 Form3.LT = "68"; Form3.HT = "78"; Form3.LH = "20"; Form3.HH = "80"; Mainform.ShowDialog(); Mainform.LoadDgv(); #endregion } #endregion #region Sensor 2: Watt Hall Upper Rosendin public void B_Watt_Hall_Upper_Rosendin() { #region Declare variables Form1 Mainform = new Form1(); Form1.RealTimeRepository = @"E:\USC\2018 Fall\ARCH692a\Tool Development\Object\Real-time\"; Form1.PicRepository = @"E:\USC\2018 Fall\ARCH692a\Tool Development\Object\Pictures\"; Mainform.SelectSensor.Text = "Watt Hall Upper Rosendin"; Document doc = this.ActiveUIDocument.Document; UIDocument uidoc = this.ActiveUIDocument; View view = doc.ActiveView; UIView uiview = null; IList<UIView> uiviews = uidoc.GetOpenUIViews(); #endregion #region Reset color schemes and set new ones G_Reset(); ElementId ColorSchemeId = new ElementId(1304568); OverrideGraphicSettings NewOgs = new OverrideGraphicSettings(); NewOgs.SetProjectionLineColor(new Autodesk.Revit.DB.Color(255,0,0)); using (Transaction t = new Transaction(doc,"Set Element Override")) { t.Start(); doc.ActiveView.SetElementOverrides(ColorSchemeId, NewOgs); uidoc.ShowElements(ColorSchemeId); t.Commit(); } #endregion #region Zoom out foreach(UIView uv in uiviews) { if(uv.ViewId.Equals(view.Id)) { uiview = uv; break; } } Rectangle rect = uiview.GetWindowRectangle(); IList<XYZ> corners = uiview.GetZoomCorners(); XYZ p = corners[0]; XYZ q = corners[1]; XYZ v = q - p; XYZ center = p + 0.5 * v; v *= 13; // Zoom out if bigger than 1; Zoom in if smaller than 1 p = center - v; 103 q = center + v; uiview.ZoomAndCenterRectangle(p,q); #endregion #region Initialize main program // Set comfort zone to ASHRAE 55-2017 Form3.LT = "68"; Form3.HT = "78"; Form3.LH = "20"; Form3.HH = "80"; Mainform.ShowDialog(); Mainform.LoadDgv(); #endregion } #endregion #region Sensor 3: Watt Hall Lower Rosendin public void C_Watt_Hall_Lower_Rosendin() { #region Declare variables Form1 Mainform = new Form1(); Form1.RealTimeRepository = @"E:\USC\2018 Fall\ARCH692a\Tool Development\Object\Real-time\"; Form1.PicRepository = @"E:\USC\2018 Fall\ARCH692a\Tool Development\Object\Pictures\"; Mainform.SelectSensor.Text = "Watt Hall Lower Rosendin"; Document doc = this.ActiveUIDocument.Document; UIDocument uidoc = this.ActiveUIDocument; View view = doc.ActiveView; UIView uiview = null; IList<UIView> uiviews = uidoc.GetOpenUIViews(); #endregion #region Reset color schemes and set new ones G_Reset(); ElementId ColorSchemeId = new ElementId(1305148); OverrideGraphicSettings NewOgs = new OverrideGraphicSettings(); NewOgs.SetProjectionLineColor(new Autodesk.Revit.DB.Color(255,0,0)); using (Transaction t = new Transaction(doc,"Set Element Override")) { t.Start(); doc.ActiveView.SetElementOverrides(ColorSchemeId, NewOgs); uidoc.ShowElements(ColorSchemeId); t.Commit(); } #endregion #region Zoom out foreach(UIView uv in uiviews) { if(uv.ViewId.Equals(view.Id)) { uiview = uv; break; } } Rectangle rect = uiview.GetWindowRectangle(); IList<XYZ> corners = uiview.GetZoomCorners(); XYZ p = corners[0]; XYZ q = corners[1]; XYZ v = q - p; XYZ center = p + 0.5 * v; v *= 5; // Zoom out if bigger than 1; Zoom in if smaller than 1 p = center - v; q = center + v; 104 uiview.ZoomAndCenterRectangle(p,q); #endregion #region Initialize main program // Set comfort zone to ASHRAE 55-2017 Form3.LT = "68"; Form3.HT = "78"; Form3.LH = "20"; Form3.HH = "80"; Mainform.ShowDialog(); Mainform.LoadDgv(); #endregion } #endregion #region Sensor 4: Watt Hall 212 public void D_Watt_Hall_212() { #region Declare variables Form1 Mainform = new Form1(); Form1.RealTimeRepository = @"E:\USC\2018 Fall\ARCH692a\Tool Development\Object\Real-time\"; Form1.PicRepository = @"E:\USC\2018 Fall\ARCH692a\Tool Development\Object\Pictures\"; Mainform.SelectSensor.Text = "Watt Hall 212"; Document doc = this.ActiveUIDocument.Document; UIDocument uidoc = this.ActiveUIDocument; View view = doc.ActiveView; UIView uiview = null; IList<UIView> uiviews = uidoc.GetOpenUIViews(); #endregion #region Reset color schemes and set new ones G_Reset(); ElementId ColorSchemeId = new ElementId(1304930); OverrideGraphicSettings NewOgs = new OverrideGraphicSettings(); NewOgs.SetProjectionLineColor(new Autodesk.Revit.DB.Color(255,0,0)); using (Transaction t = new Transaction(doc,"Set Element Override")) { t.Start(); doc.ActiveView.SetElementOverrides(ColorSchemeId, NewOgs); uidoc.ShowElements(ColorSchemeId); t.Commit(); } #endregion #region Zoom out foreach(UIView uv in uiviews) { if(uv.ViewId.Equals(view.Id)) { uiview = uv; break; } } Rectangle rect = uiview.GetWindowRectangle(); IList<XYZ> corners = uiview.GetZoomCorners(); XYZ p = corners[0]; XYZ q = corners[1]; XYZ v = q - p; XYZ center = p + 0.5 * v; v *= 15; // Zoom out if bigger than 1; Zoom in if smaller than 1 p = center - v; q = center + v; 105 uiview.ZoomAndCenterRectangle(p,q); #endregion #region Initialize main program // Set comfort zone to ASHRAE 55-2017 Form3.LT = "68"; Form3.HT = "78"; Form3.LH = "20"; Form3.HH = "80"; Mainform.ShowDialog(); Mainform.LoadDgv(); #endregion } #endregion #region Sensor 5: Watt Hall B1 public void E_Watt_Hall_B1() { #region Declare variables Form1 Mainform = new Form1(); Form1.RealTimeRepository = @"E:\USC\2018 Fall\ARCH692a\Tool Development\Object\Real-time\"; Form1.PicRepository = @"E:\USC\2018 Fall\ARCH692a\Tool Development\Object\Pictures\"; Mainform.SelectSensor.Text = "Watt Hall B1"; Document doc = this.ActiveUIDocument.Document; UIDocument uidoc = this.ActiveUIDocument; View view = doc.ActiveView; UIView uiview = null; IList<UIView> uiviews = uidoc.GetOpenUIViews(); #endregion #region Reset color schemes and set new ones G_Reset(); ElementId ColorSchemeId = new ElementId(1305363); OverrideGraphicSettings NewOgs = new OverrideGraphicSettings(); NewOgs.SetProjectionLineColor(new Autodesk.Revit.DB.Color(255,0,0)); using (Transaction t = new Transaction(doc,"Set Element Override")) { t.Start(); doc.ActiveView.SetElementOverrides(ColorSchemeId, NewOgs); uidoc.ShowElements(ColorSchemeId); t.Commit(); } #endregion #region Zoom out foreach(UIView uv in uiviews) { if(uv.ViewId.Equals(view.Id)) { uiview = uv; break; } } Rectangle rect = uiview.GetWindowRectangle(); IList<XYZ> corners = uiview.GetZoomCorners(); XYZ p = corners[0]; XYZ q = corners[1]; XYZ v = q - p; XYZ center = p + 0.5 * v; v *= 20; // Zoom out if bigger than 1; Zoom in if smaller than 1 p = center - v; q = center + v; uiview.ZoomAndCenterRectangle(p,q); 106 #endregion #region Initialize main program // Set comfort zone to ASHRAE 55-2017 Form3.LT = "68"; Form3.HT = "78"; Form3.LH = "20"; Form3.HH = "80"; Mainform.ShowDialog(); Mainform.LoadDgv(); #endregion } #endregion } } 107 A.2 Form1 – Main interface /* * Created by SharpDevelop. * User: gelin * Date: 2018/11/5 * Time: 10:32 * * To change this template use Tools | Options | Coding | Edit Standard Headers. */ using System; using System.Data; using System.Drawing; using System.Windows.Forms; using System.IO; using Autodesk.Revit.UI; using Autodesk.Revit.DB; using Autodesk.Revit.UI.Selection; using Autodesk.Revit.ApplicationServices; using System.Collections.Generic; using System.Linq; using System.Windows.Forms.DataVisualization.Charting; using System.Net; using System.Text.RegularExpressions; namespace NewReadAdafruit { /// <summary> /// Description of Form1. /// </summary> /// public partial class Form1 : System.Windows.Forms.Form { //Create data tables. public DataTable TempDataTable = new DataTable(); public DataTable HumidDataTable = new DataTable(); //=============================Strings and variables========================// public static string feed_id; public static string element_id; public static string RealTimeRepository = @"E:\USC\2018 Fall\ARCH692a\Tool Development\Object\Real-time\"; public static string PicRepository = @"E:\USC\2018 Fall\ARCH692a\Tool Development\Object\Pictures\"; //=============================Form1 Initialization=========================// public Form1() { // // The InitializeComponent() call is required for Windows Forms designer support. // InitializeComponent(); // // TODO: Add constructor code after the InitializeComponent() call. // } //=============================Custom Functions=============================// public void DateFilter() { // Object reference Form2 Form2 = new Form2(this); // Set date ranges string DateRange = ""; // Apply different date ranges if (Form2.StartDate.Checked == true && Form2.EndDate.Checked == true) { string DateRangeSE = "created_at >= '" + Form2.SY + "-" + Form2.SM + "-" + Form2.SD + "T00:00:00' " + "and created_at <= '" + Form2.EY + "-" + Form2.EM + "-" + Form2.ED + "T23:59:59'"; DateRange = DateRangeSE; } if (Form2.StartDate.Checked == true && Form2.EndDate.Checked == false) { string DateRangeS = "created_at >= '" + Form2.SY + "-" + Form2.SM + "-" + Form2.SD + "T00:00:00'"; DateRange = DateRangeS; } 108 if (Form2.StartDate.Checked == false && Form2.EndDate.Checked == true) { string DateRangeE = "created_at <= '" + Form2.EY + "-" + Form2.EM + "-" + Form2.ED + "T23:59:59'"; DateRange = DateRangeE; } // Refresh data views DataView PartialTempView = new DataView(); PartialTempView = TempDataTable.DefaultView; PartialTempView.RowFilter = DateRange; DataView PartialHumidView = new DataView(); PartialHumidView = HumidDataTable.DefaultView; PartialHumidView.RowFilter = DateRange; ColorScheme(); // Apply date range to the line plat as well. TempLinePlot.Refresh(); TempLinePlot.DataSource = PartialTempView; TempLinePlot.Series["Temperature ( ℉)"].XValueMember = "created_at"; TempLinePlot.Series["Temperature ( ℉)"].YValueMembers = "value"; TempLinePlot.DataBind(); HumidLinePlot.Refresh(); HumidLinePlot.DataSource = PartialHumidView; HumidLinePlot.Series["Relative Humidity (%)"].XValueMember = "created_at"; HumidLinePlot.Series["Relative Humidity (%)"].YValueMembers = "value"; HumidLinePlot.DataBind(); } public void ColorScheme() { // Color scheme foreach (DataGridViewRow TempRow in DataGridView1.Rows) { // Temperature too low if (Convert.ToDecimal(TempRow.Cells[1].Value) < Convert.ToDecimal(Form3.LT)) { TempRow.Cells[1].Style.BackColor = System.Drawing.Color.Cyan; TempRow.Cells[5].Style.BackColor = System.Drawing.Color.Cyan; } // Temperature too high if (Convert.ToDecimal(TempRow.Cells[1].Value) > Convert.ToDecimal(Form3.HT)) { TempRow.Cells[1].Style.BackColor = System.Drawing.Color.Orange; TempRow.Cells[5].Style.BackColor = System.Drawing.Color.Orange; } } foreach (DataGridViewRow HumidRow in DataGridView2.Rows) { // Humidity too low if (Convert.ToDecimal(HumidRow.Cells[1].Value) < Convert.ToDecimal(Form3.LH)) { HumidRow.Cells[1].Style.BackColor = System.Drawing.Color.Cyan; HumidRow.Cells[5].Style.BackColor = System.Drawing.Color.Cyan; } // Humidity too high if (Convert.ToDecimal(HumidRow.Cells[1].Value) > Convert.ToDecimal(Form3.HH)) { HumidRow.Cells[1].Style.BackColor = System.Drawing.Color.Orange; HumidRow.Cells[5].Style.BackColor = System.Drawing.Color.Orange; } } } public void LoadDgv() { // Reset filters ResetFilter.Enabled = true; NoTempLinePlot.Visible = false; NoHumidLinePlot.Visible = false; EnableFaultyOnly.Enabled = true; EnableFaultyOnly.Checked = false; EnableDateFilter.Enabled = true; EnableDateFilter.Checked = false; SetDate.Enabled = true; // A file path is composed of three parts -- file path, file name and the file extension. if (SelectSensor.Text == "Watt Hall Building Science Corner") {TBElementId.Text = "1304799";} 109 if (SelectSensor.Text == "Watt Hall Upper Rosendin") {TBElementId.Text = "1304568";} if (SelectSensor.Text == "Watt Hall Lower Rosendin") {TBElementId.Text = "1305148";} if (SelectSensor.Text == "Watt Hall 212") {TBElementId.Text = "1304930";} if (SelectSensor.Text == "Watt Hall B1") {TBElementId.Text = "1305363";} #region Temperature data goes to DataGridView1. // Dispose datatable TempDataTable.Dispose(); TempDataTable = new DataTable(); DataGridView1.Refresh(); DataGridView1.DataSource = TempDataTable; DataGridView1.AllowUserToAddRows = false; string SensorInfoPath = RealTimeRepository + SelectSensor.Text + " - Temp.csv"; string[] raw_text = System.IO.File.ReadAllLines(SensorInfoPath); string[] data_col = null; int x = 0; // Generate columns and rows foreach (string text_line in raw_text) { data_col = text_line.Split(','); // Import the header. if (x == 0) { for(int i = 0; i < data_col.Count(); i++) { TempDataTable.Columns.Add(data_col[i]); } x++; } // Import data. else { TempDataTable.Rows.Add(data_col); } } for (int TempColNum = 0; TempColNum < 6; TempColNum ++) { DataGridView1.Columns[TempColNum].AutoSizeMode = DataGridViewAutoSizeColumnMode.AllCells; DataGridView1.Columns[TempColNum].SortMode = DataGridViewColumnSortMode.NotSortable; } #endregion #region Humidity data goes to DataGridView2. // Dispose datatable HumidDataTable.Dispose(); HumidDataTable = new DataTable(); DataGridView2.Refresh(); DataGridView2.DataSource = HumidDataTable; DataGridView2.AllowUserToAddRows = false; SensorInfoPath = RealTimeRepository + SelectSensor.Text + " - Humid.csv"; raw_text = System.IO.File.ReadAllLines(SensorInfoPath); data_col = null; x = 0; // Generate columns and rows foreach (string text_line in raw_text) { data_col = text_line.Split(','); // Import the header. if (x == 0) { for(int i = 0; i < data_col.Count(); i++) { HumidDataTable.Columns.Add(data_col[i]); } x++; } // Import data. else { HumidDataTable.Rows.Add(data_col); } 110 } for (int HumidColNum = 0; HumidColNum < 6; HumidColNum ++) { DataGridView2.Columns[HumidColNum].AutoSizeMode = DataGridViewAutoSizeColumnMode.AllCells; DataGridView2.Columns[HumidColNum].SortMode = DataGridViewColumnSortMode.NotSortable; } #endregion #region Load room and sensor photographs RoomPhoto.Image = Image.FromFile(PicRepository + SelectSensor.Text + " - Room.jpg"); SensorPhoto.Image = Image.FromFile(PicRepository + SelectSensor.Text + " - Sensor.jpg"); #endregion #region Set color scheme based on comfort zone ColorScheme(); #endregion #region Generate line chart TempLinePlot.DataSource = TempDataTable; TempLinePlot.Series["Temperature ( ℉)"].XValueMember = "created_at"; TempLinePlot.Series["Temperature ( ℉)"].YValueMembers = "value"; TempLinePlot.ChartAreas[0].AxisY2.Minimum = 40; TempLinePlot.ChartAreas[0].AxisY.Minimum = 40; TempLinePlot.DataBind(); // Reverse X axis ChartArea Tlp = TempLinePlot.ChartAreas[0]; Tlp.AxisY2.Enabled = AxisEnabled.True; Tlp.AxisY.Enabled = AxisEnabled.False; Tlp.AxisX.IsReversed = true; HumidLinePlot.DataSource = HumidDataTable; HumidLinePlot.Series["Relative Humidity (%)"].XValueMember = "created_at"; HumidLinePlot.Series["Relative Humidity (%)"].YValueMembers = "value"; HumidLinePlot.DataBind(); // Reverse X axis ChartArea Hlp = HumidLinePlot.ChartAreas[0]; Hlp.AxisY2.Enabled = AxisEnabled.True; Hlp.AxisY.Enabled = AxisEnabled.False; Hlp.AxisX.IsReversed = true; #endregion } //=============================Tool Strip Bar Commands=======================// #region File -- Sync data with Adafruit IO void ToolStripMenuItem3Click(object sender, System.EventArgs e) { using (var client = new WebClient()) { string CurrentTxtFile = ""; string CurrentCsvFile = ""; for (int FileCounter = 0; FileCounter <= 9; FileCounter++) { // Create list of data files for the loop below. if (FileCounter == 0) {CurrentTxtFile = "node-13.temp"; CurrentCsvFile = "Watt Hall Building Science Corner - Temp";} if (FileCounter == 1) {CurrentTxtFile = "node-13.humid"; CurrentCsvFile = "Watt Hall Building Science Corner - Humid";} if (FileCounter == 2) {CurrentTxtFile = "node-7.temp"; CurrentCsvFile = "Watt Hall Upper Rosendin - Temp";} if (FileCounter == 3) {CurrentTxtFile = "node-7.humid"; CurrentCsvFile = "Watt Hall Upper Rosendin - Humid";} if (FileCounter == 4) {CurrentTxtFile = "node-8.temp"; CurrentCsvFile = "Watt Hall Lower Rosendin - Temp";} if (FileCounter == 5) {CurrentTxtFile = "node-8.humid"; CurrentCsvFile = "Watt Hall Lower Rosendin - Humid";} if (FileCounter == 6) {CurrentTxtFile = "node-11.temp"; CurrentCsvFile = "Watt Hall 212 - Temp";} if (FileCounter == 7) {CurrentTxtFile = "node-11.humid"; CurrentCsvFile = "Watt Hall 212 - Humid";} if (FileCounter == 8) {CurrentTxtFile = "node-3.temp"; CurrentCsvFile = "Watt Hall B1 - Temp";} if (FileCounter == 9) {CurrentTxtFile = "node-3.humid"; CurrentCsvFile = "Watt Hall B1 - Humid";} // Set the file path and download from Adafruit IO. // Get the URL, download, rename the file and save it to the designated file path // SENSITIVE DATA, DO NOT SHARE string RealTimeRepository = @"E:\USC\2018 Fall\ARCH692a\Tool Development\Object\Real-time\"; client.DownloadFile("https://io.adafruit.com/api/v2/buildingscience/feeds/" + CurrentTxtFile + "/data?X-AIO-Key=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", RealTimeRepository + CurrentTxtFile + ".txt"); 111 // Start a new line for every feed value. // Remove brackets and braces. string newline = File.ReadAllText(RealTimeRepository + CurrentTxtFile + ".txt"); newline = newline.Replace("[",""); newline = newline.Replace("]",","); newline = newline.Replace("{",""); newline = newline.Replace("},","},\r\n"); newline = newline.Replace("}",""); // Remove attribute names. newline = newline.Replace("\"id\":",""); newline = newline.Replace("\"value\":",""); newline = newline.Replace("\"feed_id\":",""); newline = newline.Replace("\"feed_key\":",""); newline = newline.Replace("\"created_at\":",""); newline = newline.Replace("\"location\":null,\"lat\":null,\"lon\":null,\"ele\":null,\"created_epoch\":",""); newline = newline.Replace("\"expiration\":",""); newline = newline.Replace("\"",""); // Use regular expression to remove "created_epoch" and "expiration". // Need improvement. newline = Regex.Replace(newline,"Z,15[^Z]+Z",""); // Pruning done. File.WriteAllText(RealTimeRepository + CurrentTxtFile + ".txt", newline); // The StreamWriter will create the file if it doesn't exist. TextWriter tw = new StreamWriter(RealTimeRepository + CurrentCsvFile + ".csv"); tw.WriteLine("id,value,feed_id,feed_key,created_at,status"); // Close the file before appending text. Or it will cause error. tw.Close(); File.AppendAllText(RealTimeRepository + CurrentCsvFile + ".csv", newline); } } // Synchronization done. MessageBox.Show("All sensor data have been synchronized with Adafruit IO server.\n\n" + "Any existing files have been overwritten.","Synchronization Completed!", MessageBoxButtons.OK,MessageBoxIcon.Information); } #endregion #region File -- Clear All Data void ToolStripMenuItem1Click(object sender, EventArgs e) { // Disable filters ResetFilter.Enabled = false; NoTempLinePlot.Visible = true; EnableFaultyOnly.Enabled = false; EnableDateFilter.Enabled = false; SetDate.Enabled = false; #region Dispose datatable TempDataTable.Dispose(); TempDataTable = new DataTable(); DataGridView1.Refresh(); DataGridView1.DataSource = TempDataTable; HumidDataTable.Dispose(); HumidDataTable = new DataTable(); DataGridView2.Refresh(); DataGridView2.DataSource = TempDataTable; #endregion RoomPhoto.Image = null; SensorPhoto.Image = null; } #endregion // File -- Exit void ExitToolStripMenuItem1Click(object sender, EventArgs e) { Close(); } // Edit -- Comfort zone void ApplyFiltersToolStripMenuItemClick(object sender, EventArgs e) { // Go to filter window. Form3 Form3 = new Form3(this); 112 Form3.ShowDialog(); } // Help -- About void AboutToolStripMenuItemClick(object sender, EventArgs e) { MessageBox.Show("Adafruit IO Reader Version 0.5\nDeveloped By: Gelin Su (University of Southern California)\n" + "Last Update: 02/04/2019\nContact: gelinsu@usc.edu","About", MessageBoxButtons.OK,MessageBoxIcon.Information); } //=============================Interface Commands=============================// // ALL FEATURES START FROM HERE - Select a sensor and open corresponding CSV file. void SelectSensorSelectedIndexChanged(object sender, EventArgs e) { LoadDgv(); } // Reset filter. void ResetFilterClick(object sender, EventArgs e) { EnableDateFilter.Checked = false; EnableFaultyOnly.Checked = false; TempDataTable.DefaultView.RowFilter = string.Empty; HumidDataTable.DefaultView.RowFilter = string.Empty; // Reset filter for the line plot as well. NoTempLinePlot.Visible = false; TempLinePlot.Refresh(); TempLinePlot.DataSource = TempDataTable; TempLinePlot.Series["Temperature ( ℉)"].XValueMember = "created_at"; TempLinePlot.Series["Temperature ( ℉)"].YValueMembers = "value"; TempLinePlot.DataBind(); NoHumidLinePlot.Visible = false; HumidLinePlot.Refresh(); HumidLinePlot.DataSource = HumidDataTable; HumidLinePlot.Series["Relative Humidity (%)"].XValueMember = "created_at"; HumidLinePlot.Series["Relative Humidity (%)"].YValueMembers = "value"; HumidLinePlot.DataBind(); } // All values and faulty values void FaultyOnlyCheckedChanged(object sender, EventArgs e) { if (EnableFaultyOnly.Checked == true) { // Filter temperature values. DataView TempDataView = new DataView(); TempDataView = TempDataTable.DefaultView; TempDataView.RowFilter = "value > '" + Form3.HT + "' or value < '" + Form3.LT + "'"; NoTempLinePlot.Visible = true; // Filter RH values. DataView HumidDataView = new DataView(); HumidDataView = HumidDataTable.DefaultView; HumidDataView.RowFilter = "value > '" + Form3.HH + "' or value < '" + Form3.LH + "'"; NoHumidLinePlot.Visible = true; ColorScheme(); } else { TempDataTable.DefaultView.RowFilter = string.Empty; HumidDataTable.DefaultView.RowFilter = string.Empty; NoTempLinePlot.Visible = false; NoHumidLinePlot.Visible = false; ColorScheme(); } } // Set start and end date void SetDateClick(object sender, EventArgs e) { Form2 Form2 = new Form2(this); Form2.ShowDialog(); } } } 113 A.3 Form2 – Date Filter /* * Created by SharpDevelop. * User: gelin * Date: 2/4/2019 * Time: 15:43 * * To change this template use Tools | Options | Coding | Edit Standard Headers. */ using System; using System.Drawing; using System.Windows.Forms; namespace NewReadAdafruit { /// <summary> /// Description of Form2. /// </summary> public partial class Form2 : Form { // Declaration of the main form. Form1 MainForm; //=============================Strings======================================// public static string SY; public static string SM; public static string SD; public static string EY; public static string EM; public static string ED; public Form2(Form1 MainForm) { // // The InitializeComponent() call is required for Windows Forms designer support. // InitializeComponent(); this.MainForm = MainForm; // // TODO: Add constructor code after the InitializeComponent() call. // StartDate.Checked = true; EndDate.Checked = true; StartYear.Text = "2018"; StartMonth.Text = "12"; StartDay.Text = "12"; EndYear.Text = "2018"; EndMonth.Text = "12"; EndDay.Text = "13"; } // Decide if both dates are used. void StartDateCheckedChanged(object sender, EventArgs e) { if (StartDate.Checked == true) { StartYear.Enabled = true; StartMonth.Enabled = true; StartDay.Enabled = true; } if (StartDate.Checked == false) { StartYear.Enabled = false; StartMonth.Enabled = false; StartDay.Enabled = false; } } void EndDateCheckedChanged(object sender, EventArgs e) { 114 if (EndDate.Checked == true) { EndYear.Enabled = true; EndMonth.Enabled = true; EndDay.Enabled = true; } if (EndDate.Checked == false) { EndYear.Enabled = false; EndMonth.Enabled = false; EndDay.Enabled = false; } } // OK button void Button1Click(object sender, EventArgs e) { if (StartDate.Checked == false && EndDate.Checked == false) { MessageBox.Show("Please check at least one box to set the date range.","Date Range", MessageBoxButtons.OK,MessageBoxIcon.Exclamation); return; } // Data validation only when both start and end date boxes are checked if (StartDate.Checked == true && EndDate.Checked == true) { // Year int InvalidYear = string.Compare(StartYear.Text, EndYear.Text); if (InvalidYear == 1) { MessageBox.Show("The start year cannot be later than the end year.","Invalid Year Range", MessageBoxButtons.OK,MessageBoxIcon.Exclamation); StartYear.Focus(); return; } // Month int InvalidMonth = string.Compare(StartMonth.Text, EndMonth.Text); if (InvalidMonth == 1) { MessageBox.Show("The start month cannot be later than the end month.","Invalid Month Range", MessageBoxButtons.OK,MessageBoxIcon.Exclamation); StartMonth.Focus(); return; } // Day int InvalidDay = string.Compare(StartDay.Text, EndDay.Text); if (InvalidDay == 1) { MessageBox.Show("The start day cannot be later than the end day.","Invalid Day Range", MessageBoxButtons.OK,MessageBoxIcon.Exclamation); StartDay.Focus(); return; } } // Apply date filter SY = StartYear.Text; SM = StartMonth.Text; SD = StartDay.Text; EY = EndYear.Text; EM = EndMonth.Text; ED = EndDay.Text; MainForm.DateFilter(); Close(); } // Cancel button void Button2Click(object sender, EventArgs e) { Close(); } } } 115 A.4 Form3 – Comfort Zones /* * Created by SharpDevelop. * User: gelin * Date: 12/3/2018 * Time: 15:02 * * To change this template use Tools | Options | Coding | Edit Standard Headers. */ using System; using System.Drawing; using System.Windows.Forms; using System.IO; using System.Linq; namespace NewReadAdafruit { /// <summary> /// Description of Form3. /// </summary> public partial class Form3 : Form { // Declaration of the main form. Form1 MainForm; //=============================Strings======================================// public static string LT; public static string HT; public static string LH; public static string HH; string ComfortRepository = @"E:\USC\2018 Fall\ARCH692a\Tool Development\Object\"; //=============================Form3 Initialization=========================// public Form3(Form1 MainForm) { // // The InitializeComponent() call is required for Windows Forms designer support. // InitializeComponent(); this.MainForm = MainForm; // Set default value preset.Text = "ASHRAE 55-2017"; LowTemp.Text = "68"; HighTemp.Text = "78"; LowHumid.Text = "20"; HighHumid.Text = "80"; // // TODO: Add constructor code after the InitializeComponent() call. // } public void DisableBoxes() { LowTemp.Enabled = false; HighTemp.Enabled = false; LowHumid.Enabled = false; HighHumid.Enabled = false; } void PresetSelectedIndexChanged(object sender, EventArgs e) { if(preset.Text == "ASHRAE 55-2017") { DisableBoxes(); LowTemp.Text = "66"; HighTemp.Text = "84"; LowHumid.Text = "20"; HighHumid.Text = "80"; } 116 if(preset.Text == "ISO 7730 - Winter") { DisableBoxes(); LowTemp.Text = "68"; HighTemp.Text = "75.2"; LowHumid.Text = "30"; HighHumid.Text = "70"; } if(preset.Text == "ISO 7730 - Summer") { DisableBoxes(); LowTemp.Text = "73.4"; HighTemp.Text = "78.8"; LowHumid.Text = "30"; HighHumid.Text = "70"; } if(preset.Text == "Test Option 1") { DisableBoxes(); LowTemp.Text = "68"; HighTemp.Text = "72"; LowHumid.Text = "20"; HighHumid.Text = "80"; } if(preset.Text == "Test Option 2") { DisableBoxes(); LowTemp.Text = "72"; HighTemp.Text = "78"; LowHumid.Text = "20"; HighHumid.Text = "80"; } if(preset.Text == "Customize...") { LowTemp.Enabled = true; HighTemp.Enabled = true; LowHumid.Enabled = true; HighHumid.Enabled = true; // Values need to be read from the file LowTemp.Text = File.ReadLines(ComfortRepository + "Customized Comfort Zone.txt").Skip(0).Take(1).First(); HighTemp.Text = File.ReadLines(ComfortRepository + "Customized Comfort Zone.txt").Skip(1).Take(1).First(); LowHumid.Text = File.ReadLines(ComfortRepository + "Customized Comfort Zone.txt").Skip(2).Take(1).First(); HighHumid.Text = File.ReadLines(ComfortRepository + "Customized Comfort Zone.txt").Skip(3).Take(1).First(); } } // Button -- OK void Button1Click(object sender, EventArgs e) { // Data validation int InvalidTemp = string.Compare(LowTemp.Text, HighTemp.Text); if (InvalidTemp == 1) { MessageBox.Show("The low value cannot be higher than the high value.","Invalid Temperature Range", MessageBoxButtons.OK,MessageBoxIcon.Exclamation); LowTemp.Focus(); return; } int InvalidHumid = string.Compare(LowHumid.Text, HighHumid.Text); if (InvalidHumid == 1) { MessageBox.Show("The low value cannot be higher than the high value.","Invalid Relative Humidity Range", MessageBoxButtons.OK,MessageBoxIcon.Exclamation); LowHumid.Focus(); return; } if (string.IsNullOrWhiteSpace(LowTemp.Text) || string.IsNullOrWhiteSpace(HighTemp.Text) || string.IsNullOrWhiteSpace(LowHumid.Text) || string.IsNullOrWhiteSpace(HighHumid.Text)) { MessageBox.Show("Please enter valid values.","Data is missing", MessageBoxButtons.OK,MessageBoxIcon.Exclamation); 117 return; } LT = LowTemp.Text; HT = HighTemp.Text; LH = LowHumid.Text; HH = HighHumid.Text; // Use presets if (preset.Text != "Customize...") { // Just refresh data grid views. MainForm.LoadDgv(); Close(); } // Use customized comfort zone else { // Write comfort zone to a file string[] lines = {LT, HT, LH, HH}; System.IO.File.WriteAllLines(ComfortRepository + "Customized Comfort Zone.txt", lines); // Then refresh data grid views. MainForm.LoadDgv(); Close(); } } // Button -- Cancel void Button2Click(object sender, EventArgs e) { Close(); } } }
Abstract (if available)
Abstract
During the operation and maintenance (O&M) phase of a building, nearly 30% of its operating expenses were spent on utilities, and the majority of this expenditure belongs to energy costs (electricity and natural gas) for powering varieties of facilities and equipment. Therefore, an effective and easy-to-access system for facility management (FM) is significant in terms of both financial consideration and building performance. Building Information Modeling (BIM) technology is a powerful tool to assist FM, by integrating BIM into the FM process. ❧ One of the examples is the integration of real-time sensor data into BIM models that help with daily monitoring and fault detection of sensors. By pinpointing the location of faults in 3D models, FM personnel are able to find out the reason for fault occurrences and execute corrective maintenance or make changes to the indoor environment such as thermal condition. ❧ A BIM-based visualization tool “Adafruit IO Reader” was developed with the C# programming language in Revit Macro IDE to interface real-time Internet of Things (IoT) sensor data feeds in Autodesk Revit. Data feeds were retrieved from TrojanSense Project, which intended for providing strategies of improving thermal comfort. By executing C# codes, data feeds were retrieved from the Adafruit IO server and saved as text (TXT) files. These files were pruned and converted to comma-separated values (CSV) files, and then imported into the tool. Feeds were displayed both in tables and line graphs. By making connections between sensor data feed IDs and sensor model IDs in Revit, users could be navigated to corresponding sensors in Revit. Fault detection algorithm based on comfort zones such as ASHRAE 55-2017 helped locate sensor with abnormal values, and these sensors were highlighted with alerting colors in 3D views. ❧ Usability of the tool was tested with installed IoT sensors in Watt Hall (WAH), and the tool was able to locate faulted sensors and highlight them. The research findings contribute to the area of information visualization in facility management, and the tool can provide FM personnel with an insight into HVAC operation in terms of improving indoor thermal comfort.
Linked assets
University of Southern California Dissertations and Theses
Conceptually similar
PDF
Using building information modeling with augmented reality: visualizing and editing MEP systems with a mobile augmented reality application
PDF
Exploring participatory sensing and the Internet of things to evaluate temperature setpoint policy and potential of overheating/overcooling of spaces on the USC campus
PDF
BIM+AR in architecture: a building maintenance application for a smart phone
PDF
Building information modeling based design review and facility management: Virtual reality workflows and augmented reality experiment for healthcare project
PDF
Visualizing thermal data in a building information model
PDF
MM Electrical Tool: a tool for generating electrical single line diagrams in BIM
PDF
Data visualization in VR/AR: static data analysis in buildings
PDF
Streamlining sustainable design in building information modeling: BIM-based PV design and analysis tools
PDF
Building bridges: filling gaps between BIM and other tools in mechanical design
PDF
CFD visualization: a case study for using a building information modeling with virtual reality
PDF
Enhancing thermal comfort: data-driven approach to control air temperature based on facial skin temperature
PDF
Bridging the gap: a tool to support bim data transparency for interoperability with building energy performance software
PDF
Office floor plans generation based on Generative Adversarial Network
PDF
Enhancing thermal comfort: air temperature control based on human facial skin temperature
PDF
Multi-occupancy environmental control for smart connected communities
PDF
Developing environmental controls using a data-driven approach for enhancing environmental comfort and energy performance
PDF
Human–building integration: machine learning–based and occupant eye pupil size–driven lighting control as an applicable visual comfort tool in the office environment
PDF
Real-time simulation-based feedback on carbon impacts for user-engaged temperature management
PDF
Single & multi-family housing: the complex behind the simple: a kit of parts for minimally invasive interventions
PDF
Smart buildings: employing modern technology to create an integrated, data-driven, intelligent, self-optimizing, human-centered, building automation system
Asset Metadata
Creator
Su, Gelin
(author)
Core Title
A BIM-based visualization tool for facilities management: fault detection through integrating real-time sensor data into BIM
School
School of Architecture
Degree
Master of Building Science
Degree Program
Building Science
Publication Date
04/16/2019
Defense Date
03/22/2019
Publisher
University of Southern California
(original),
University of Southern California. Libraries
(digital)
Tag
building information modeling (BIM),facilities management and operation,fault detection,IoT sensors,OAI-PMH Harvest,Visualization
Format
application/pdf
(imt)
Language
English
Contributor
Electronically uploaded by the author
(provenance)
Advisor
Kensek, Karen (
committee chair
), Choi, Joon-Ho (
committee member
), Konis, Kyle (
committee member
)
Creator Email
gelinsu@usc.edu,gelinsu94@gmail.com
Permanent Link (DOI)
https://doi.org/10.25549/usctheses-c89-139018
Unique identifier
UC11675822
Identifier
etd-SuGelin-7196.pdf (filename),usctheses-c89-139018 (legacy record id)
Legacy Identifier
etd-SuGelin-7196.pdf
Dmrecord
139018
Document Type
Thesis
Format
application/pdf (imt)
Rights
Su, Gelin
Type
texts
Source
University of Southern California
(contributing entity),
University of Southern California Dissertations and Theses
(collection)
Access Conditions
The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the a...
Repository Name
University of Southern California Digital Library
Repository Location
USC Digital Library, University of Southern California, University Park Campus MC 2810, 3434 South Grand Avenue, 2nd Floor, Los Angeles, California 90089-2810, USA
Tags
building information modeling (BIM)
facilities management and operation
fault detection
IoT sensors