Building Information Modelling for Building Control

Renato Filipe Vieirarenato.vieira@ist.utl.pt

Instituto Superior Tecnico, Lisboa, Portugal

May 2015

Abstract

Despite the emergence of Building Information Modeling (BIM) standards, not all dimensions ofconstruction are supported to the same extent. Such is the case of the Building Automation (BA) di-mension, where only aspects related to mostly physical setup of devices are supported, which are largelyinsufficient to enable modeling automation scenarios. BA requires modeling a richer set of aspects, stillvery heterogeneous, without becoming bound to a specific technology upfront. BIM standards suchas Industry Foundation Classes (IFC) position themselves as natural candidates for modeling and ex-changing information regarding BA. However, the extent to which BIM supports automation aspectshas never been rigorously analyzed.

This work explores the hypothesis of extending BIM to support BA concepts, proposing a newextension to the IFC model, based on an assessment of scientific and technical literature. This studyelicits the information requirements of BA and performs a gap analysis with current BIM standardssuch as IFC, upholding the proposal of a set of new concepts, using model-driven techniques, whichenable IFC to exchange automation scenario data. This approach is validated for completeness usingmodel transformations.Keywords: Building Information Modeling, Building Automation, Model-Driven Engineering

1. Introduction

Efficient Facility Management (FM) is becoming anincreasingly important topic that relies on Informa-tion Technology (IT) to support the achievementof energy and managerial efficiency goals [23], sup-ported by tools such as Computer-Aided FacilityManagement (CAFM) and Computer-Aided Main-tenance Management (CAMM) as well as tools forBuilding Automation (BA) and Energy Manage-ment Systems (EMS). Ideally, the operation of thesetools should be supported by a common representa-tion as Building Information Modeling(BIM) [1, 10].Although some progress has been accomplished inmaking CAFM and CAMM applications interoper-able with BIM models [8, 34] BA and EMS still lackin terms of integration with BIM. The focus of thiswork is to establish such connection, proposing anextension that is able to express the requirements ofheterogeneous BA, enabling distinct tools to sharedetails regarding the configuration and setup of au-tomation systems through BIM models.

A BAS consists of a network of sensors, actuatorsand controllers that collect data and manage the op-eration of a wide span of electric equipment, such asHeating, Ventilation, and Air Conditioning systems(HVAC), or lighting, according to a set of controlprocedures previously configured. BASs also enable

monitoring of equipment and building performanceas well as remotely managing electric loads to im-prove operation and energy efficiency [21, 24]. In-formation regarding structure and implementationof a BAS—network topology, device configuration,control loops—is very complex to grasp from thedocumentation delivered to the building managerwhen the system is installed [30]. Despite the factthat a part of this information is available, the im-plementation details are frequently not understoodby the building owner nor by technical maintenancepersonnel. In fact, only the vendor can comprehendthe entire BAS, making the building owners highlydependent on their contractors whenever they wantto modify, commission, or tune the BAS [29]. Ide-ally, this information should be represented in aBAS- independent way, enabling facility managersto easily contract system alteration, hiring special-ists, and using third- party tools or technologies.

BIM supports a more efficient management of fa-cilities since all building information, from designto operation, is contained in a shared digital repos-itory [5]. Thus, a BIM-supported FM is more ef-fective, once the information is promptly availableto the applications and more efficient, since it isshared across the building’s peers avoiding losses,replication and incoherence of data [2, 26]. BIM fo-

1

cuses on integrating all the data concerning build-ing’s life cycle in one digital single model, provid-ing a cross-entity representation of it, and makingit easier for every stakeholder to get involved oneach of the Architecture, Engineering, Constructionand Operation (AEC/O) phases [12, pp.1]. Never-theless, this approach is still deeply connected tothe structural phases of the building life cycle, suchas Architecture, Engineering and Construction insharp contrast with several limitations of the Oper-ational phase, specially in what concerns modelingand sharing information regarding BA elements.

The lack of connection between AEC and Oper-ation dimensions is mostly due to two factors. Thefirst has to do with the targeting of efforts to the de-sign phases, where Computer Aided Design (CAD)software vendors play an important role on influ-encing research and development [17]. The secondhas to do with the automation information itself,that is of a more volatile nature than informationregarding other constructive elements (characteris-tics and arrangement of automation elements aresubject to change faster than the constructive el-ements). Although BIM exchange formats, suchas Industry Foundation Classes 4 (IFC)1, alreadyfeature constructs for the BA domain, these areonly used for delivery of information such as in-stallation instructions or device specification. Ef-forts are being made for integrating BAS data intoBIM’s exchange format, but the information sup-ported by the current BIM standard is limited onlyto the system structure, like devices and wiring re-lations, disregarding the logical and operational di-mensions, such as control loops, bindings or config-uration management [8]. As will be clear later, dataregarding BAS in BIM is still largely incomplete toenable interoperability with BAS tools, negativelyimpacting operation efficiency [20].

