Evaluation of reference modeling for building performance assessment

Automation in Construction 40 (2014) 44–59

Contents lists available at ScienceDirect

Automation in Construction journal homepage: www.elsevier.com/locate/autcon

Evaluation of reference modeling for building performance assessment Ipek Gursel Dino a,b,⁎, Rudi Stouffs b,c,1 a b c

Middle East Technical University, Faculty of Architecture, Universiteler Mah., Dumlupinar Bulvari, No: 1, 06800 Ankara, Turkey Technische Universiteit Delft, Faculteit Bouwkunde, Postbus 5043, 2600GA Delft, Netherlands National University of Singapore, Department of Architecture, School of Design and Environment, 4 Architecture Drive, Singapore 117566, Singapore

a r t i c l e

i n f o

Article history: Accepted 28 December 2013 Available online 24 January 2014 Keywords: Lifecycle performance assessment Building maintenance Reference modeling Model-based development Model adaptation

a b s t r a c t Lifecycle building performance assessment (LBPA) practices are being increasingly applied on existing buildings to ensure that performance requirements are fulfilled during building service-life. LBPA is a multi-disciplinary and information-intense process that requires computational tools for information management and decision support. We have previously developed a computational reference model (CLIP-Core) that supports various component-based LBPA practices. When CLIP-Core is considered to be used, it needs to be adapted to the specific context it addresses. We developed two such domain models, CLIP EPI-CREM and CLIP-CMU, for two existing LBPA practices. This paper addresses the evaluation of CLIP-Core and its potential in supporting various requirements. Hereto, we first discuss CLIP-Core and the two domain models. Then we present the evaluation results based on the domain models and their development processes. Finally we discuss guidelines for extending CLIP-Core and recommend technologies and alternative architectures that can increase CLIP-Core’s usability. © 2014 Elsevier B.V. All rights reserved.

1. Introduction The continuous assessment of performance of existing buildings has been brought into focus in AEC/FM due to the huge environmental impact of the existing building stock and the ever increasing user comfort requirements. Extending the building service-life and sustaining the existing stock is considered as a feasible alternative to new construction [35,44]. To this end, there is a need to ensure a building's intended performance and operation during the building service-life by practicing lifecycle building performance assessment (LBPA) through continuous inspections and measurement. We have previously developed a computational reference model named Computational support for Lifecycle Integral Performance Assessment (CLIP-Core) that supports the capturing, structuring and visualization of LBPA information [17]. CLIP-Core, as a reference model, does not address contextual variables and specific functional requirements of a particular setting. When it is being considered for practical use, it needs to be enriched representationally with local concepts and algorithms, and semantically with domain information in external ontologies. As such, CLIP-Core acts as a development accelerator by avoiding repetitive work, thereby reducing the development effort of domain-specific models. We have previously adapted CLIP-Core to two different LBPA domains that adopt different approaches, methods and tools, EPI-CREM (Energy Performance Integration in Public Corporate Real Estate

⁎ Corresponding author at: Middle East Technical University, Faculty of Architecture, Universiteler Mah., Dumlupinar Bulvari, No: 1, 06800 Ankara, Turkey. Tel.: + 90 532 2724408. E-mail addresses: [email protected] (I.G. Dino), [email protected] (R. Stouffs). 1 Tel.: +31 6 3925 0903. 0926-5805/$ – see front matter © 2014 Elsevier B.V. All rights reserved. http://dx.doi.org/10.1016/j.autcon.2013.12.007

Management) and CMU FMS (Carnegie Mellon University Facilities Management Services). EPI-CREM is an EU research project that aims to embed energy-awareness to public and private real estate management processes through long-term maintenance planning. CMU FMS carries out the preventive and corrective maintenance activities of its campus buildings. CLIP-Core was extended and implemented into two domain models and software tools, CLIP EPI-CREM and CLIP-CMU respectively, and tested by its end users. These results of the model adaptation process allowed us to evaluate CLIP-Core. This paper concerns the value of CLIP-Core as a conceptual reference model as it is operationalized through the domain model development processes. In doing so, we first briefly discuss CLIP-Core and the two domain models that adapt it, CLIP EPI-CREM and CLIP-CMU. Then we present the evaluation of CLIP-Core based on these domain models. Finally, we propose guidelines of adaptation for CLIP-Core's future use, and recommend alternative solutions that can increase its usability. 2. CLIP-Core for LBPA 2.1. LBPA and CLIP-Core CLIP-Core is a computational model that supports LBPA, where the primary focus is an existing building's observed/measured behavior in order to maintain building's performance during its service-life. LBPA, as a semantically-rich domain, requires large amounts of information to be processed, stored and shared across various stakeholders. As LBPA practices are typically applied discretely with insufficient or no integration, building information is largely fragmented, leading to redundancy and information overlap. This poses problems regarding efficiency and effectiveness, as process actors have to spend a considerable

I.G. Dino, R. Stouffs / Automation in Construction 40 (2014) 44–59

amount of effort in searching, structuring, processing and translating information [14]. Without seamless information management tools, critical information is lost through ineffective documentation, posing problems for effective decision-making and leading to buildings that are often underperforming [29]. The existing off-the-shelf tools cannot wholly respond to the specific needs of a custom LBPA method due to their broad functional coverage and generic information types. In order to tackle these problems, model-based approaches are essential for building service-life. Representations of up-to-date and accurate building information can increase the quality and performance of LBPA processes, eliminate unnecessary rework at site, and reduce inefficient use of time, resources and labor [1,38,7]. CLIP-Core concerns the development of domain models and software tools that aim to improve the efficiency and quality of existing LBPA practices by capturing, structuring and presenting LBPA information [17]. Modeling for LBPA as a loosely-defined area poses a number of challenges in clearly defining LBPA's operational domain and draw concrete requirements. Moreover, each distinct LBPA process dictates its own domain-specific knowledge, views and conceptual worlds of representations. As the granularity of the problem domain gets coarser, the solution needs to become more abstract and less complete. Generally speaking, a model can address such ill-defined problem areas only on a conceptual level, as a reference model. Reference models address the common functions and information content on a higher level of abstraction, aiming to provide an a priori solution for the future developers to reduce the effort of developing domain-specific models. A reference model is to be reused for different but similar application areas in order to save development time and cost of proprietary domain models [2]. An efficient and correct reference model can lead to higher quality domain models that extend it [37]. CLIP-Core similarly provides high-level computational support for the development of fully-functional domain models supporting context-specific LBPA settings. Moreover, adaptability is a fundamental quality for CLIPCore, facilitating its customization with little effort as compared to build-from-scratch approaches. From a model development perspective, the increased complexity of products, shortened development cycles, and heightened user expectations of quality have created major challenges at all stages of the software life cycle [18]. This poses threats to the quality of the computational tools developed for AEC/FM as large and complex systems. Developing new models and tools for each context is a prohibitively expensive activity. Reference modeling can effectively accelerate the development process, provide a sound basis for system implementation and increase the quality of enterprise-specific domain models. CLIP-Core is a conceptual reference model with a high level of abstraction, containing only basic concepts of LBPA. It contains data structures and algorithms for the representation, transformation and integration of LBPA information during building service-life. When considered to be used in a real LBPA setting, CLIP-Core needs to be customized functionally and representationally into a domain model (Fig. 1). Each domain model needs to be semantically enriched with a reference library of domain-specific objects. A library needs to be developed for each domain model by its domain actors, and codified separately from CLIP-Core. 2.1.1. LBPA and CLIP-Core requirements For LBPA, well-informed decision-making primarily requires a building representation that reflects the as-is building condition and components (Fig. 2, R1). CLIP-Core supports component-based assessment methods in which components undergo periodic inspections and measurements throughout their service life. CLIP-Core formalizes a directed acyclic graph, named the component–topology graph, for the representation of buildings that consist of components, both hierarchically and non-hierarchically. In this graph, the nodes and edges are representationally separated as Component and TopologyRelation,

45

Domain model 1 (CLIP EPI-CREM) Ontology 1 (EPI-CREM ontology)

Domain model 2 (CLIP CMU)

CLIP-Core

Ontology 2 (CMU ontology)

Domain model n Ontology n

Fig. 1. CLIP-Core and its domain models.

