Knowledge Capture

In addition to lifecycle data, building knowledge is captured by FM experts and system designers using different methods (e.g., fault trees) as explained in Subsection ‎2.6. In this Subsection, available IFC resources that can be used to capture various O&M-related knowledge are investigated.

6.3.2.1 Logical and Spatial Relationships Definition

Defining relationships among building elements is one of the basic steps to capture building knowledge. Two types of relationships between components and spaces are used: (1) Logical relationships: The logically related components are not necessarily physically connected. For example, the connection between a light switch and a light fixture can be considered as a logical relationship because the cable connecting the switch to the light is not usually added to the model (Liebich, 2009); and (2) Spatial relationships: A spatial relationship defines the relationship between components and/or

134

spaces in which they are physically related (e.g., containment, connection, and adjacency relationships).

Various types of logical and spatial relationships are defined and the categorization of these relationships is done based on the literature and interviews with FM personnel. The Relationship between two related entities (Ei and Ej) is defined using the following notation: where m defines the type of relationship (i.e. logical (l) or spatial (s)) and n defines the category and the instance of the relationship (e.g., a part of HVAC#1 system belongs to the electrical engineering department). Based on this definition, the following are different possible groups of relationships: (1) Relationships between components ( ); (2) Relationships between spaces ( ); and (3) Relationships between spaces and components ( ). In Figure ‎6-3, shows a logical relationship between Sa and Sb that are not adjacent or physically connected but logically related. For example, Sa can be a mechanical room and Sb can be a space that is located at a different floor from Sa but Sa provides Sb with heating/cooling. shows the logical relationship between C1 and C4 which are logically related but not physically connected. For example, the relationship between a boiler located in the mechanical room Sa and a supply diffuser in Sc. shows the spatial relationship between C2 and C3 that are located in Sb and physically connected (e.g., ducts and supply diffusers). shows the spatial relationship between two spaces Sb and Sc that are adjacent. In addition, C1 has a logical relationship with Sc( ), but spatial relationship with Sa( ).

135 C4 C3 C1 C2 Sa Sb _Sc `

Figure ‎6-3 Examples of spatial and logical relationships between components and spaces

Realizing spatial and logical relationships in IFC

The IfcRelConnectsElements resource provides the generalization of a one-to-one logical connection between elements. In order to capture one-to-many relationships, IfcRelAssignstoProduct can be used. Moreover, the spatial containment relationship between a component and a space is defined in IFC by IfcRelContainedInSpatialStructure. The physical connectivity can be identified in IFC using tags, such as IfcRelConnectsPorts.

Various groups can be defined in IFC using the IfcGroup resource. Systems are examples of the logical grouping of assets. Elements are grouped under a system based on their roles regardless of their position in a building. IfcRelServicesBuildings defines relationships between building service systems (e.g., HVAC) and the site, the building, and its stories, spaces, and spatial zones.

The main resources related to grouping in the current version of IFC (2x4) are: (1) Building service systems (heating, cooling, waste water systems) represented by

136

instances of IfcDistributionSystem; (2) Building systems (fenestration, shading) represented by instances of IfcBuildingSystem; (3) Zones as collection of logically grouped spaces represented by instances of IfcZone; and (4) Idealized structural analysis systems represented by instances of IfcStructuralAnalysisModel.

6.3.2.2 Knowledge Capture Using Fault Trees

Table ‎6-3 shows the list of the high level causes for heating/cooling service tickets in a certain space of a building. A part of the related fault tree is developed for the first four main causes for cooling problems as shown in Figure ‎6-4. The top event in this tree is the too-hot issue that is broken down to intermediate events, such as HVAC failure and openings failure. The intermediate events are further broken down to component level failures (such as air supply fan failure) and basic events (e.g., blown fuse). The triangles connected to intermediate events link the fault tree to other fault trees that are developed for the associated components’ failure.

Table ‎6-3 Possible causes of heating/cooling problems in a space

1 HVAC malfunctioning (Boiler malfunctioning, ducts and supply diffuser deficiency) 2 Temperature sensor or thermostat malfunctioning (Akcamete et al., 2011)

3 Openings isolation problem

4 Window/door not closed properly (Ahluwalia, 2008) 5 Adjacent spaces heat transfer

137

Temperature issue (Too hot) HVAC failure to

provide cool air

Room temperature sensor failure Openings failure to block outside air Ducts failure to transfer air Diffusers failure to supply air Outdoor air intake louver failure

Air filter unit failure Humidification unit failure Air supply fan failure Dampers failure Cooling coil failure Fan assembly failure Fan belt broken Fan bearing failed Blown fuse Loose pulleys Control system failure Chiller failure Cooling tower failure Cooling coil ruptured Tube and fins covered by dirt Closed Blocked Windowss

failure Doors failure

Doors not sealed off Doors are open open Door is broken Cooling water circulating pump failure Control system failure Fan motor failure Condenser water pump Humidity control failure Static pressure control failure Temperature control failure Damper motor failure Fan failure Purge compress motor Failure Oil pump failure Water evaporator pump failure Control unit failure Compressor motor Not Sealed off Open Cracked Not sealed off Dismantled /broken Blocked Blocked by foreign material Damaged or removed Blades are broken Broken Incorrect Settings Filter failed Pre filter failed Internal joints failure Actuator failure Damper motor failure Damper motor control system failure Variable frequency drive failure

138

Realizing fault trees and lifecycle knowledge in IFC

Classifications and hierarchies can be captured in IFC. IfcClassification is used for the arrangement of objects into a class or category according to a common purpose or their common characteristics. Hence, taxonomic schemes, arranged in a hierarchical structure can be captured using IFC definitions. These resources can be used to record system hierarchies and fault trees in an IFC database.

O&M processes can be captured in IFC using IfcProcess entity. An IfcProcess is an activity or event that is ordered in time and has sequence relationships with other processes. Products and resources can be assigned to an IFC process. Moreover, individual O&M tasks (IfcTask) or events (IfcEvent) can be defined in IFC. Using these resources, various processes related to the O&M can be recorded in IFC (e.g., shut down, lock-out/tag-out, and safety and maintenance procedures).

In order to capture historical data, IFC resources such as IfcPerformanceHistory can be used to document the actual performance of an occurrence instance over time. The captured data include machine-measured data from building automation systems and human-specified data, such as tasks and resources usage. The data can represent actual conditions, predictions, or simulation results. The real-time data tracked by performance history takes the form of property sets where all properties are based on time series (e.g., Pset_UtilityConsumptionPHistory (Consumption of utility resources), Pset_BoilerPHistory, and Pset_ActuatorPHistory).

139