Model-Driven Engineering (MDE) provides anon-traditional approach to system development.MDE conceives the domain model as the centralconcept for developing a system, separating theformal description of the domain from the con-crete platforms on which it will be built[11]. Inother words, MDE enables the independent spec-ification of the functionality, abstracting from theconcrete idiosyncrasies of the target platform onwhich the system is implemented. This allows thesame model to be implemented on several infras-tructures, through the specification of mappingsbetween the model and target platforms. Sincethe model specification is independent from spe-cific implementation, and the mappings handle theconversion between platforms, different platformscan interoperate more easily, sharing a commonrepresentation[28, 32]. In a practical sense, MDE

1http://www.buildingsmart.org/standards/ifc

eases system development due to, amongst others,the following aspects. Firstly, the correctness ofthe core domain (model) of the system is moreeasily evaluated since the functionality is isolatedfrom the implementation. Secondly, the gener-ation of implementations under several platformsis semi-automated, saving time. Thirdly, the in-tegration of different platforms is more simple toachieve through the usage of a common, indepen-dent model representation. Finally, the domain ismore easily maintainable, since changes are exe-cuted in the model and easily propagated throughtarget platforms[22].

Despite being developed as a data exchange for-mat, IFC can be perceived under the light ofMDE[15]. Since IFC is an independent model forrepresenting building data, model transformationscan be specified, using MDE techniques, in order tomap IFC constructs into different platforms suchas BA protocols or commissioning tools instead ofserving as input for applications which have to con-form with its specification[19]. Using this approach,further IFC versions can evolve independently of thetarget platforms, as long as the model transforma-tions remain coherent, thus favoring maintainabil-ity. Also, the target platforms can be fed by infor-mation contained in IFC models without having toimplement IFC specifications.

The convergence between BIM and BA worldsusing model-driven techniques opens an array ofinteresting possibilities regarding building efficientoperation such as (i) reducing scattering and im-proving consistency of BA data, (ii) favoring inter-operability between BA tools which reduces main-tenance costs and finally, (iii) improving the inde-pendence of the representation of BA data, eventu-ally leading to alleviating customer lock-in. Stud-ies have suggested the development of extensionsto BIM [25, 31, 34] and also of platforms that in-tegrate information with it for use in applicationsrelated to buildings [3, 6, 35]. There are also, sev-eral initiatives relying on MDE for interacting withBIM [7, 15, 16, 16]. This underscores the impor-tance of BIM as interoperable source of data. How-ever, IFC version 4 elements concerning BAS do notfully cover the entire BA domain concerns. In addi-tion, the only tools available for realizing, analyzingand managing BAS are proprietary, and do not sup-port BIM, keeping FM inefficient and locked-in totool vendors, that are the only ones that can under-stand the details of Automation Systems and man-age their implementation [9]. Interoperability of BAwith BIM would, therefore, contribute to more effi-cient building automation.

This work presents a new BIM-based standard formodeling BA requirements in a vendor-independentmanner. Such approach will enable the develop-

2

ment of open tools to manage, control, and analyzeBA systems. Indeed, the results presented hereinare far-reaching as they contribute to alleviatingthe customer dependency from the vendor that in-stalled the systems. The model extension developedin this work will be validated using a model trans-formation mechanism, mapping it into the BA pro-tocols studied, in order to prove the completenessand equivalence of the extension, facing the above-mentioned BA protocols.

2. Background

This section presents a series of relevant definitionsfor understanding the problem discussed. Firstly,we are going to describe BIM, making a brief anal-ysis to its motivations and features. Secondly, someconcepts regarding BAS will be visited. Thirdly,this work explores the data that characterizes theBAS features. Finally, the most relevant aspectsrelated to Model-Driven Engineering are visited.

2.1. Building Information Modelling

BIM is an open technology for digital building mod-eling. The National Institute of Building Sciences(NIBS)2 describes BIM as an improved planning,design, construction, operation, and maintenanceprocess using a standardized machine-readable in-formation model for each facility, new or old,which contains all appropriate information createdor gathered about that facility in a format usable byall throughout its life cycle” [27].