together with their subtypes (Fig. 3). Components' descriptors are again represented with a separate object type (PerformanceIndex) capturing static design data that doesn't change by time, or dynamic service-life data such as inspection results. As the building undergoes changes by time, the building representation needs to correspondingly lend itself to changes by the actors through mechanisms that grant dynamic access to this representation's structural schema (Fig. 2, R2). The structural operations during the initial build-up of the component–topology graph and later modifications are supported by a set of algorithms (topology operations) in CLIP-Core. In the build-up of an instance of a building representation, component libraries are typically used. For semantically heterogeneous areas like LBPA, the context dependency and rich-semantics of these libraries is important (Fig. 2, R3). Therefore, each LBPA domain needs to build its own library (an ontology), reflecting its own data views. Ontologies are used for the establishment of a common understanding of the information content, the reuse of this content and the separation of domain knowledge from the operational knowledge [8]. A CLIP ontology can be considered as a top-down a posteriori representation developed by the immediate stakeholders, seeking for information standardization for a specific context. A CLIP ontology specifies only the basic object types of the component–topology graph, being nodes, edges and descriptors. An ontology is physically decoupled from CLIP-Core in an XML file. As it is plugged into CLIP, the model objects are instantiated by CLIP. During inspections, large amounts of time-based data are captured (Fig. 2, R4), which is represented in CLIP-Core by MeasuredValue. MeasuredValue registers all sources of information including manual (inspections), automated (sensors, data loggers) or calculated (using a reasoning routine that operates on available information). When many components are to be inspected at once (i.e. maintenance plans), the AssessmentEvent manages this dataset both representationally and visually. For visualization, CLIP-Core generates hierarchical views for planned activities, and presents a limited view to the relevant components and inspection points. Data analysis for decision-making is the final stage of LBPA. This phase requires specific methods for each context and shows too great variance to be supported by a single model. Therefore, analysis functions need to be developed as part of domain models that extend CLIP-Core. In short, CLIP-Core addresses functions that can be generalized such as data codification, specification and acquisition, while delegating data analysis to domain models for future development. In the following section, we discuss the development of these two domain models and software tools. In Section 4, we will comparatively evaluate CLIP-Core based on the basic requirements discussed here, which are (R1) a building representation, (R2) context-dependent, semantically-rich information content, (R3) capturing time-based data and (4) facilitating structural changes on the building representation.

46

I.G. Dino, R. Stouffs / Automation in Construction 40 (2014) 44–59

Medium of codification (XML...)

R3 LBPA domain information

Knowledge codification F0

As-is building data

R2

Changes over time Update building representation

Libraries, reference data

LBPA data acquisition procedures, tools

analysis and diagnosis methods, reasoning mechanisms

R1 Data specification

Building representation

F1

R4 performance

Performance information data acquisition F2

Data analysis F3

List of actions

Implementation F4

Object manager, Facility manager, ….

Inspectors, sensors, data loggers, calculations …

Performance data analysts,Decisionmakers,Digital tools ...

Technical staff

Fig. 2. LBPA process model, and model requirements (R1, R2, R3 and R4).

2.1.2. CLIP-Core software tool After its development, we implemented the CLIP-Core model in a software tool with Java SE 6, on which the initial testing was carried out. The model development and software implementation for each LBPA domain, EPI-CREM and CMU FMS, were based on the CLIP-Core model and software. In this process, the existing classes and algorithms were reused and extended. 3. CLIP domain models 3.1. CLIP EPI-CREM EPI-CREM is a publicly funded project that aims to improve the existing public building stock's energy performance and rational use of energy by embedding energy measures into the public and corporate Real Estate Management (REM) processes in Europe [30]. A set of methods and tools, including CLIP EPI-CREM, are developed in support of information processing and decision-making activities to facilitate energy improvement through the processes of building maintenance. The method and its evaluation are discussed elsewhere [9]. As the model development team, we got involved in the project while the EPI-CREM method was still under development, and worked under the pressure of completing the software together with the method. The parallel development entailed a great deal of uncertainty in the specification of the model requirements. Therefore we used formal and semi-formal methods of model development. These include the collaborative development of process models with the EPI-CREM partners (as an extension to the generic LBPA functions described above) as a

basis of functional specification and interdisciplinary communication, and software prototyping for testing and development. As a result, we extended CLIP-Core into a domain model and software tool named CLIP EPI-CREM (Fig. 4). CLIP EPI-CREM is an information management system that facilitates the specification and capturing of maintenance information (mostly reusing CLIP-Core), and a decision support system based on a scenario analysis module (a new module that is built upon CLIP-Core). Here we discuss only the functions that have a representational relevance to CLIP-Core so to focus on its potential for reuse. As we got involved in the project, the EPI-CREM ontology was under development by the EPI-CREM partners. Datasheets that are used to define the ontology were regularly being modified during method development. After a change was made, CLIP EPI-CREM internalized it immediately by parsing the new ontology datasheets into XML (Fig. 5). As such, the datasheets acted as the interface between the project partners and CLIP EPI-CREM. In terms of the content, the ontology contains a hierarchical component library named the Standard Element List (SEL), energy performance calculation rules and a risk assessment calculation framework. SEL is a 4-level deep hierarchical component structure (as opposed to a network) that specifies PerformanceIndices for its leaf components. A building representation that is based on SEL is named the Building Elements List (BEL). Representationally, the component–topology graph of CLIP-Core is completely reused for BEL. Standardization and benchmarking between buildings is important for EPICREM, so the BEL needs to be faithful to the ontology at all times. This means the ontology's content and structure are strictly maintained in BEL without allowing customization. During data acquisition, inspection-based information is captured. First, components' energy performance and maintenance condition

I.G. Dino, R. Stouffs / Automation in Construction 40 (2014) 44–59

«enumeration» TopologyRelType +concept_hierarchy +component_decomposition +concept_realization +grouping +versioning +services_to +identical

Static PI

47

Dynamic PI -minValue -maxValue -measuredValue [ ]

MeasuredValue

-behavior

-value -date : Date 1

0..* * 0..*

PerformanceIndex -name : String -description : String -designValue -unit : String -valueType

TopologyRelation -type : TopologyRelType -parent : Component -child : Component -rank : Integer 1

-group

-activity

AssessmentEvent -name : String -description : String -startDate : Date -endDate : Date -budget : Double -values [ ] : Measured Value

0..* 1 ComponentSet

Component

-group

-name : String -description : String 1

*

PhysicalComponent

0..*

-baseComponent : Component -name : String -description : String -subRelationsList [ ] : TopologyRelation

ConceptualComponent

Fig. 3. CLIP-Core class diagram. The objects of the component–topology graph are highlighted in gray. These objects are instantiated using the content of the ontologies.

information, named classification, are calculated by CLIP EPI-CREM based on component information (where 1 is excellent and 6 is very bad). For energy classification, the EPA-C procedure is formalized as energy rules in the ontology, which specifies the conditions determining a component's energy classification (Fig. 6). For maintenance classification, an existing NEN2767-based calculation method is adopted that takes as inputs a component's theoretical lifecycle and age [25]. Following, inspectors register in CLIP EPI-CREM their recommended corrective actions. EPI-CREM aims to shift maintenance investments from conventional maintenance actions (repair and refurbishment) to retrofitting where applicable (i.e. high-performance LED lighting instead of incandescence lighting). Therefore, each action type (repair, refurbish and retrofit) distinguished so that the inspectors can select the appropriate actions considering the information previously captured in CLIP EPI-CREM. As an action type is recommended, inspectors also need to determine a new classification value to which the component will improve, and calculate the risks a component currently carries so to set priority values to actions. For the classification information, we reuse the existing MeasuredValue object type and extend it with additional attributes, such that one instance holds multiple values generated at different times during the inspection: calculatedValue is the result of the initial CLIP EPI-CREM calculation; inspectedValue is registered if inspectors feel the need to correct the calculatedValue, and recommendedValue is the predicted value after the corrective actions are taken. As such, MeasuredValue reflects the different forms this information takes during the course of an inspection (Fig. 7). To present inspection information to the strategic REM level, EPICREM customizes the NEN2767 data aggregation method [25] that presents an equalization procedure that calculates an aggregate

classification information on upper BEL levels. This aggregate information presents an overall quantitative view of the building's condition, calculating the condition of a parent component by taking the weighted average (using component cost information) of the sibling components. For CLIP EPI-CREM, the data aggregation function and its visualization uses a depth-first traversal algorithm, which recursively calculates and displays component classification values starting from the leaf nodes of the component–topology graph, moving up to the parent nodes with post-order and pre-order traversal algorithms respectively. As such, each level of the graph is populated with aggregated classification and cost information. Data analysis involves the processing of the generated building information towards maintenance planning, named scenario analysis. A scenario is a list of actions that are selected amongst the whole set of previously recommended Actions. Scenarios are generated as the technical advisors select a number of actions while prioritizing those with high risk and low classification. CLIP EPI-CREM builds a separate hierarchical representation similar to BEL, named BEL-Scenario, populates it with the information linked to the Actions, and aggregates the classification and cost information. As such, a scenario can be placed next to BEL or other scenarios to facilitate a comparison based on performance improvement and cost on every building level. Eventually, a scenario is selected and the actions contained within are implemented. The EPI-CREM method and tools were tested in 20 non-residential buildings, in which the assessment method, tools (including but not limited to CLIP EPI-CREM) and the level of organizational adaptation is evaluated [23]. Testing was performed by the project partners: Dutch Government Building Agency and the Ministry of Defense in The Netherlands, energie:bewusst Kärnten, Austrian Energy Agency and

48

I.G. Dino, R. Stouffs / Automation in Construction 40 (2014) 44–59

Objects from the Ontology

LibTopologyRelation

Model Objects

«utility» CLIP_TopologyOperations

TopologyRelation

1

1 LibComponent

Component

LibRisk

Defect

Action

AssessmentEvent

ActionSet

Risk

Scenario

EnergyRule

SingleStatement BldgSHEEQdashboard

Statement

EPI-CREM extension

LibDefect

MeasuredValue

PerformanceIndex

CLIP-Core

LibPerformanceIndex

CompositeStatement «utility» EPI-CREMAlgorithms ImpactCriteria-SHEEQdashboard

Fig. 4. CLIP EPI-CREM class diagram.

Austrian Railways in Austria, and Centre Scientifique et Technique du Bâtiment in France. The testing process started with the training of the inspectors, after which the EPI-CREM approach was implemented within the Real Estate Management of the participating buildings with real data extracted from the existing documentation. The earlier phases of the method and relevant tools, including SEL, energy and maintenance condition calculation, were tested thoroughly, while the evaluation of the later stages of maintenance scenario arrestment remained less rigorous. Nevertheless, it is important the stress that this paper concerns CLIP-Core, and the evaluation results of the EPI-CREM method itself has no effect on the evaluation of CLIP-Core.

3.2. CLIP-CMU Carnegie Mellon University's Facilities Management Services (CMU FMS) carries out routine corrective and preventive maintenance activities on the campus facilities. At CMU FMS, an up-to-date building documentation is crucial for lifecycle decision-making, especially run to failure activities. The maintenance processes, especially asset management and maintenance planning, were already being supported by a commercial computer-aided facility management software tool. However, there were reported inefficiencies in these processes, which we specifically addressed in CLIP-CMU. We developed CLIP-CMU by extending CLIP-Core, enriching it with necessary object types, and a new module named CLIP-Traceability. The initial development efforts of

CLIP-CMU can be found elsewhere [17]. Here, we present an extended discussion on the eventual model. We tested CLIP-CMU in a campus building that has strict indoor air quality requirements due to the rare and historic books and art pieces it houses. The building went through several modifications due to equipment problems after its start-up. These maintenance events, as discussed below, acted as test cases for the evaluation of the model and its topology operations.

3.2.1. Data specification and codification In its ontology, CMU FMS prefers to maintain only the space hierarchy of the campus (the campus N campus zones N subzones N buildings N building floors N building spaces). A building representation takes this hierarchy and appends to it a hierarchy of the HVAC components in composition relationships (component N subcomponent N sub-subcomponent). Correspondingly, the component–topology graph is also composed of two layers: the space hierarchy at the upper levels and the physical components hierarchy at the lower level. For the test building, we built a component–topology graph using both the ontology for spaces component information for HVAC Components and their PerformanceIndices. The connectivity of the HVAC system gave us the opportunity to model the non-hierarchical relationships between spatial and HVAC components. To further test how efficiently CLIP can support maintenance changes made in the building, we applied the topology operations to a

I.G. Dino, R. Stouffs / Automation in Construction 40 (2014) 44–59

49

178 escalator MECHANICAL element 8 10 33 20 ... 106 CONCEPT_HIERARCHY 106 49 ... 21 thermal conduction coefficient U SPECIFICATION 92 93 104 W/m2.K physics DOUBLE Fig. 5. A partial view from the EPI-CREM ontology of the components, topology relations and performance indices.

previous maintenance event (ME1) that prompted various actions of measurement, inspection and corrections. Maintenance Event 1 (ME1):

documentation of this history, the VAV box seems as a redundant component; while in fact it functions as a secondary element to be used when necessary.

ME 1.1. Shortly after the building start-up, the FMS received complaints regarding the humidity levels fluctuating in the vault room. ME 1.2. The FMS concluded that the central AHU and the humidifier cannot meet the strict humidity specifications of the vault. ME 1.3. Humidification operating at strict set points is very costly, and thus should be applied sparingly on the spaces that truly require it. Thus, the FMS decided to separate the vault HVAC system from the rest of the building by installing a separate piece of equipment designed for precision cooling system for humidity control and air filtration. ME 1.4. As a result, the VAV box that is connected to the central system remained as an auxiliary component to be used when the new precision cooling system is nonoperational. With the lack of the

To reflect these changes we first appended a new precision cooling unit and its subcomponents to the vault, removed the servicing link between the vault and the VAV box, created a new servicing link between the vault and the precision cooling unit and, finally, created a link between the precision cooling unit and the VAV box of type versioning. As a result, the updated component representation allowed us to evaluate the graph's capacity to dynamically modify itself to capture the as-is building topology (Fig. 8). ME1 will be revisited below, in relation to CLIP-Traceability. Moreover, to capture the rich-semantics of the maintenance activities and information content, we extended the PerformanceIndex class into five subclasses: Requirement (indicators that cannot be expressed in metrics) and Specification (numeric design information) as

facade, floor, roof insulation

1

2

3

4

5

6

Rc >= 4,0 [m2K/W]

4,0 > Rc >= 3,0 [m2K/W]

3,0 > Rc >= 2,0 [m2K/W]

2,0 > Rc >= 1,0 [m2K/W]

1,0 > Rc > 0 [m2K/W]

no insulation

insulation >= 150 mm

150 mm > insulation >= 110 mm

110 mm > insulation >= 70 mm

70 > insulation >= 20 mm

20 mm > insulation

YoC > 20002008

2000 >= YoC 1995 >= YoC 1982 >= YoC 1975 >= YoCr > 1995> 1982 > 1975

Fig. 6. Energy rules of an insulation component, where the input parameters are PerformanceIndices.

50

I.G. Dino, R. Stouffs / Automation in Construction 40 (2014) 44–59

Condition value : MeasuredValue

Condition classification : Performance Index

calculatedValue : double = 5 inspectedValue : double = 4 realizedValue : double = 3

name = Condition classification thresholdValue : int = 3

Event : Assessment Event

Energy value : MeasuredValue

Energy classification : Performance Index

date = 15/12/2009 name : string = EPI-CREM asst budget : double = 400000

calculatedValue : double = 2 inspectedValue : double = 2 realizedValue : double

name = Energy classification thresholdValue : int = 4

Fig. 7. The object diagram of an example element, showing the extended MeasuredValue object types.

static and Measurement (numeric measurement information), Inspection (observed condition) and Correction (expressing actions of modification) as dynamic PerformanceIndices (Fig. 9). The Correction object type is used when a planned or ad-hoc modification action is made (changing belts, lubricating moving parts, etc.). These subclasses also reflect the order in which each type is generated during building lifecycle: the requirement, specification and measurement types that are specified in the design phases, and the measurement, inspection and correction types that specify activities during building service-life. This ordering reflects on CLIP-Traceability rules, which structure the relationships between these indicators and facilitates their reasoning (see the next section). 3.2.2. CLIP-Traceability CLIP-Traceability is a module under CLIP-CMU that is motivated by the fact that an information environment's broad scope in time and breadth hinders the participants' access of project information beyond the current phase and activity area [41]. The lack of a representation

that reflects the time dimension disguises the motivation behind past maintenance actions and hinders well-informed decisions being taken. CLIP-Core's existing component–topology graph reflects the static building condition, but fails to capture the events and changes that take place over time. CLIP-Traceability allows the restructuring of the existing information in CLIP-CMU with a topological structure so to allow for tracing the actions taken during a maintenance activity. A traceability structure can document a history of events as a reference for future maintenance activities, linking designs to justifications, important decisions, and assumptions and contexts in which design solutions are arrived at. CLIP-Traceability formalizes a directed graph structure with nodes of PerformanceIndex objects and edges of a new object type named TraceabilityRelation (Fig. 10). A TraceabilityRelation captures different types of relationships such as refinement (when early design information leads to detailed information during design), trigger (when a maintenance action triggers another during building service-life) or feedback (when there is a need to ensure a corrective

South lobby Holding kitchen

Restrooms EZB Zones 1-5 POSCTR

Conference room B Conference room A

POSCTR-1Floor

VAV-1 Humidifier

VAV-2

Zones 6-10 Technical room

South lobby Lounge

Return fan

Reading room AHU North lobby

Supply fan

VAV-9

Main AHU duct Book vault

Reading room damper

VAV-9 return duct

HIERARCHICAL EDGES Concept hierarchy Component decomposition

Pressure control Vault damper

NON-HIERARCHICAL EDGES

VAV-10 Fan Precision cooling

VAV-10 return duct