The motivation for BIM has sprung from theneed to simplify the process of passing the informa-tion between activities in building AEC/O phases.Overall, BIM rests on three main aspects. First,BIM stores information in a digital representation,that reduces costs of paper support, while reducingthe complexity inherent to the construction processand making it more agile. BIMs also serve as unifieddata sources that centralize all relevant building in-formation. A computational model containing thefacility’s data enables integration of a wide varietyof tools that modify and collect data on the model,enabling several kinds of analysis. One common ex-ample is energy simulation [4].

The second aspect of BIM is that digital mod-els may be shared and updated concurrently. Dis-tinct stakeholders can insert, update or delete in-formation from it, contributing to the enrichmentof the model. The recurring example is the archi-tect adding sketches of the building, the structuralengineer modifying it to comply with engineeringrequirements, the builder using it to plan the con-struction phase, and the facilities manager analyz-ing it to operate the facility properly [5, 18, 35].

Finally, the third aspect is that BIM organizes in-

2http://www.nibs.org/

formation in a structured way. This contributes tomaking processes more consistent and also to pre-serving the information coherence, preventing dataquality issues. Moreover, structuring automates theanalysis of the models, favoring error traceability.For example, it is possible to query the model tocheck for collisions between different components orconstruction errors, like an air duct colliding withthe building roof [12, 33, pp. 21-22, 24].

2.2. Building AutomationA BAS connects electrical and mechanical compo-nents in a facility enabling them to interact. Typ-ically a BAS is responsible for managing HVAC,lighting, among other aspects and possibly inter-acting with other systems, such as access controland fire safety [21]. A large number of conceptshave to be analyzed in order to support BA aspectsin BIM.

With respect to the conceptualization of a BAS,it is important to define upfront the difference be-tween the concepts of equipment and control device.This distinction is as follows:

Equipment stands for a part of, or an entireelectrical or mechanical system, that inter-acts with the building environment, namelyHVAC systems, electrical blinds, or luminar-ies. Equipement can be atomic, or composedof simpler equipment. This composition is de-picted in the Figure 1.

Control devices consist of equipment with logicalbehavior in a BAS control network. Sensors,actuators, meters, controllers, or gateways areexamples of control devices. They can sense,act and execute logic on the environment di-rectly or on another equipment, for example, asensor detecting movement on a given room ora dimmer controlling the output of a luminary.

Control devices and equipment in general can bearranged in several ways. For example, there are

Devices

Equipment Sensor

Meter

Actuator

Controller

Sub-Equipment

ReadingDatapoint

Exposes1..*

1..*

1..*

1..*

R/WDatapoint

R/WDatapoint

WritingDatapoint

Figure 1: Decomposition of an equipment in smallerequipment or control devices. Each control deviceexposes one or more datapoints in the BAS network.

3

devices that connect externally to another equip-ment, as is the case of external on/off actuators,while others are part of a complex equipment, suchas a fan controller inside an HVAC module. Fig-ure 2 illustrates this idea.

HVAC

Termostat ON/OFF

Controller Fan Temperature

ON/OFFDatapoint

SetpointDatapoint

SpeedDatapoint

TemperatureDatapoint

Legend

Equipment

Device

Exposed Datapoint

Figure 2: Example of the equipment tree of a simpleHVAC split system. It decomposes into a thermo-stat sub-equipment and an on/off switch control de-vice. The thermostat divides three control devices.All the control devices expose one datapoint.

One BAS can be organized according to threelevels: the Field level, the Automation level, andthe Management level. The field level consists ofequipment that interacts with the building envi-ronment, as well as the control devices. Automa-tion level consists of controllers responsible for or-chestrating other control devices, according to pre-defined control-loops, and collecting the data pro-duced. Management Level receives informationfrom controllers and manages their configuration.Management Level also unifies an interface for man-ual management tasks such as system state mon-itoring, event logging, manual variable configura-tion, access to historical data, or alarm notifica-tions. [13, 14, 21].

2.3. Domain ModelThis section systematizes the information require-ments from the BAS aspects. For each aspect, thissubsection defines the information that needs to becaptured in order to express it. This information issummarized in Table 1.

Field Level

Wiring relations are described through a list of de-vice connections, which represents every link

Level Concept Information required

Field

WiringDevice Connection

Device Connection Type

Equipment Specification Specific Device Information

LocationSpacial Element

Position

Influence ZoneInfluence Area

Influence Type

Influenced DevicesInfluence Devices

Influence Type

Automation