Services to Connected to

Humidifier

Replaces Located in

Air cooled condensing unit

Filter Compressor

Fig. 8. A partial view of the graph, visualized hierarchically (left) and nonhierarchically (right) (visualized in Prefuse).

Identical

I.G. Dino, R. Stouffs / Automation in Construction 40 (2014) 44–59

51

Performance Index -name : String -description : String -designValue -unit : String -valueType

Static PI

Dynamic PI -minValue -maxValue

Requirement

Specification

Measurement

Inspection

Correction

Fig. 9. The extended PerformanceIndex object type.

action has taken effect by backtracking it to its initial requirement). Consequently, a TraceabilityRelation poses constraints on the PerformanceIndex subclasses for parent–child relationships (Fig. 11). For example, two static PerformanceIndex instances can only be linked with the refinement type, or the link between two Measurement type PerformanceIndex instances can be of type refinement or trigger. We tested CLIP-Traceability with two previous maintenance events, ME2 and ME3, which took place after ME1. Afterwards we built corresponding traceability graphs and evaluated together with the FMS staff the extent to which they can represent the flow of actions. Maintenance Event 2 (ME2): ME 2.1. The Building Automation System (BAS) gave an alarm for a fluctuating humidity level in the vault room. ME 2.2. As the historic books in the vault are sensitive to moisture, the FMS immediately created a work order to inspect:

ME 2.3. The inspection of the humidifier passed the test. However, they found that the return duct of the VAV unit in the vault room (Fig. 12, point B), which is supposed to be nonoperational after the installment of the precision cooling unit, was left open and still sucking air into the main ventilation system. Due to the low pressure in the vault room, there was undesirable infiltration into the vault room through the wall that the return duct and supply duct of the newly installed precision cooling unit (see ME1) are passing (Fig. 12, point A). ME 2.4. The gap on the wall (point A) was closed to circumvent the infiltration into the vault room. ME 2.5. The return duct of the vault room (point B) was blocked by plastic to circumvent the air leak out from the vault. ME 2.6. The humidity level in the vault room stabilized, and the work order was closed. Maintenance Event 3 (ME3): ME 3.1. Shortly after ME2, the FMS received complaints regarding the reading room, located next to the vault, about excessive noise coming from the return duct.

a) the humidifier b) the vault room's infiltration.

Parent PerformanceIndex

* «enumeration» TraceRelType +refinement +trigger +feedback

TraceabilityRelation

1

-relType : TraceRelType -ranking : Integer

* 1 TraceabillityLayer -traceLayers[] : TraceabilityRelation

Fig. 10. A partial view of the CLIP-Traceability class diagram.

Child PerformanceIndex

PerformanceIndex

R S R S M I C

M I

C

r

r

r

r

r

r

r

r

r,t

t

f

t

t

f

t

t

Fig. 11. Traceability graph constraints (r = refinement, t = trigger, f = feedback).

52

I.G. Dino, R. Stouffs / Automation in Construction 40 (2014) 44–59

Reading room

Technical room

Vault room

A

Return duct

Return duct

B

Precision cooling Humidifier

C AHU

D

VAV-9

VAV-10

Return duct Supply duct Nonoperational duct Fig. 12. A schematic plan drawing of the test building.

ME 3.2. FMS measures the airflow rate of the main return duct of the reading room and the vault room (Fig. 12, point D) as 400 CFM. The design value is also 400 CFM. ME 3.3. FMS then measures the airflow rate of the return duct of the reading room only (Fig. 12, point C), whose design value is 100 CFM, whereas the measured value was 400 CFM. The FMS identified the overloading of this return duct as the source of the noise problem. However, the reason of this overloading in the duct was not immediately apparent. ME 3.4. After exhaustive visual inspections, it was found out that the return duct of the vault room was previously blocked (during ME2.5), which was causing the over-pressurization of the shared duct. This action was never documented, and therefore was not visible to the FMS during this inspection. ME 3.5. To remedy the situation, two dampers were installed; one for the vault room return duct and one for the reading room return duct. While the first damper was set to %0 open, the second was set to %25, reducing the air flow from 400 to 100 CFM. Consequently, the plastic blockage was removed (Fig. 13). ME 3.6. The return ducts air flow rates of both rooms (point C and B), and the main duct (point D) were measured. ME 3.7. The work order was closed as the sound in the reading room disappeared.

B

4. Evaluation of CLIP-Core As a reference model, CLIP-Core does not interface with the end users directly, but only through a domain model. Therefore, evaluating such a reference model involves two different steps (Fig. 15). The first

B 300 CFM

C

ME2 and ME3 demonstrate the maintenance problems that arise due to poor documentation of past maintenance work. Here, with a proper documentation of ME1 and ME2 that is made accessible for ME3, the amount of maintenance time spent for diagnosis could significantly be reduced. We tested CLIP-Traceability's potential in increasing the efficiency of maintenance decision-making. We represent each event, ME2 and ME3, with a separate traceability graph and create a PerformanceIndex for each discrete maintenance action (Fig. 14). In the graphs, each (dynamic) PerformanceIndex has a trigger link from parent node, and each Correction links to the root PerformanceIndex with a feedback link. Each graph loops from the initiation of the work order to the concluding action. In the end, the FMS staff confirmed that during ME3, if the traceability graph of ME2 was made available to FMS, the root of the problem could be easily recognized without further inspecting the whole HVAC system. CLIP-Traceability demonstrated that a graph has the potential to capture and document time-based information on multiple components.

100 CFM

B 0 CFM

C 100 CFM 400 CFM

C

%0

0 CFM

100 CFM %25

D

D

D

400 CFM

400 CFM

400 CFM

Design

Modification 1

Modification 2

(before ME 2.1)

(after ME 2.4)

(after ME 3.5)

Fig. 13. The design and modified settings of the supply ducts during ME2 and ME3: the design setting and the two steps of modifications.

I.G. Dino, R. Stouffs / Automation in Construction 40 (2014) 44–59 Vault humidity fluctuating complaint

53

Reading room duct noise complaint

2.2a Hoses and fitting are tight Humidifier

2.1 Relative humidity Book vault

2.5

Excessive duct noise Reading room

2.4

Close duct by plastic VAV-10 return duct

Close precision-cooling duct gap on wall Book vault

2.2b

2.3

3.1

3.2

No leaks on walls Book vault

inspect VAV-10 return duct

3.1

CFM VAV-9 return duct

No in-leaks Book vault

No out-leaks Book vault

3.5

2.3

CFM Main AHU duct

Not obstructed Main return duct

Set position to 25% Reading room damper

2.3

3.6

3.4

3.5 2.3

CFM Main AHU duct

3.6

Install two dampers Main AHU duct

CFM VAV-10 return duct

3.5

CFM VAV-10 return duct

3.5

Remove plastic VAV-10 return duct

Set position to 0% Vault damper

Fig. 14. CLIP-Traceability graphs of ME2 (left) and ME3 (right).

evaluation focuses on the two domain models that extend CLIP-Core, and their fittingness to their contextual requirements, as previously presented. This assessment was made in collaboration with the domain actors and was based on their feedback on the software tool. This section concerns the second evaluation, focusing on CLIP-Core's adaptation process into domain model models. 4.1. A requirements-based evaluation Models and frameworks that are developed to support the modeling of complex systems and processes in AEC/FM have received much attention lately. The aim of conceptual building models is the formal description of the products and processes through its lifecycle phases. Our approach in CLIP-Core was to provide a conceptual model to software developers with several computational constructs so to establish the basic LBPA concepts and ease the development effort. Previously in Section 2.1.1, we have identified the requirements that computational tools in support of LBPA should satisfy. In this section we revisit these requirements to evaluate CLIP-Core and make a comparative analysis with the existing models that have similar motivations. 4.1.1. Requirement 1: A building representation As LBPA primarily operates on an as-is representation of a building, its accuracy and currentness are the basis of well-informed lifecycle

decisions. CLIP-Core formalizes this representation with a directed graph. In AEC/FM and planning, graph theory is widely used for various purposes such as the representation and analysis of spatial/urban topology [50,51,52], modeling of products, processes and dependencies [53,54], and design analysis [55,56]. CLIP-Core's directed graph facilitates the representation both hierarchical and non-hierarchical structures with arbitrary levels of granularity, and lends itself to efficient traversal and querying of the building topology, as in the case of data aggregation in EPI-CREM that calculates the component classification values through the hierarchical links, or the network topology of the HVAC components at CMU. However, this formalism may fail to fittingly describe systems wherein building components cannot be identified discretely in decomposition relationships. The problem of a structured building representation resulted in many development efforts in the area, which aimed at the definition of a conceptual schema as well as the building data. The current standardization initiatives focus on neutral product models such as Industry Foundation Classes (IFC) for AEC/FM [20], or dictionaries such as ISO 15926 for process plants. Both formalisms contain a semantically-rich representation on different levels of abstraction. Their most abstract level (IFC's Kernel and ISO 15926–2 conceptual model) defines general concept categories that are comparable to CLIP-Core, and lower levels define domain objects (IFC Domain and ISO 15926–4 Reference Data) that are comparable to CLIP ontologies. However, the function of these Detailed requirements

High-level requirements 2nd level evaluation: Adaptation

CLIP Core

iterative prototyping

Domain models

test and refine

LBPA processes Fig. 15. Levels of evaluation for CLIP and its domain models.

1st level evaluation: Use

54

I.G. Dino, R. Stouffs / Automation in Construction 40 (2014) 44–59

formalisms is merely data mapping and cannot be directly developed into software tools. Other limitations against the use of a standard model in CLIP-Core include model rigidity and their inability to accommodate schematic changes (see the next requirement). Reference models, in contrast, support that all models are subjective interpretations of a context, and don't have universal truth values. They capture domain concepts on a low level of abstraction so to allow further development and customization. Several conceptual models that allow a flexible building representation similar to CLIP-Core have been developed [15,47,46,19,31,40], which we will discuss in the context of the following model requirements. 4.1.2. Requirement 2: Rich contextual semantics To be able to support a broad range of LBPA practices, CLIP needs to address the information needs of each context with flexibility, while reassuring the strategic role of standard reference descriptions. We support the argument that one single representation cannot capture the whole range of domain information in areas wherein information is diverse and biased towards local perspectives [27,45,42], such as LBPA. Therefore, domain-specific information is captured in ontologies that are physically decoupled from CLIP-Core. The externalization of information allows isolating the volatile domain knowledge within ontologies. As such, the modification of each side remains independent of each other. At the same time, the ontologies and the model gain immunity to the changes in each other concerning the description of relevant data. This proved to be most useful in the EPI-CREM ontology, where encapsulation of the changing domain information in ontologies allowed us to develop CLIP EPI-CREM in parallel with the EPI-CREM project. Moreover, other types of semantic content were captured in the EPI-CREM ontology, such as the energy calculation rules. As such, ontologies proved to be effective in the representation both data structures and procedures. However, it is important to note that without an interpreter (CLIP-Core) that understands and operationalizes the content of it, ontologies are static structures that only have representational value.

The need for a structured and comprehensive description of shared building objects calls into question the potential role that the existing building information models could play in the development of CLIPCore. Such top-down a priori models impose a rigorous level of formalism to represent product information for data interoperability. In terms of their motivation, CLIP ontologies are similar to these models, as they strive to integrate the information content in a single representation. However, a comparative study of IFC, EPI-CREM and CMU ontologies based on a shared element, a VAV-box, reveals important structural and semantic differences between these models. In IFC, entities are mainly organized in an inheritance hierarchy. Despite having advantages such as avoiding redundant data definition and enforcing standards, deep inheritance relationships make the definition, consistency and understanding of sub-classes increasingly difficult, and challenge a model's overall integrity. This is a problematic situation for CLIP-Core, where frequent modifications on ontologies are under consideration, and a change in a superclass can uncontrollably propagate through inheritance relationships. Therefore CLIP ontologies avoid inheritance by restricting component descriptions only to their own classes. Another setback is the difficulty in matching the component information in models. Although IFC property sets and relationships cover most of the CLIP ontologies' PerformanceIndices and TopologyRelations, these are not easy to locate as they are inherited from objects scattered throughout the hierarchy. For example the “serial date” property in SEL can be mapped to the SerialNumber property of IfcElement that is four levels higher in the hierarchy (Fig. 16a). Likewise, semantic ambiguities may complicate a possible mapping between models. For example, IFC's “AirflowRateRange” has possible mappings to “air flow”, “cooling airflow” and “heating airflow” in the CMU ontology (Fig. 16b). Spatial relationships in IFC are handled by a separate relationship type “IfcRelContainedInSpatialStructure”, while SEL captures this information type in PerformanceIndices (Fig. 16c). The VAV-box components in SEL and CMU ontologies can only be mapped to two enumerations of the IfcAirTerminalBox (Fig. 16d). Such ambiguous

Fig. 16. A comparative study of IFC, EPI-CREM SEL and CMU ontologies. The data types that cannot be mapped are in gray color.

I.G. Dino, R. Stouffs / Automation in Construction 40 (2014) 44–59

situations make the comprehension and use of standard models difficult especially for the domain actors that develop a CLIP ontology, who are not necessarily familiar with building information modeling. The fact that standard models are constantly evolving in terms of content and structure is also posing challenges to maintaining mappings with domain models [3]. Every time a standard undergoes an update, the software tolls implementing it need to readjust their internal schema accordingly. Therefore we argue that commitment to an existing model, especially if its scale and complexity are high, should be avoided if interoperability is not a primary concern. Several existing conceptual models handle contextual data either by delegating it to end users to manually create and manipulate it. Especially in the field design, the dependence of a designer on standards is contradicting to the creative and explorative act of design. A gradually refined, adaptable design representation and the extensibility of schemas are characteristics of models that address design processes, such as [40,46,47]. Here, existing standards are completely eliminated and design data is created and structured in a bottom-up a posterior way. However, the creation and management of a representation from scratch doesn't have much advantage outside design, as adherence to a local standard (such as CLIP ontologies) outweighs the creative freedom in LBPA. An alternative approach to use contextual information is to derive it from other software tools that are being used. Howard et al. develops a methodology to assemble composite objects from primitive parts, where data is derived from external applications that will exchange data [19]. Papamichael makes use of available databases and computer simulation programs in the development of a software environment that assists design decisions. While similar data mapping mechanisms can be additionally used to enrich the semantics of CLIPCore in the future (see Section 4.3), this cannot replace the use of ontologies. Contextual information management is addressed by various technologies such as the Web Ontology Language (OWL) to internalize multiple shared ontologies [6], description logic to create a single ontology that provides views for multiple contexts [4], distributed description logics (DDL) to describe constraints guiding the correspondences between multiple ontologies within a context [26], or modal logic to define the trustworthiness of concepts in different contexts [49]. These approaches either fail to tackle the problem of the use of disjoint plug-in ontologies to be linked to computational models, or are too complex to be used by the domain actors. Our approach is to allow LBPA actors develop their simple hierarchical views, and then parse these into formal ontologies in computer-readable format. Nevertheless, the mentioned technologies have potentials to improve CLIP ontologies in the future (Section 4.4). 4.1.3. Requirement 3: Capturing time-based data during building lifecycle The data captured during LBPA (i.e. during inspections) need to be captured as linked to the building representation. This timedependent information is represented by MeasuredValue as a generic object type, and can act as a basis to which other related object types be linked. CLIP EPI-CREM especially significantly extended it with new object types, rules and algorithms of classification calculation, risk assessment, or Actions that capture corrective activities. In CMU FMS, time-based data acquisition was tested through maintenance events, wherein the design and inspection data were derived from building documentation, job plans and computer aided facility management tools that are being used. Moreover, the activities were dealt by not new object types but the traceability graph, which captured the order of maintenance events that trigger one another. Capture of time-based data is a general concern for processes wherein there is a need to represent information on processes, or information that is changing over time. Models that address building lifecycle prioritize this information type and link it to relating concepts such as actors, resources, tools, etc. [15,20]. However, conceptual models that we

55