Bindings List of bindings

Datapoints List of datapoints

Device/Datapoint RelationList of Datapoints

Relation with devices

Management

Setpoints

List of setpoints

Unit of measure

Relation with datapoints

Scenarios

List of scenarios

Relation with trigger conditions

Relation with datapoints

Scheduling

List of Schedules

Relation with datapoints

Relation with date and time

Groups and Zoning

List of Groups and Zones

Relation with datapoints

Relation with building spaces

Alarms and Events

List of events and alarms

Relation with datapoints

Action to trigger

Table 2: Information requirements for the distinct automation components,organized according to the corresponding BAS level.

54

Table 1: Information requirements for the distinctautomation components, organized according to thecorresponding BAS level.

between devices. It is also necessary to specifythe device connection type of each relation, forexample RS232 or RJ45 cable.

Equipment Specification requires detailing thecharacteristics of each device, namely specificdevice information provided by manufacturers.

Location is supported by data about the spatialelement where the device is contained, as wellas the position of the device within that ele-ment.

Influence Zone supports the knowledge aboutthe spaces influenced by devices, namelythe influence area. It is also necessary to knowthe type of influence employed, for example,whether it is of actuation or monitoring.

Influence Devices similarly to influence zones,depend on information about the device con-nections. They are also defined by the type ofinfluence exerted.

Automation Level

Datapoints information is captured throughthe list of datapoints that compose the BAS,and its metadata.

Bindings require the specification of a list of logi-cal connections between datapoints.

4

Control Device/Datapoint Relation encodesa mapping between control devices and dat-apoints. Hence, to express this concept it isnecessary to know both the datapoint list andthe control device list, as well as the mappingbetween control devices and datapoints.

Management Level

Setpoints are supported by a list of setpoints. Foreach setpoint it is also necessary to know theunit of measure and the datapoint it refers to.

Scenarios are defined by the list of scenarios,which define the presets for each datapointthey affect.

Scheduling is based on a list of schedules, as wellas the datapoints they affect.

Groups and Zoning are defined by the list ofgroup and zone objects and the datapoints theycontain. For zoning it is also necessary to cap-ture the spatial elements related to the zoneobject.

Alarms and Events are described by the list ofoccurrences, the datapoints related to those oc-currences and the action they trigger.

3. ImplementationIFC4Automation is an extension the IFC4 informa-tion model, that covers the remaining relevant BASaspects from automation and management levels,such as bindings, setpoints, schedules, or scenarios,that are not met by the actual specification.

The model defines a set of new objects, relations,and resources that comply with IFC, enabling thereuse of constructs already available, such as equip-ment details, wiring, or location. In other words, itis designed to make possible the interaction betweenexisting IFC elements and the new ones.

EXPRESS IFC4Automation is developed usingEXPRESS, the modeling language used forspecifying IFC. Writing an extension usingEXPRESS provides a powerful mechanism forexpressing all the elements, required withoutambiguities, and guarantees the consistencyneeded in a BIM extension, in the sense thatthere is no need for translating between differ-ent modeling approaches.

MDE IFC4Automation model defines a set of ab-stract constructs that capture the core infor-mation of each BA aspects in order to keepthe model independent from the several imple-mentations, detaching the core specification ofa BAS from the several technologies in whichit could be realized.

EMF IFC4Automation is also represented usingthe Ecore metamodeling language. Ecore ispart of the EMF platform where, in contrastwith EXPRESS which is less established in theMDE community, a multitude of open-sourcetools for handling models and metamodels arealready developed and well supported. Oncerepresented as an Ecore model, it is possiblefor IFC4Automation to interact with a largervariety of MDE tools.

IFC Compliance The structure of theIFC4Automation extension follows thesame design principles as the rest of theIFC specification. It consists of a set ofentities, relationships and data types, and alsopredicts the definition of property sets forcharacterizing each element.

Abstraction Constructs developed inIFC4Automation express each feature ina sufficiently high level manner, enabling thecreation of generic BAS domains that areindependent from the underlying technology.

3.1. Element RealmsIFC4Automation is arranged into three mainrealms, that address the three most general con-cerns of this work, which are the device topology,the structural configuration and the behavioral con-figuration. This division corresponds to the threemain functions that BAS models cover, namelytopology, structure, and behavior. The entities thatare contained in each of these realms are detailedbelow.

Device topology realm contains the elementsaiming at specifying control devices in termsof their physical and logical structure. The el-ements that belong to this realm define whichdatapoints are part of a given control device,how the datapoints are bound to each other,or which physical elements (IfcActuator or Ifc-Controller, for example) are related to whichcontrol devices.