mentioned above address design and therefore don't usually capture lifecycle data. Commercial asset management tools contain this function, but don't satisfy the other model requirements that we propose. 4.1.4. Requirement 4: Dynamic access to the building representation's structure In AEC/FM, concepts involving interaction, coordination, and decision-making need to be captured through process-centric representations of dynamic product descriptions and life-cycle processes [24,34]. Similarly in LBPA, a building representation is built up and kept up-todate with graph algorithms named topology operations in CLIP-Core. The component–topology graph facilitated the querying and calculations on the graph for several functions with its traversal algorithms. For CLIP EPI-CREM, the data aggregation function and its visualization was based on a depth-first traversal algorithm, which calculates classification values and displays component information recursively with post-order and pre-order traversal respectively. CLIP-CMU demonstrated how the topology operations can keep the building representation up-to-date as an evolving network-type structure. We further implemented a separate graph and operations for CLIP-Traceability to augment the static building representation by adding a time dimension to the components' description. Here, the component graph captures a static snapshot of one state of a building, whereas the traceability graph captures the transitions between two or more states. CLIPTraceability effectively conveyed information on the temporal interdependencies between processes, and the flow of changes triggering each other. Topology operations are modular standalone algorithms; therefore an existing operation can be modified, deactivated, or a new one can be plugged in provided that it does not violate the graph's structural integrity. Several modifications were made in the form of rules and structural constraints in EPI-CREM, where the depth of the ontology and the corresponding graph has to be strictly four levels. As a result, the topology operations were limited to the fourth-level components, and ensured that no leftover leaves on the in-between levels remained after deleting a node. The explorative and evolutionary nature of design necessitates a similar modeling approach that allows the design information to be structurally modified during design so to allow dynamic design representations [40,46,47]. However, these models operate on design concepts, not building components. For the design of product families, Sudarsan et al. develop a product information-modeling framework that represents the design evolution of product families, but doesn't implement procedures for change [43]. Eastman et al., proposes an approach to manage design constraints that allows model evolution based on writable views associated with each application [10]. Howard et al. allows different tools to build their own complex abstractions a posteriori for data exchange from a different perspective based on form–function–behavior perspective [19]. In contrast, CLIP-Core's topology operations are for processes that adopt a top-down building definition, where the building is decomposed into its subcomponents at the lower levels. Alternatively, a building can be defined from bottom-up starting with the most specific building elements, then categorizing these into more general entities. In this case, additional topology operations that facilitate the bottom-up development of a graph need to be developed. 4.2. Reusability of CLIP-Core In this section, we evaluate the role of CLIP-Core in the development of its domain models, and the degree to which its domain models are founded on CLIP-Core. As a reference model, the quality of CLIP-Core is directly related to the ease with which it lends itself to reuse within environments other than those which it was designed for. To quantify the extent of its reuse while developing domain models, we first need metrics that are relevant and easy to acquire.

The number of unique operators, operands, the total number of operators and operands

Control-flow complexity

Size-based approaches (see above) Cyclomatic complexity : quantifies the control flow complexity through the number of linearly independent paths in a program Halstead's complexity measures [11]: quantifies program components to assess program length, volume, difficult, effort Information flow complexity [23] Coupling (see above) Analysis of the control graph of the program (see Cyclomatic complexity above) Algorithmic complexity

Total number of edges (e), vertices (v) and cohesion components (c) in the control graph. Evaluated by the formula V(G) = e − n + 2p

Afferent coupling (fan-in or the average number of modules calling a module) and efferent coupling (fan-out or the average number of modules called by a module) [23,35] Coupling

The amount of business functionality Software that is composed of small and well isolated chunks of code The degree of dependency between modules Functionality Modularity Structure

Description

The amount of code

Metric name

Size Size

Table 1 A classification of code-based software metrics. The metrics that we used for evaluation are underlined.

Data required

I.G. Dino, R. Stouffs / Automation in Construction 40 (2014) 44–59 Logical lines of code (LLOC), number of lexical tokens, number of attributes, classes, methods [4], complexity Number of function points [4] Coupling (below) and cohesion

56