Structural Configuration realm organizes theconstructs that capture the way datapointscan be organized to form a more complexstructure. Its elements enable the composi-tion of datapoints in free groups, such as allthe HVAC-related datapoints, as well as zonedgroups, which have a correspondence with agiven physical space.

Behavioral Configuration realm encloses the el-ements that address the logical behavior of dat-apoints. These elements enable the definitionof configuration setpoints, as well as action

5

sets, which are predefined actuations that canbe triggered by human users, environment con-straints or even other datapoints.

Table 2 summarizes the elements that constitutethe model extension.

Component Entity

(none)IfcAutomationObject

IfcAutomationObjectType

Device Topology

IfcAutomationDatapoint

IfcAutomationInputDatapoint

IfcAutomationOutputDatapoint

IfcAutomationControlDevice

Structural Configuration

IfcAutomationDatapointSet

IfcAutomationGroup

IfcAutomationZone

Behavioral Configuration

IfcAutomationDatapointWrite

IfcAutomationActuation

IfcAutomationSetpoint

IfcAutomationDevicePreset

IfcAutomationEvent

IfcAutomationAlarm

IfcAutomationScenario

IfcAutomationSchedule

Relationships

IfcRelBelongsToDevice

IfcRelBelongsToControlElement

IfcRelGroupsDatapoint

IfcRelTriggersEvent

IfcRelInfluencesSpace

IfcRelBindsToDatapoint

IfcRelBindsByDatapoint

IfcRelBindsByDatapointWrite

IfcRelLocatesInSpace

IfcRelDefinesSchedule

IfcRelDefinesDatapointWrite

Table 2: Summary of the elements defined inIFC4Automation organized by type of element andwith references for the component in which they arecontained.

3.2. Non-functional Requirements

The development of IFC4Automation encompassesthe satisfaction of three main non-functional re-quirements which are (i) flexibility, in order to ren-der the model less sensitive to change and evo-lution, (ii) complexity, since a simpler model ismore easily readable, therefore, more easily used,and finally (iii) interoperability, which is of extremeimportance, since this extension aims at being acommon representation between several automationtechnologies. The design decisions that fulfill therequirements above are detailed as follows.

Flexibility is addressed through the organizationof the model in realms, which are represented

by abstract entities . This separation of con-cepts makes the development of new entitiesinside each realm easier, since part of their def-inition is reused.

Complexity is addressed by circumscribing theinherent complexity of IFC. Firstly, entities areorganized in small hierarchies. Another aspectis the definition of a small, but cohesive set ofentities to express all the information require-ments. Reducing the depth of the inheritancetree and increasing the cohesiveness of the en-tity specification reduces the effort required bythe final user to discern the structure of themodel.

Interoperability is achieved in the first place byextending the IFC specification per se. More-over, each IFC4Automation element is de-signed to contain the attributes that are rel-evant for describing each aspect without de-pending on any technology.

4. ResultsSince IFC4Automation extends IFC standard spec-ification, it includes the complexity inherent toIFC. Despite is necessary to slightly increase thecomplexity of the IFC4 by adding 55 new classes,IFC4Automation remains with the same inheri-tance tree depth. It is also worth noting that thisnew 55 classes cover the remaining 9 BAS aspects.

In spite of directing efforts to makeIFC4Automation a flexible model, this workhad also to cope with complexity concerns, whichwould be greatly impacted if a trade-off would notbe considered. However, the measures taken inorder to make it a flexible model succeeded, sincethey make it easier to modify.

Finally, as mentioned earlier, IFC4Automation isthe only model that covers all the aspects of BASs,and therefore, is the only model that is suited formodeling BA scenarios on field, automation andmanagement level. Therefore, it can be said thatIFC4Automartion covers the whole set of aspectsof BAS.

5. Case Study: Sustainability Systems RoomIn order to further validate that IFC4Automation isadequate to express automation scenarios that areconvertible to BAS installation descriptions (con-forming to information models of particular au-tomation systems), this work encompasses the re-alization of a case study that consists of modelingan automation scenario installed in room 1.58 atIST-T and comparing it with the real installation.This case study evaluates whether the model gen-erated from an IFC4Automation description is ableto express the same logic as the currently deployedKNX configuration. This case study uses the Room

6

1.58, on the first floor of IST-T to test the model.This room is equipped with a KNX installation, andexposes datapoints for controlling mostly lighting,HVAC and blind control.

5.1. Room 1.58 IFC4A modelWith respect to the modeling of the automation sce-nario, the following approach was followed. Eachdevice was modeled as an IfcAutomationControlD-evice. The name, description and OID were setaccording with each one of the devices, as Fig-ure 4 depicts. Each datapoint exposed by theeach device was modeled, according to the type ofdatapoint, as an IfcAutomationInputDatapoint oran IfcAutomationOutputDatapoint, where the at-tributes OID, name, description, dataType, unitand address were set according to the datapointscharacteristics. The dataType attribute is alwaysset to USERDEFINED since the list of availabledatatypes is still an open topic for future work. Theindividual group addresses for each datapoint werespecified in modeling time, since the the installa-tion documentation already specified them. Oth-erwise they could be generated upon transforma-tion, however, in this case this would led to dis-crepancy between the addresses from the documen-tation, and the ones generated by the transforma-tion. The containment relation between each deviceand its exposed datapoints was modeled recurringto an IfcRelBelongsToDatapoint per device. Thedevice was inserted in the device end of the relationand the set of datapoints it exposed were insertedin the set of relating datapoints. For modeling eachgroup of datapoints, such as stopAllBlinds, an If-cAutomationGroup was instantiated with the nameand description attributes set. Similarly to device,each group is related with the datapoints it groupsthrough one relation object, this time IfcRelGroups-Datapoint. The group was inserted in the one endof the relation, and the datapoints that compose itwere added to the set that figures on the other endof the relation. An excerpt of the resulting modelis depcted in Figure 3.

Figure 3: Excerpt of the resulting IFC4Automationmodel for room 1.58. The first line depicts the def-inition of a IfcAutomationControlDevice.

5.2. Generated InstallationAs mentioned in the previous section, one of theroom 1.58 IFC4Automation representations serial-ized by the populate script intends to be fed intothe TransformToKNX transformation. Basically,

Figure 4: Excerpt of the resulting EMF model forroom 1.58. The highlighted construct representsa IfcRelBelongsToDevice, which properties are de-tailed in the properties tab on the lower section.

this file keeps representing the constructs conform-ing to the IFC4Automation schema, however, fol-lowing a XML-based representation, as depicted inFigure 4, where each construct is represented as anelement, and each relation as a reference attribute.For taming the complexity of reading and parsingall the constructive elements already represented inthe IST-T model, the EMF representation only con-tains the BA-related elements, that are the onesthat are relevant in the following steps.

After executing the transformation, the inputtedelements were converted to the following constructsof the KNX domain, as illustrated by Figure 5.Each IfcAutomationControlDevice was transformedinto a KNX FunctionalBlock. The name attributeof each device is mapped into the name of the func-tional block. Though the documentation of the baseinstallation did not mention their existence, thegenerated model includes functional blocks as log-ical aggregations of datapoints, that compose onedevice. Therefore, each functional block has a refer-ence to each datapoint that it contains. Each IfcAu-tomationDatapoint, whether input or output, gener-ated a KNX Datapoint and the respective GroupOb-ject. The group object contains relevant networkinformation regarding datapoints, hence, they arecreated at the same time. The OID, name, de-scription, dataType and unit attributes were di-rectly mapped form each IFC datapoint into eachKNX datapoint. IFC input and output datapointswere converted to KNX datapoints with the Flow-Type attribute set to ”INPUT” and ”OUTPUT”,respectively. Each datapoint has a reference at-tribute to its respective group object and functionalblock. Each IfcAutomationGroup was convertedinto a KNX GroupAddress. The IFC group nameand description were not mapped, since group ad-dresses do not define these attributes. The groupaddress was generated by the transformation, ac-cording to an algorithm that increments the groupidentifier each time a group is converted. Eachgroup address have references to the group objects

7

that represent the datapoints contained in it. It isalso worth noting that each group object containsa reference to its main group address, the one thatit uses when is necessary to send a package, anda reference to a list of group addresses from whichthe datapoint listens. In terms of generated objects,the transformation produced a total of 218, where92 represent BAS aspects such as datapoints, groupaddresses and functional blocks, and 126 representauxiliary objects such as group objects and data-point group addresses.

Figure 5: Excerpt of the resulting KNX model forroom 1.58. The highlighted construct represents aFunctionalBlock for blind 3, which properties aredetailed in the properties tab on the lower section.This object is equivalent to a device.

5.3. Discussion