Fenton and Neil [12] propose a classification of software measurement activities from the perspectives of resources (development team, organization etc.), processes (phases of development etc.) and products (specifications, designs, code, test data etc.). Related to the context and the process in which the software was implemented, the former two perspectives require a controlled development process. However, the software development processes of CLIP-Core and its domain models (spanning almost two years) was mainly explorative rather than goaldirected. Therefore metrics such as development time, effort, number of requirements changes, number of faults etc. cannot truthfully contribute to our comparative analysis. Therefore we adopted a productbased perspective that focuses on the artifacts of the development process. As the models are too abstract and unsuitable for quantifying, we used software (source code) metrics of the three models. Here, it is important to stress that CLIP-Core's source code remained largely intact while it was being extended for its domain software (except for a negligible portion of the topology operations). Moreover, the core and reference models and software tools are developed by the same team with the same modeling methodology and programming language. Jones argues that software metrics in isolation cannot reliably be used to evaluate software products [22]. On the other hand, metrics can facilitate an objective comparative evaluation when they are used for benchmarking between software tools [48]. Frakes and Terry similarly propose a simple benchmarking method based on a formula that quantifies the ratio of the amount of life cycle objects reused to the total size of life cycle objects [13]. We adopt this approach in our evaluation with the claim that the percentage of code reuse can proportionally indicate reference model reuse. Table 1 summarizes the main categories of software metric types, amongst which we use only the logical lines of code (LLOC) and cyclomatic complexity (CC) metrics. This is because these metrics can be assumed to increase linearly during model evolution, and can therefore provide a basis for benchmarking. We use Eclipse's Metrics plugin to quantify LLOC and CC in the source codes of CLIP-Core, CLIP-CMU and CLIP EPI-CREM, with their main model classes and supporting classes (Table 2). We then benchmark the metrics of the domain models' software against CLIP-Core. The aggregated results show that CLIPCore was extended with 158% and 159% increase for CLIP CPI-CREM and 26% and 31% increase for CLIP-CMU regarding CC and LLOC respectively (Table 1, row VV). When model classes are considered, the class size increased significantly. In CLIP EPI-CREM, Component (100% and 107%), LibComponent (61% and 45%) and MeasuredValue (60% and 45%) were both reused and extended with new data types, while this extension reflects on the helper classes that contain static datasets (such as EnumHolder (0% and 1206%)) or handle graph algorithms and database connections (such as DBHandler (89% and 95%) and XMLHelper (82% and 130%)). In CLIP-CMU, we observe a less drastic size increase both in model classes (row L) and in total, as the ontology content and calculation algorithms were considerably lighter. We will extend upon an alternative perspective proposed by Matook et al. that discusses the relationships between reference models characteristics (Fig. 17) [28]. According to them, flexibility is a necessary feature of reference models, as they are subject to evolution and modification in order to respond to changes in the domain they address. The lack of flexibility requires serious compromises during adaptation, which reduces the model's potential application area. CLIP-Core has two levels of flexibility, semantic and functional. Semantic flexibility is acquired by externalizing domain knowledge in ontologies. Functional flexibility is acquired by increasing the level of representational abstraction, and pulling the functional scope of the model to the functional primitives of LBPA. This has an effect on other qualities such as generality (the ability to address a wide range of contexts), completeness (the degree to which the model covers domain concepts) and correctness (model's degree of accuracy in representing the domain concepts). An over-specified model contains too many assumptions that diminish its relevance to a wide range of contexts, which can even endanger

I.G. Dino, R. Stouffs / Automation in Construction 40 (2014) 44–59 Table 2 The results of size-based metrics. The classes in bold text in column A are CLIP-Core domain object classes, and the bold gray text is CLIP-Core helper classes.

% growth

LLOC

% growth

CC

% growth

LLOC

% growth

126

58

132

282

124

25

0

126

0

B

Comp

14

43

15

7

49

14

14

0

43

0

C

Component

54

281

108

100

581

107

76

41

382

36

D

ComponentSet

40

170

0

0

-100

40

0

170

0

E

LibComponent

46

224

74

61

324

45

50

9

244

9

F

LibPerformanceIndex

39

189

61

56

276

46

43

10

215

14

G

LibTopologyRelation

54

230

59

9

254

10

59

9

254

10

H

MeasuredValue

30

149

48

60

216

45

30

0

149

0

I

PerformanceIndex

73

360

118

62

519

44

75

3

372

3

J

TopologyRelation

52

234

65

25

293

25

64

23

289

24

K

TopRef

6

22

18

200

51

132

9

50

30

36 12

CLIP-Core EPI-CREM

CC

LLOC

25

433

2028

624

44

2845

40

485

12

2274

M

CompMutableTreeNode

5

21

5

0

21

0

5

0

21

0

N

EnumHolder

0

17

0

0

222

1206

0

0

31

82

O

DBHandler

56

518

106

89

1010

95

59

5

620

20

P

TopologyRepository

73

222

51

-30

161

-27

73

0

222

0

Subtotal:

L

Q

XMLHelper

22

150

40

82

345

130

22

0

191

27

R

UnifiedTreeModel

97

494

116

20

598

21

119

23

600

21

S

Portfolio

18

89

T

Building

12

54

U

VirtualBuilding

0

6

W

Dashboard

0

7

Y

Rule

20

104

Z

Statement

7

31

AA

SingleStatement

11

69

BB

CompositeStatement

15

81

CC

Defect

34

121

DD

LibDefect

18

87

EE

Action

55

273

FF

ActionSet

52

251

GG

Propagation

179

670

HH

Risk

14

61

II

Scenario

49

278

JJ

Utility (package)

37

179

KK

XMLParser

19

96

LL

ComponentRepository

MM EnergyClassificationWrapper NN Util

1

7

110

445

112

519

OO

PropagationHashmap

12

90

PP

PropagationData

22

80

QQ

CalculationHelper

16

100

RR

MaintClassificationWrapper

14

50

SS TT UU

TraceabilityLayer TraceabilityNetwork TraceabilityRelation Total sum:

VV

686

3450

1769

158

8950

(Complexility)

-

CLIP-CMU

AssessmentEvent

A

CMU

EPI-CREM

CC

CLIP-Core

57

Flexibility

-

+

Completeness

-

Generality

Correctness Fig. 17. A framework to evaluate the quality of reference models (extended from [28]).

159

44 28 32 867

26

229 170 159 4517

31

correctness. On the other hand, when under-specified, missing concepts in the model can lead to a lack of expressiveness in terms of conceptual patterns, which negatively affects completeness [32]. A model with a high level of generality can be easily adapted to address the unanticipated changes and requirements. Therefore, generality and flexibility as model qualities usually go hand in hand. For CLIP-Core, total completeness is not a desired goal, as it will result in an overloaded model that loses its generality and correctness. Where we aim to achieve completeness is not CLIP-Core, but its domain models, which can be said to be complete for the context they specifically address. On the other hand, CLIP-Core can be refined further over time as we tailor it to other contexts and identify repeating concepts that might be added to the model. This process is a continuous search for recurring patterns, which will allow CLIP-Core to evolve towards a richer model. 4.3. Guidelines for reusing CLIP-Core While developing a domain model, a series of translations and tradeoffs need to be made to reuse CLIP-Core. Adding new concepts, either by introducing new classes, sub-classes or enriching the existing objects is a fairly safe transformation, provided that the existing algorithms can handle the new concepts. Extension through sub-classes

was easily achieved on the static and dynamic PerformanceIndex classes for CLIP CMU. Action is a common theme that was not initially in CLIP-Core but was later integrated into both domain models in different ways. In CLIP EPI-CREM an explicit object type was necessary. Alternatively in CLIP-CMU, inspections and corrective actions are represented as subclasses of PerformanceIndex, which is an implementation decision that aims to simplify the traceability graph by considering all of its nodes as the same object type. These two approaches to the same problem demonstrate the different ways of representing the same concept regarding CLIP-Core's object structure. Aggressive tradeoffs, on the other hand, require drastic changes that eventually compromise the model's integrity. For CLIP-Core, such tradeoffs include changing/eliminating the fundamental data structures such as the graph, or removing central objects in the model. This centrality can be best described with coupling. The removal of stronglycoupled objects, such as Component or PerformanceIndex upon which most other objects are built, renders the model useless. Weakly-coupled objects, on the other hand, can be safely removed as in the case of ComponentSet. Deep class hierarchies, too, can be said to be susceptible to change, as the inherited concepts makes it difficult to predict and control class behavior. Moreover, even multiple independent changes can have interacting effects, forming complex change networks. These change processes, in the worst case, can “avalanche” and lead to an increasing volume of changes that might not be brought to a conclusion [11]. This means that the adaptation process failed and the system does not allow those types of changes, in which case the reuse of CLIP-Core might not be desirable.

4.4. Points of improvement 4.4.1. Semantically The semantics of the graph topology can be enhanced with the use of formal languages such as Web Ontology Language (OWL), resource description framework (RDF) or description logics. As such, a more detailed and complex characterization of topology relationships can be achieved, as well as posing constraints on the component–topology structure, and relationships of cardinality, dependence, or disjointness. Moreover, CLIP ontologies have the potential to be used as standard schema for data sharing and interoperability. When necessary exchange procedures are implemented, data mapping between other data sources can be carried out through an ontology.

58

I.G. Dino, R. Stouffs / Automation in Construction 40 (2014) 44–59

4.4.2. Representationally During the development of two domain models, we representationally extended CLIP-Core only with new objects and algorithms. A broader perspective can alternatively follow an extension based on functions as autonomous plug-in applications, namely the serviceoriented architecture (SOA). SOA organizes the discrete functions contained in enterprise applications into interoperable, standardsbased, platform-independent services that can be combined and reused to meet an organization's business needs [33]. SOA considers these services as the primary elements of design and production, such that the functionality of an existing service can be reused rather than built from scratch, promoting reuse at the macro (service) level rather than micro (classes) level [36]. In applications supporting the building lifecycle, distributed looselycoupled environments have a number of advantages over centralized models, such as extensibility, reliability and feasibility for composite services and end user applications [39,16,5,21]. The SOA approach, if applied to CLIP-Core, requires a central model that contains the domain objects that will be shared by the functions, or services. The plug-in services, in return, should operate on the domain objects contained within the central model while applying their intended functionality. Correspondingly, CLIP-Core can assume a broader understanding of services, and foster the development of specific functions as satellite services. Each domain function that we have previously developed has the potential to be implemented as a plug-in service. This approach can take CLIP-Core at its center only as a static representational model, while delegating the algorithms into services, such as topology operation services, or risk assessment services. The standardization of communication is of upmost importance in SOA to ensure the reliability and predictability of service transactions. To be able to ensure a robust central model, the flexibility of CLIP-Core needs to be downsized. Moreover, the idea of external ontologies needs to be substituted with a final, complete and accurate component model that will be shared across the services developed. The benefits of SOA in maximizing functional flexibility and reusability might overweigh the advantages of CLIP-Core as it is discussed in this paper. 4.4.3. Extensions that increase the applicability of CLIP Intensive data input is a limitation against the practical use of CLIPCore. The applicability of CLIP-Core can be improved by augmenting the model with extensions that ease the LBPA data input and its management by allowing automated access to external data sources with importing routines. These data sources include other computational tools being used during LBPA, data repositories, or sensor-based systems that monitor building performance. Import routines can allow the reuse of pre-defined building data and facilitate data integration between CLIP and external sources. The use of data capturing technologies can also improve the LBPA processes in carrying out fieldwork. While physical inspections are being carried out, inspectors usually need to access relevant information to be able to reason about the findings. If embedded in RFID devices, such information can be reliably made available when needed during an inspection activity. Moreover, the matching between the physical element and the abstract information about element specifications, performance and history, contained within digital files or software tools, is another area that RFID devices can be of help. 5. Conclusion This paper presented a reference model that contains data structures and algorithms that support the performance assessment of existing buildings. CLIP-Core is explanatory, describing and structuring the generic concepts of LBPA, and normative, fostering and supporting the development of fully functional domain models and software tools with increased efficiency and ease. Therefore, it is a valuable artifact both in understanding the domain of study and developing

computational models addressing this domain. In this paper we focus on the evaluation of CLIP-Core as a development accelerator that can help the future modeling and software development efforts that address unforeseen practical contexts. Although CLIP needs to be tailored to meet the local needs, this effort is still considerably lighter than approaching the development of each computational model as a new project. Although it is impossible to precisely quantify the advantage that CLIP-Core has over build-from-scratch approaches, we can claim that it supports the development process in various ways based on our experience. As a conceptual model, it helps to establish a common conceptual vocabulary for communication between the model developers and the domain actors. As a reference model, it shortens the domain model and software development processes by providing basic concepts and algorithms. As a software tool, it allows prototypes to be built early on during development, increasing the involvement of the domain actors with the project. References [1] A. Akcamete, B. Akinci, J.H. Garrett, Motivation for computational support for updating building information models (BIMs), Proceedings of the 2009 ASCE International Workshop on Computing in Civil Engineering, vol. 346, 2009, pp. 523–532. [2] J. Becker, P. Delfmann, Reference Modeling: Efficient Information Systems Design through Reuse of Information Models, Physica-Verlag GmbH, 2007. [3] J. Beetz, J. Van Leeuwen, B. De Vries, IfcOWL: a case of transforming EXPRESS schemas into ontologies, Artif. Intell. Eng. Des. Anal. Manuf. 23 (01) (2009) 89–101. [4] D. Benslimane, A. Arara, G. Falquet, Z. Maamar, P. Thiran, F. Gargouri, Contextual Ontologies, Advances in Information Systems, Springer, 2006. 168–176. [5] S. Boddy, Y. Rezgui, G. Cooper, M. Wetherill, Computer integrated construction: a review and proposals for future direction, Adv. Eng. Softw. 38 (10) (2007) 677–687. [6] P. Bouquet, F. Giunchiglia, F. van Harmelen, L. Serafini, H. Stuckenschmidt, Contextualizing ontologies, Web Semant. Sci. Serv. Agents World Wide Web 1 (4) (2004) 325–343. [7] J. Bröchner, Integrated development of facilities design and services, J. Perform. Constr. Facil. 17 (1) (2003) 19–23. [8] M.J. Darlington, S.J. Culley, Investigating ontology development for engineering design support, Adv. Eng. Inform. 22 (1) (2008) 112–134. [9] I.G. Dino, R. Leeuw, S. Sariyildiz, R. Stouffs, A method for energy performance integration in corporate public real estate management, J. Perform, Constr. Facil. (2013), http://dx.doi.org/10.1061/(ASCE)CF.1943-5509.0000428 (Published online before print December 13 2012). [10] C. Eastman, T.S. Jeng, A database supporting evolutionary product model development for design, Autom. Constr. 8 (3) (1999) 305–323. [11] C. Eckert, W. Zanker, P.J. Clarkson, Aspects of a better understanding of changes, Proceedings of ICED, Vol. 1, 2001. [12] N.E. Fenton, M. Neil, Software metrics: roadmap, Proceedings of the Conference on the Future of Software Engineering, ACM, 2000, pp. 357–370. [13] W. Frakes, C. Terry, Software reuse: metrics and models, ACM Comput. Surv. (CSUR) 28 (2) (1996) 415–435. [14] M.P. Gallaher, R.E. Chapman, Cost Analysis of Inadequate Interoperability in the US Capital Facilities Industry, US Department of Commerce, Technology Administration, National Institute of Standards and Technology, 2004. [15] W. Gielingh, General AEC Reference Model (GARM): An Aid for the Integration of Application Specific Product Definition Models, ISO TC 184/SC4/WG1 Document N329 Delft, Netherlands, 1988. [16] A. Grilo, R. Jardim-Goncalves, Challenging electronic procurement in the AEC sector: a BIM-based integrated perspective, Autom. Constr. 20 (2) (2011) 107–114. [17] I. Gursel, S. Sariyildiz, O. Akin, R. Stouffs, Modeling and visualization of lifecycle building performance assessment, Adv. Eng. Inform. 23 (4) (2009) 396–417. [18] B. Hailpern, P. Tarr, Model-driven development: the good, the bad, and the ugly, IBM Syst. J. 45 (3) (2006) 451–461. [19] H.C. Howard, J.A. Abdalla, D. Douglas Phan, Primitive-composite approach for structural data modeling, J. Comput. Civ. Eng. 6 (1) (1992) 19–40. [20] I.A.I. Model Support Group, IFC2x Edition 3 Technical Corrigendum, http://www. buildingsmart-tech.org/ifc/IFC2x3/TC1/html/2007. [21] Y. Jiao, Y. Wang, S. Zhang, Y. Li, B. Yang, L. Yuan, A cloud approach to unified lifecycle data management in architecture, engineering, construction and facilities management: integrating BIMs and SNS, Adv. Eng. Inform. 27 (2) (2012) 173–188. [22] C. Jones, Software metrics: good, bad and missing, Computer 27 (9) (1994) 98–100. [23] R. Katzengruber, Evaluation of the EPI-CREM embedding approach and software tool in 20 nonresidential buildings: France, Netherlands and Austria. G. Moritz. Klagenfurt, Austria, energie:bewusst Kärnten, 2010(http://www.buildup.eu/sites/ default/files/content/OVERAL%20Pilot%20results.PDF). [24] K.H. Law, Data, product, and process modeling in civil engineering, J. Comput. Civ. Eng. 10 (3) (1996) 173. [25] J.v. Lokven, Conditiemeting van bouw- en installatiedelen - Deel 1, Methodiek, Nederlands Normalisatie-instituut, Delft, 2006. [26] Y. Ma, Y. Feng, B. Jin, J. Wei, A default extension to distributed description logics, Web. Intell. Agent Syst. 4 (4) (2006) 371–383.

I.G. Dino, R. Stouffs / Automation in Construction 40 (2014) 44–59 [27] A. Mahdavi, Reflections on computational building models, Build. Environ. 39 (8) (2004) 913–925. [28] S. Matook, M. Indulska, Improving the quality of process reference models: a quality function deployment-based approach, Decis. Support. Syst. 47 (1) (2009) 60–71. [29] D. O'Sullivan, M. Keane, D. Kelliher, R. Hitchcock, Improving building operation by tracking performance metrics throughout the building lifecycle (BLC), Energy Build. 36 (11) (2004) 1075–1090. [30] O. Ooijevaar, C. Tiekstra, O. Ooijevaar, C. Tiekstra, Guidance Book and Reference Manual: EPI-CREM Embedding Approach, Ministry of Housing, Spatial Planning and Environment, The Hague, Netherlands, 2010. [31] K. Papamichael, Application of information technologies in building design decisions, Build. Res. Inf. 27 (1) (1999) 20–34. [32] O. Pastor, J.C. Molina, Model-Driven Architecture in Practice: A Software Production Environment Based on Conceptual Modeling, Springer Verlag, 2007. [33] D. Petcu, V. Iordan, Understanding Service-Oriented Architectures in the Classroom: From Web Services to Grid Services, in: G.A. Papadopoulos, W. Wojtkowski, G. Wojtkowski, S. Wrycza, J. Zupancic (Eds.), Inf, Syst. Dev, Springer US, 2010, pp. 831–838. [34] D.G. Platt, Building process models for design management, J. Comput. Civ. Eng. 10 (3) (1996) 194–203. [35] B. Poel, G. van Cruchten, C.A. Balaras, Energy performance assessment of existing dwellings, Energy Build. 39 (4) (2007) 393–403. [36] L. Ribarov, I. Manova, S. Ilieva, Testing in a service-oriented world, InfoTech 2007, Proceedings of the International Conference on Information Technologies, CiteSeer, 2007. [37] R. Schuette, T. Rotthowe, The guidelines of modeling — an approach to enhance the quality in information models, Lect. Notes Comput. Sci (1998) 240–254. [38] W. Shen, Q. Hao, H. Mak, J. Neelamkavil, H. Xie, J. Dickinson, R. Thomas, A. Pardasani, H. Xue, Systems integration and collaboration in architecture, engineering, construction, and facilities management: a review, Adv. Eng. Inform. 24 (2) (2010) 196–207. [39] W. Shen, Q. Hao, Y. Xue, A loosely coupled system integration approach for decision support in facility management and maintenance, Autom. Constr. 25 (2012) 41–48. [40] R. Stouffs, Constructing design representations using a sortal approach, Adv. Eng. Inform. 22 (1) (2008) 71–89. [41] R. Stouffs, Visualizing information structures and its impact on project teams: an information architecture for the virtual AEC company, Build. Res. Inf. 29 (3) (2001) 218–232. [42] R. Stouffs, R. Krishnamurti, On the road to standardization, in: B.d. Vries, J.v. Leeuwen, H. Achten (Eds.), Computer Aided Architectural Design Futures 2001, Kluwer Academic, Dordrecht, 2001, pp. 75–88.

59

[43] R. Sudarsan, S.J. Fenves, R.D. Sriram, F. Wang, A product information modeling framework for product lifecycle management, Comput.-Aided Des. 37 (13) (2005) 1399–1411. [44] A. Thomsen, K. van der Flier, Understanding obsolescence: a conceptual model for buildings, Build. Res. Inf. 39 (4) (2011) 352–362. [45] Z. Turk, On Theoretical Backgrounds of CAD, Artificial Intelligence in Structural Engineering, Lecture Notes in Artificial Intelligence, Springer, 1998. 490–496. [46] J. Van Leeuwen, A. Hendricx, S. Fridqvist, Towards dynamic information modelling in architectural design, Proceedings of the CIB-W78 International Conference IT in Construction in Africa 2001, 2001, pp. 19.11–19.14. [47] S. van Nederveen, F. Tolman, Neutral object tree support for inter-discipline communication in large-scale construction, ITCON 6 (2001) 35–44. [48] C. Wohlin, A. Aurum, H. Petersson, F. Shull, M. Ciolkowski, Software inspection benchmarking — a qualitative and quantitative comparative opportunity, Software Metrics, 2002, Proceedings. Eighth IEEE Symposium on, IEEE, 2002, pp. 118–127. [49] F. Wolter, M. Zakharyaschev, Satisfiability problem in description logics with modal operators, Principles of Knowledge Representation and Reasoning — International Conference, CiteSeer, 1998, pp. 512–523. [50] B. Hillier, Space is the machine: a configurational theory of architecture, Cambridge University Press, Cambridge, 2007. [51] A. Turner, M. Doxa, D. O'sullivan, A. Penn, From isovists to visibility graphs: a methodology for the analysis of architectural space, Environ Plann B 28 (1) (2001) 103–121. [52] A. Schwarz, D.M. Berry, E. Shaviv, Representing and solving the automated building design problem, Computer-aided design 26 (9) (1994) 689–698. [53] C. van Treeck, E. Rank, Dimensional reduction of 3D building models using graph theory and its application in building energy simulation, Engineering with Computers 23 (2) (2007) 109–122. [54] S. Isaac, R. Navon, Modeling building projects as a basis for change control, Automation in Construction 18 (5) (2009) 656–664. [55] Y. Zhang, X. Luo, J. Li, J.J. Buis, A semantic representation model for design rationale of products, Advanced Engineering Informatics 27 (1) (2013) 13–26. [56] J. Haymaker, J. Kunz, B. Suter, M. Fischer, Perspectors: composable, reusable reasoning modules to construct an engineering view from other engineering views, Advanced Engineering Informatics 18 (1) (2004) 49–67.