The analysis of this case study makes possible todraw a set of conclusions regarding the transforma-tion performance. In what concerns to convertedconstructs, the transformation succeeded in con-verting all the 92 aspects (devices, datapoints andgroups) from the input model into constructs fromthe output model, hence, it can be concluded that,for this case study, the IFC4Automation extensioncan cover 100% of the automation scenario of theroom 1.58. Besides, the transformation was ableto convert all the constructs from the input modelinto equivalent constructs from the output model,which states that no ambiguities were found in ruleexecution. It is worth noting that all the possibletest cases could not be executed, since the KNX in-formation model does not cover the whole spectrumof BAS aspects, and that the automation scenariofrom room 1.58 is also unable to exercise all theuse cases of the KNX information model. However,evaluating the whole set of use cases that cover theentire KNX or IFC4A information models impliesan unpractical effort, out of the scope of this work.In addition, the aspects concerning data type test-ing and data type validation were not regarded sincethey are part of a future work, also out of the scope

of this research.

6. Conclusions

The emergence of BIM as a central repository for allthe building-related data makes possible to managemost aspects of buildings in a more efficient, con-sistent, and coherent way. However, the coverageof IFC, the standard model specification for BIM,regarding the logical aspects of BA is almost inex-istent. Also, there is no model that covers the fullspectrum of BAS concepts natively, accounting forplatform heterogeneity and vendor independence.

This work explores the connection amid the BIMand BA realms, and proposes IFC4Automation, anextension to IFC that (i) covers the logical compo-nents of BAS configurations, abstracting from tech-nological specificities, (ii) enables the definition ofinteroperable BAS models, that can be refined to in-stallations conforming to specific automation plat-forms, and (iii) provides a centralized repository forthe BAS-related data of facilities.

The proposed extension is evaluated towardscompleteness, complexity, flexibility, and interop-erability, and its practical applicability is statedthrough a model transformation.

The impact of this work is far-reaching as it drawsa path for solving the problems of (i) consistencyand coherence of BAS-related data, (ii) interoper-ability between different BA tools and protocols,and (iii) vendor dependency of the BAS configura-tion. Interoperability between BA models has beenstated as a solution for preventing customer lock-in,and for enabling the development of a multitude ofapplications that make use of the BAS informationfor improving, among other FM software.

Acknowledgements

The author would like to thank Professor PauloCarreira, for all the effort and good will demon-strated in supervising this work. Moreover, a workof gratitude to Instituto Superior Tcnico, whichtries everyday to provide the students with valu-able knowledge, with rigor and exigence.

References

[1] A. Akcamete, B. Akinci, and J. H. Garrett. Po-tential utilization of building information mod-els for planning maintenance activities. 2010.

[2] M. Alahmad, W. Nader, A. Brumbaugh,Y. Cho, S. Ci, H. Sharif, J. Shi, and J. Neal.The BIM’s 4D+ dimension: Real time energymonitoring. 2011 IEEE GCC Conference andExhibition (GCC), pages 589–592, Feb. 2011.

[3] M. Alahmad, W. Nader, J. Neal, J. Shi,C. Berryman, Y. Cho, S.-K. Lau, H. Li,A. Schwer, Z. Shen, J. Stansbury, and

8

T. Zhang. Real Time Power Monitoring & inte-gration with BIM. IECON 2010 - 36th AnnualConference on IEEE Industrial Electronics So-ciety, pages 2454–2458, Nov. 2010.

[4] B. alliance. National BIM Standard - UnitedStates Version 2. 2012.

[5] S. Azhar, M. Hein, and B. Sketo. BuildingInformation Modeling ( BIM ): Benefits , Risksand Challenges. 2007.

[6] V. Bazjanac. IFC BIM-based methodology forsemi-automated building energy performancesimulation. 2008.

[7] J. Beetz and L. V. Berlo. BIMSERVER.ORGAn open source IFC model schema. (Weise2006):16–18, 2010.

[8] C. Bogen, D. Ph, M. Rashid, E. W. East, andF. Asce. A framework for building informationfusion. pages 26–28, 2011.

[9] S. T. Bushby. BACnet: a standard communi-cation infrastructure for intelligent buildings.6:529–540, 1997.

[10] E. Curry, J. ODonnell, E. Corry, S. Hasan,M. Keane, and S. ORiain. Linking buildingdata in the cloud: Integrating cross-domainbuilding data using linked data. AdvancedEngineering Informatics, 27(2):206–219, Apr.2013.

[11] V. Devedzic, D. Djuric, and D. Gasevic. ModelDriven Engineering and Ontology Develop-ment. 2009.

[12] C. Eastman, P. Teicholz, R. Sacks, and K. Lis-ton. BIM handbook: A guide to building in-formation modeling for owners, managers, de-signers, engineers and contractors. Wiley. com,2011.

[13] W. Granzer and W. Kastner. Informationmodeling in heterogeneous Building Automa-tion Systems. 2012 9th IEEE InternationalWorkshop on Factory Communication Sys-tems, pages 291–300, May 2012.

[14] W. Granzer, W. Kastner, G. Neugschwandt-ner, and F. Praus. A modular architecture forbuilding automation systems. 2006 IEEE In-ternational Workshop on Factory Communica-tion Systems, pages 99–102, 2006.

[15] a. Grilo. Shifting the construction interoper-ability paradigm, in the advent of Service Ori-ented and Model Driven Architectures. Con-ference on Information Technology in Con-struction, 304:6, 2005.

[16] A. Grilo and R. Jardim-Goncalves. Challeng-ing electronic procurement in the AEC sector:A BIM-based integrated perspective. Automa-tion in Construction, 20(2):107–114, 2011.

[17] R. Howard and B.-C. Bjork. Building informa-tion modelling Experts views on standardisa-tion and industry deployment. Advanced Engi-neering Informatics, 22(2):271–280, Apr. 2008.

[18] U. Isikdag, G. Aouad, J. Underwood, andS. Wu. Building Information Models: A Re-view on Storage and Echange Mechanisms.1999.

[19] U. Isikdag and J. Underwood. Two de-sign patterns for facilitating Building Informa-tion Model-based synchronous collaboration.Automation in Construction, 19(5):544–553,2010.

[20] A. Karavan and K. Kabitzsch. Merging Build-ing Automation Network Design and IFC 2xConstruction Projects. 2005.

[21] W. Kastner, G. Neugschwandtner, S. Soucek,and H. M. Newman. Communication Systemsfor Building Automation and Control. 93(6),2005.

[22] S. Kent. Model Driven Engineering. IntegratedFormal Methods, Third International Confer-ence, {IFM}, 2335:286–298, 2002.

[23] J. Lee, Y. Jeong, Y.-S. Oh, J.-C. Lee, N. Ahn,J. Lee, and S.-H. Yoon. An integrated ap-proach to intelligent urban facilities manage-ment for real-time emergency response. Au-tomation in Construction, 30:256–264, Mar.2013.

[24] V. Marinakis, H. Doukas, C. Karakosta, andJ. Psarras. An integrated system for buildingsenergy-efficient automation: Application in thetertiary sector. Applied Energy, 101:6–14, Jan.2013.

[25] P. Meadati. BIM Extension into Later Stagesof Project Life Cycle. 2009.

[26] I. Motawa and K. Carter. Sustainable BIM-based Evaluation of Buildings. Procedia - So-cial and Behavioral Sciences, 74:419–428, Mar.2013.

[27] National Institute of Building Sciences. Na-tional Building Information Modeling Stan-dard. Technical report, 2007.

[28] OMG. Object Management Group, ModelDriven Architecture (MDA). (June):1–15,2003.

9

[29] S. Runde and A. Fay. A data exchange formatfor the engineering of building automation sys-tems. 2008 IEEE International Conference onEmerging Technologies and Factory Automa-tion, pages 303–310, Sept. 2008.

[30] J. Schein. An information model for buildingautomation systems. Automation in Construc-tion, 16(2):125–139, Mar. 2007.

[31] A. Schlueter and F. Thesseling. Building in-formation model based energy/exergy perfor-mance assessment in early design stages. Au-tomation in Construction, 18(2):153–163, Mar.2009.

[32] D. C. Schmidt. Model-Driven Engineering.Computer, 39(February):25–31, 2006.

[33] W. Shen, Q. Hao, H. Mak, J. Neelamkavil,H. Xie, J. Dickinson, R. Thomas, A. Pardasani,and H. Xue. Systems integration and collabo-ration in architecture, engineering, construc-tion, and facilities management: A review.Advanced Engineering Informatics, 24(2):196–207, Apr. 2010.

[34] R. Vanlande, C. Nicolle, and C. Cruz. IFC andbuilding lifecycle management. Automation inConstruction, 18(1):70–78, Dec. 2008.

[35] W. Yan, M. Clayton, J. Haberl, W. Jeong, J. B.Kim, A. Texas, and C. Station. InterfacingBIM with Building Thermal and DaylightingModelling. (Bazjanac 2001), 2007.

10